🤖 AI

Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

Dit artikel adresseert het kritieke beveiligingsgat in multitenant enterprise AI-systemen waarbij relevantie van ophaalresultaten autorisatie overstemt, door een serverzijdige, gelaagde isolatiearchitectuur binnen het open-source OGX-framework voor te stellen en te valideren die beleidsbewuste opname en ophaalbeperking afdwingt om lekken van data tussen tenants te voorkomen met een verwaarloosbare prestatie-overhead.

Oorspronkelijke auteurs: Francisco Javier Arceo, Varsha Prasad Narsing

Gepubliceerd 2026-05-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Francisco Javier Arceo, Varsha Prasad Narsing

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een enorme, high-tech bibliotheek voor waar duizenden verschillende bedrijven (huurders) planken hebben gehuurd om hun geheime documenten op te slaan. In deze bibliotheek werken ook krachtige robots (AI-agenten) die zijn ingehuurd om specifieke informatie te vinden en taken uit te voeren op basis van wat de bedrijven vragen.

Het artikel van Arceo en Narsing identificeert een gevaarlijk gebrek in de manier waarop deze bibliotheken momenteel werken en stelt een nieuw beveiligingssysteem voor om dit op te lossen.

Het probleem: De "Relevantie"-val

In een normale bibliotheek geeft de bibliothecaris je, als je om "recepten" vraagt, de boeken die het meest relevant zijn voor dat woord. Ze geven er geen om wie de boeken bezit; ze pakken gewoon de beste matches.

De auteurs wijzen erop dat dit in de AI-wereld een ramp is voor de beveiliging.

Het scenario: Bedrijf A vraagt de robot: "Hoe lossen we onze serverproblemen op?"
De vergissing: De robot doorzoekt de hele bibliotheek. Het vindt een document van Bedrijf B dat zeer vergelijkbaar is met de vraag (misschien gaat het ook over het oplossen van een serverprobleem).
Het lek: Omdat het document een "perfecte match" is voor de vraag, geeft de robot het door. Bedrijf A heeft zo per ongeluk het geheime serverhandboek van Bedrijf B gelezen.

Het artikel noemt dit de "Relevantie-Autorisatie-kloof". Het systeem is uitstekend in het vinden van wat relevant is, maar slecht in het controleren wie er toegang toe heeft.

De oplossing: Het "Gelaagde Isolatie"-gebouw

Om dit op te lossen, stellen de auteurs een nieuw gebouwontwerp voor met drie specifieke beveiligingslagen en een strikte regel over wie de sleutels in handen heeft.

1. De drie lagen van beveiliging

Stel je de gegevensreis voor als een pakket dat door een beveiligde faciliteit gaat:

Laag 1: Het Etiketteringsstation (Beleid-bewuste Inname)
Wanneer een bedrijf een doos met documenten aflevert, stempelt het systeem direct elke enkele pagina met een "Bedrijf A" of "Bedrijf B"-label. Je kunt ze niet later vergeten te etiketteren; dit gebeurt het moment dat ze aankomen. Dit zorgt ervoor dat elk stuk papier weet aan wie het toebehoort.
Laag 2: De Beveiligingspoort (Retrieval Gating)
Voordat de robot überhaupt mag zoeken naar boeken, moet hij door een beveiligingspoort. De poort controleert het ID-bewijs van de gebruiker.
- Als de gebruiker van Bedrijf A is, blokkeert de poort fysiek het gangpad met de boeken van Bedrijf B.
- De robot ziet de verboden boeken nooit, dus kan hij ze niet per ongeluk doorgeven. Dit heet ABAC-gating (Attribuutgebaseerde Toegangscontrole).
Laag 3: Het Gedeelde Brein (Gedeelde Inferentie)
Het daadwerkelijke "denkende" deel van de robot (het AI-model) wordt door iedereen gedeeld om kosten te besparen. Meestal zou je denken dat je een aparte robot nodig hebt voor elk bedrijf om geheimen veilig te houden. Maar omdat Laag 1 en 2 ervoor zorgen dat alleen de juiste, gelabelde documenten aan de robot worden gegeven, kan de robot veilig worden gedeeld. Het is alsof een kok voor iedereen kookt, maar de ingrediënten zijn vooraf gesorteerd zodat de kok nooit per ongeluk het geheime recept van de ene klant in het gerecht van een andere klant gebruikt.

2. De "Server-side"-regel

Het artikel stelt dat de beveiligingscontroles binnen het gebouw (de server) moeten plaatsvinden, niet buiten in het kantoor van de klant (de client).

De oude manier (Client-side): De computer van de klant doet het zoeken en controleren. Een slinks klant kan gewoon zijn beveiligingssoftware uitschakelen, de regels negeren en de robot vragen om naar alles te kijken.
De nieuwe manier (Server-side): De klant stuurt een verzoek, maar het interne beveiligingsteam van het gebouw doet al het zoeken, het gebruik van hulpmiddelen en het controleren. De klant kan vragen om een "rode auto", maar kan het beveiligingsteam niet vertellen om de regels te negeren en hen een "blauwe auto" te tonen die van iemand anders is. Het gebouw controleert hoe het zoeken plaatsvindt, zodat de regels nooit worden overtreden.

De resultaten: Wat ze hebben getest

De auteurs bouwden een prototype-systeem genaamd OGX (Open GenAI Stack) om dit idee te testen. Ze voerden experimenten uit met nep-bedrijven en lastige vragen om te zien wat er gebeurde.

Beveiliging: Zonder de nieuwe beveiligingspoort lekte de robot 98–100% van de tijd geheime documenten van andere bedrijven. Met de nieuwe poort werden 0% van de geheimen gelekt. De beveiligingspoort stopte de lekken volledig.
Snelheid: Het toevoegen van de beveiligingspoort vertraagde de zaken met een klein beetje (ongeveer 19 milliseconden). Dit is als het toevoegen van een split-second pauze aan een gesprek – voor mensen niet merkbaar, maar cruciaal voor veiligheid.
Kwaliteit: Omdat de robot niet in de war werd gebracht door irrelevante documenten van andere bedrijven, vond het de juiste antwoorden eigenlijk sneller en accurater.

De conclusie

Het artikel concludeert dat je een gedeeld, kosteneffectief AI-systeem kunt hebben voor veel verschillende bedrijven zonder dat ze elkaars geheimen stelen. Je moet gewoon stoppen met vertrouwen op de "relevantie" van een zoekresultaat en beginnen met het afdwingen van strikte "toestemmings"-controles bij de deur, allemaal beheerd door een centraal beveiligingsteam binnen de server.

Ze benadrukken dat dit een leveranciersonafhankelijke oplossing is, wat betekent dat het je niet vastzet bij één specifiek AI-bedrijf (zoals OpenAI of Google); het werkt met elke open-source of commerciële AI-tool die je kiest.

Technische Samenvatting: Beveiligen van de Agent in Multitenant Enterprise-omgevingen

1. Probleemstelling

Het artikel adresseert een fundamentele beveiligingskloof bij de implementatie van Retrieval-Augmented Generation (RAG) en agentische AI-systemen binnen enterprise-omgevingen. Waar academische behandelingen en consumentgerichte API's vaak uitgaan van single-tenant, homogene data-toegang, omvatten real-world enterprise-implementaties meerdere tenants die infrastructuur delen met heterogene data, strikte nalevingsregels en granulaire toegangscontrole-eisen.

Het kernprobleem dat wordt geïdentificeerd is de relevantie-autorisatiekloof. Bestaande ophaalsystemen (vector, trefwoord of hybride) optimaliseren voor semantische relevantie of trefwoordmatching, maar missen ingebouwde mechanismen om autorisatiebeleid af te dwingen. Bijgevolg kan een query van de ene tenant vertrouwelijke data van een andere tenant ophalen en zichtbaar maken als die data de hoogste score behaalt op relevantiemaatstaven. Deze kloof wordt versterkt in agentische systemen waar:

Tool-gemedieerde openbaarmaking optreedt wanneer agents tools aanroepen met brede credentials in plaats van eindgebruikersautorisatie.
Contextaccumulatie toelaat dat multi-turn gesprekken data over tenants heen lekken zonder per-turn beleidshercontrole.
Client-side orkestratie beveiligingskritieke logica verdeelt naar potentieel onbetrouwbare clients, waardoor autorisatiecontroles kunnen worden omzeild.

Standaard benaderingen voor isolatie, zoals het repliceren van de volledige agentische stack (vectoropslag, inferentie-eindpunten) per tenant, worden beschouwd als kostenprohibitief en operationeel gefragmenteerd.

2. Methodologie en Architectuur

De auteurs stellen een gelagen isolatiearchitectuur voor die wordt afgedwongen via server-side orkestratie om de data- en controlepaden van agentische AI te beveiligen. Deze aanpak is geïmplementeerd in OGX (Open GenAI Stack), een vendor-neutraal, open-source framework dat OpenAI-compatibele API's biedt.

2.1 Gelagen Isolatie (Data-pad)

De architectuur beveiligt de dataflow door drie distincte lagen binnen de server-vertrouwensgrens:

Beleidsbewuste Ingestion: Tenant-metadata (eigendom, attributen) wordt bij het moment van ingestion aan documenten gekoppeld. Dit zorgt ervoor dat elk documentfragment consistente tenant-attributen erft, waardoor accidentele koppeling tussen tenants wordt voorkomen.
Retrieval Gating: Een tweelaags afdwingingsmechanisme wordt toegepast:
- Pre-search: Attribuutgebaseerde toegangscontrole (ABAC) autorisatie wordt geëvalueerd voordat het zoeken begint.
- Post-retrieval: Filtering op fragmentniveau wordt toegepast na ophalen.
- Het systeem ondersteunt predicate pushdown (waar de vectorbackend filters natively toepast tijdens het zoeken) om perfecte recall op schaal te behouden. Als pushdown niet beschikbaar is, zorgt post-retrieval filtering voor beveiliging (nul lekken), maar kan dit de recall bij grote corpora verslechteren.
Gedeelde Inferentie: De Large Language Model (LLM) inferentielaag wordt gedeeld tussen tenants. Omdat lagen 1 en 2 ervoor zorgen dat alleen geautoriseerde documenten de promptcontext binnenkomen, vereist het model zelf geen per-tenant isolatie, wat de infrastructuurkosten verlaagt van $O(N \cdot M)$ naar $O(M)$ .

2.2 Server-side Orkestratie (Controle-pad)

Om risico's van client-side omzeiling aan te pakken, pleiten de auteurs voor server-side orkestratie van de inferentie $\to$ tool $\to$ inferentie-lus.

Vertrouwensgrens: Alle beveiligingskritieke operaties (tool-uitvoeringsautorisatie, staatisolatie, beleidsafdwinging) worden gecentraliseerd binnen het serverproces.
Trade-offs: Hoewel dit latentie introduceert voor tool-aanroepen in vergelijking met lokale uitvoering, voorkomt het dat gecompromitteerde clients filters overslaan of tool-aanroepen manipuleren.
Hybride Aanpak: De architectuur staat client-side frameworks toe controle te behouden over agentcompositie en latentie-gevoelige operaties, terwijl de server beveiligingsinvarianten afdwingt.

3. Belangrijkste Bijdragen

Het artikel levert vier primaire bijdragen:

Formalisatie van de Relevantie-Autorisatiekloof: De auteurs definiëren wiskundig waarom relevantieranking alleen ontoereikend is voor isolatie en leveren empirisch bewijs dat onbeperkte retrieval in 98–100% van de probes data over tenants heen lekt.
Gelaagde Isolatiearchitectuur: Een voorgesteld ontwerp dat beleidsbewuste ingestion, gating op het moment van ophalen en gedeelde inferentie combineert, met server-side orkestratie als afdwingingslaag.
Empirische Validatie: Een evaluatie met zes experimenten die beveiliging (lekken, weerstand tegen prompt-injectie), systeemprestaties (latentie, doorvoer) en ophaalkwaliteit meet over een $2 \times 2$ matrix van orkestratiemodi (client versus server) en retrieval gating (ongeperkt versus ABAC-gegateerd).
Open-source Implementatie: De architectuur is geïmplementeerd in OGX, een vendor-neutraal framework dat OpenAI-compatibele API's biedt (inclusief een Responses API voor multi-turn orkestratie) en een Kubernetes Operator voor implementatie.

4. Experimentele Resultaten

De evaluatie gebruikte een synthetisch testbed met drie tenants (financiën, engineering, juridisch) en 300 documenten.

Beveiliging (Lekken over tenants):
- Ongateerde Configuraties: Ongeacht de orkestratiemodus resulteerde ongegateerde retrieval in 98–100% lekken van data over tenants heen.
- Gateerde Configuraties: ABAC-gating elimineerde lekken over tenants volledig (0% lekken), waardoor het beveiligingsdoel (G1) werd bereikt.
- Prompt-injectie: Onder gateerde configuraties werden alle 90 prompt-injectieprobes geblokkeerd (0% lekken). In ongegateerde configuraties slaagden 62–80% van de probes erin ongeautoriseerde data op te halen.
- Afdwinging: De studie benadrukt dat hoewel client-side gating (Configuratie B) 0% lekken kan bereiken, dit afhankelijk is van de integriteit van de client. Server-side orkestratie (Configuratie D) biedt de noodzakelijke afdwingingsgarantie (G2) door logica binnen de vertrouwensgrens te verplaatsen.
Prestaties:
- Latentie: Retrieval gating voegde ongeveer 19ms toe aan het zoekpad (auth round-trip + beleidsbeoordeling + opzoeken), wat verwaarloosbaar is in vergelijking met inferentietijden (seconden). Server-side orkestratie voegde ongeveer 3s totale latentie toe door round-trips, maar ondersteunt streaming om de tijd tot eerste token te verminderen.
- Doorvoer: Gating degradeerde de doorvoer niet. De doorvoer groeide lineair met concurrentie. Client-side orkestratie bereikte bij hoge concurrentie ongeveer 2x de QPS van server-side orkestratie vanwege kortere request-paden.
Ophaalkwaliteit:
- Fragmentniveau-gating verbeterde Precision@5 met 2,2x (van 0,200 naar 0,433) door ruis over tenants heen te filteren.
- Predicate Pushdown: Backends die predicate pushdown ondersteunden, behielden Recall@5 = 1,0 over alle corpusgroottes heen. Backends zonder pushdown (met gebruik van post-retrieval filtering) zagen recall aanzienlijk verslechteren (van 1,0 naar 0,002) naarmate de corpusgrootte toenam tot 50k fragmenten, hoewel de beveiligingsgaranties intact bleven.

5. Betekenis en Reikwijdte

Het artikel beweert dat dit werk de eerste is die de intersectie adresseert van gestandaardiseerd agentisch API-ontwerp, server-side orkestratie en multitenant-isolatie op gedeelde infrastructuur.

Betekenis: De architectuur toont aan dat veilige multitenancy, vendor-neutrale OpenAI-compatibele API's en autonome agentcapaciteiten gelijktijdig kunnen worden bereikt zonder duplicatie van infrastructuur per tenant. Het verschuift het beveiligingsparadigma van "relevantiegebaseerd" naar "beleidgebaseerd" ophalen.
Reikwijdte en Beperkingen:
- De oplossing is ontworpen voor multitenant enterprise-omgevingen; het is onnodig voor single-tenant-implementaties of publieke data.
- De architectuur beveiligt contextopbouw maar niet parametrisch geheugen; modellen kunnen nog steeds informatie genereren die tijdens pretraining is opgenomen.
- De vertrouwensgrens is het serverproces; de architectuur biedt geen bescherming tegen gecompromitteerde serverprocessen, interne operators of side-channel-aanvallen.
- Client-side functietools blijven buiten de server-vertrouwensgrens, hoewel OGX dit mitigeert via expliciete tool-classificatie.

De auteurs concluderen dat hoewel client-side orkestratie lagere latentie biedt voor betrouwbare omgevingen, server-side orkestratie met ABAC-gating essentieel is voor enterprise-scenario's die strikte isolatie en naleving vereisen.