AI-agentbeveiliging begint met één regel: uw AI-agent mag nooit uw inloggegevens bewaren. Hier is het 38 jaar oude broker-patroon dat dit afdwingt.
AI-agents zijn verwarde gevolmachtigden. Dat is een 38 jaar oud beveiligingspatroon, en het antwoord is net zo oud: plaats een broker — een vertrouwde, observeerbare, deterministische, controleerbare, niet-vervalsbare, scope-beperkte, beleidsgestuurde, niet-AI tussenlaag — tussen de agent en de SaaS-API's die hij moet aanroepen, waarbij de inloggegevens worden bewaard die uw agent niet mag hebben.
In 1988 publiceerde Norm Hardy een kort artikel over een echt incident uit zijn tijd bij Tymshare. Een Fortran-compiler genaamd FORT stond in een systeemmap genaamd SYSX. Om gebruiksstatistieken te verzamelen, moest de compiler schrijven naar (SYSX)STAT, dus het besturingssysteem had FORT een "home files license" gegeven, waarmee hij elk bestand in SYSX mocht beschrijven. Het facturatiebestand van het systeem, (SYSX)BILL, stond daar ook. Een gebruiker die de compiler aanriep, kon een bestandsnaam opgeven om optionele debugoutput te ontvangen. Op een dag gaf een gebruiker (SYSX)BILL op. De compiler vroeg het OS dat bestand te openen om te schrijven; het OS, dat de home files license zag, stond het toe. De facturatiegegevens werden overschreven. De compiler deed precies waarvoor hij was ontworpen. De fout zat in de architectuur.
Hardy noemde het het confused deputy-probleem: een bevoorrecht programma (de gevolmachtigde) heeft eigen bevoegdheden; een minder bevoorrechte aanroeper vraagt hem iets te doen; de gevolmachtigde raakt in de war over namens wiens bevoegdheid hij handelt, en gebruikt zijn eigen. De oplossing is om die bevoegdheid helemaal bij de gevolmachtigde weg te halen en achter een aparte laag te plaatsen die de oproep op aanvraag bemiddelt. Die laag is de broker.
Achtendertig jaar later is elke AI-agent die uw bedrijf draait een verwarde gevolmachtigde. En de meeste draaien zonder broker.
Waarom AI-agents het beveiligingsprobleem verergeren
Hardy's FORT had één invoerkanaal: de opdrachtregel. Een moderne AI-agent heeft er tientallen: e-mailberichten, opgehaalde webpagina's, geüploade PDF's, tooluitvoer van MCP-servers, berichten van andere agents in een multi-agent systeem. Alles wat in het contextvenster terechtkomt, kan instructies geven, en de agent behandelt ze allemaal als legitiem.
Dat doorbreekt een aanname waar traditionele toegangscontrole op vertrouwt: de aanroeper beheerst de invoer. In een webapp komen de aanroeper (de geauthenticeerde sessie) en de invoer (de HTTP-request body) van dezelfde plek. Voor een agent is de aanroeper degene die de prompt vormgeeft, wat betekent dat een aanvaller die een e-mail kan schrijven of een zoekresultaat kan beïnvloeden, ook een aanroeper is.
In november 2025 lieten beveiligingsonderzoekers van PromptArmor zien hoe dat er in de praktijk uitziet. Ze verstopten kwaadaardige instructies in een 1-pixels lettertype op een integratiegids. Toen een ontwikkelaar Google's Antigravity IDE erop wees, omzeilde de agent zijn eigen .gitignore-gebaseerde bestandsbeveiliging door een shell-opdracht naar cat uit te voeren. Vervolgens lekte hij de inhoud van .env-bestanden naar een door de aanvaller beheerde webhook.site-URL via Antigravity's eigen browser-subagent. De gebruiker had alles correct ingesteld. De sandbox hield stand. De agent kon simpelweg niet onderscheiden wat de gebruiker vroeg van wat de invoer hem opdroeg.
Hetzelfde patroon als Hardy's FORT, decennia later: brede bevoegdheid, onbetrouwbare invoer, geen manier om die te scheiden.
De community heeft antwoorden. Ze zijn alleen verspreid.
Dit is geen nieuw probleem. De beveiligingsgemeenschap schrijft al decennia antwoorden:
Capability-based security (Dennis & Van Horn, 1966; later de E-taal en Mark Miller's Caja bij Google). Het principe: geef geen algemene bevoegdheid op basis van identiteit of locatie; geef expliciete, niet-vervalsbare bevoegdheden voor elke bron die het programma mag benaderen. Een capability bundelt wat je mag doen met waar je het op mag doen, en kan niet worden verward met iets anders.
Brokered Credentials (vastgelegd door de OWASP LLM Top 10). Zet geen API-tokens in de context van het LLM. Een vertrouwde tussenlaag doet de oproep namens de agent; het model bepaalt wat er moet gebeuren, de broker regelt hoe. Prompt-injectie die het model vraagt zijn inloggegevens te tonen, levert niets bruikbaars op. De inloggegevens zijn er niet.
Het Phantom Token Pattern (Curity, oorspronkelijk voor OAuth in microservices). De agent heeft een ondoorzichtige sessiehandle, niet het echte bearer-token. Een proxy valideert de handle, wisselt het echte token in aan de netwerkgrens en stuurt het upstream. Als de agent zijn omgeving lekt, krijgt de aanvaller een tekenreeks die verloopt als de sessie eindigt.
Just-in-time credential injection (workload identity-systemen zoals Aembit). Maak per oproep een kortlevend, scope-beperkt token aan in plaats van langlevende tokens uit te geven.
Niets hiervan ontbreekt in de literatuur. Het ontbreekt in de standaardinstellingen. De meeste agentplatforms geven het model nog steeds een OAuth-token zonder broker ertussen, en hopen op het beste.
Hoe de broker van Zero werkt
Wij hebben geen van bovenstaande patronen uitgevonden. We hebben ze samengebracht in één broker die standaard draait voor elke agent op Zero. Het is de vertrouwde tussenlaag die deze patronen beschrijven, gebouwd voor een AI-agentplatform. Elke oproep die een agent naar een connector doet, loopt erdoorheen. Elke connector is één externe SaaS (Slack, GitHub, Notion, enzovoort).
De broker zit tussen elke agent en elke connector. Echte inloggegevens blijven alleen aan de brokerzijde van de gestippelde lijn.
Zie het als drie lagen.
1. Credential-isolatie
De sandbox van de agent bevat nooit echte connector-inloggegevens. Wanneer u een SaaS aan Zero koppelt, blijft het OAuth-token of de API-sleutel aan de brokerzijde. De sandbox krijgt een placeholder-tekenreeks die genoeg lijkt op een omgevingsgeheim zodat bestaande tools blijven werken, maar geen enkele SaaS accepteert het.
Wanneer de agent een verzoek doet aan een geregistreerde connectorhost, koppelt de broker het verzoek, vult het authenticatiesjabloon van de connector in en injecteert het echte token aan de netwerkgrens. Het verzoek gaat upstream met geldige authenticatie; de agent heeft nooit iets bruikbaars gehad. Een prompt-geïnjecteerde agent die zijn omgevingsvariabelen dumpt, geeft de aanvaller een placeholder, niet het SaaS-token.
Dit is het phantom token-patroon, toegepast op AI-agents.
2. Connector policy gate
Een connector in Zero moet meer zijn dan een aan/uit-schakelaar. Elke connector beschrijft de API-bases die hij dekt en hoe authenticatie moet worden geïnjecteerd. Waar de upstreamdienst een stabiele scope-naar-endpoint-mapping publiceert, kan hij ook aangeven welke benoemde permissie bij elke methode en pad hoort. Slack's slack-api-ref is een goed voorbeeld.
Dus wanneer een agent die aan Slack is gekoppeld chat.postMessage aanroept, kan de broker dat verzoek koppelen aan chat:write. Als hij auditlogs leest, is dat admin.analytics:read. Voor elke agent bepaalt permission_policies hoe die benoemde permissies zich gedragen: toestaan, weigeren of vragen. Het beleid wordt afgedwongen bij de broker vóór authenticatie-injectie, niet als hint aan het model. Als de agent probeert een oproep te doen die onder een geweigerde permissie valt, bijvoorbeeld door prompt-injectie, bereikt het verzoek het upstreamnetwerk nooit.
Niet elke connector krijgt die resolutie vandaag. Sommige upstream-API's publiceren geen stabiele scope-naar-endpoint-mapping. GitHub's GraphQL-oppervlak is het klassieke geval: de REST-kant kan worden gemapt, maar de GraphQL-kant nog niet. Voor die connectors beheert de broker nog steeds de credential-injectie en het netwerkpad, terwijl de permissiepoort terugvalt op het grovere connector- of hostniveau dat het platform daadwerkelijk kan afdwingen. We vullen deze aan zodra upstreamdata beschikbaar komt. We claimen geen dekking die we niet gebouwd hebben.
Tokens dragen geen algemene bevoegdheid. Bevoegdheid wordt per agent bemiddeld, op het detailniveau dat upstream ondersteunt. Dat is het capability-based deel van het antwoord.
3. Operationele lus en audit
Least privilege werkt alleen als de faalmodus bruikbaar is. Agents groeien. Zes weken later heeft een onderzoeksagent die begon met lezen uit Notion misschien de behoefte om een samenvatting terug te schrijven. De gebruikelijke faalmodi elders: de agent draait stilletjes zonder de nieuwe permissie en faalt, of de operator geeft in paniek te veel rechten en trekt die nooit meer in.
Een geweigerd connectorverzoek retourneert een gestructureerde 403: connector, methode, pad, basis-URL en de bijbehorende permissienamen als de broker die kan identificeren. De system prompt van de agent vertelt hoe hij de weigering kan diagnosticeren en precies de permissie kan aanvragen die hij zojuist nodig had, wat een eenklik-verleen-URL oplevert voor de gebruiker of beheerder. Zo blijft het escalatiepad gekoppeld aan de exacte gevraagde permissie in plaats van te veranderen in "geef maar alles vrij".
Verzoeken tot permissiewijziging komen in een wachtrij. Eigenaren en beheerders kunnen ze goedkeuren of afwijzen via het dashboard; goedgekeurde verzoeken werken het beleid van de agent bij, en de volgende poging slaagt. De meeste platforms slaan deze lus over. Zonder deze lus blijft "least privilege" op de slides staan in plaats van in productie te draaien.
Hetzelfde brokerpad voedt de audit. Per-run netwerklogs registreren sandbox-netwerkactiviteit over HTTP, TCP, DNS en lagere pakketobservaties voor niet-TCP-verkeer. Connector-gematchte verzoeken bevatten gestructureerde brokermetadata: connector, gematchte permissie indien beschikbaar, toestaan/weigeren-uitkomst, authenticatieresolutie-metadata en billable-vlag. Als iemand later vraagt "wat deed deze agent dinsdag om 15:00?", reconstrueert u het antwoord uit die gegevens. Preventie mist soms iets. Het auditspoor laat zien wat er is gebeurd.
Wat we nog niet hebben opgelost
Zelfs met alles hierboven kan een agent met een legitieme chat:write nog steeds worden overgehaald om een gênant bericht te plaatsen in een kanaal waar hij al toegang toe heeft. De broker beperkt de schade; hij elimineert die niet.
Het andere deel van het antwoord is goedkeuring voor risicovolle acties, outputvalidatie en standaard wantrouwen van tooluitvoer. Dat werk staat op de roadmap, maar zit nog niet in het product. Wie beweert het confused deputy-probleem volledig te hebben opgelost, verkoopt u iets.
Dit zou de standaard moeten zijn, geen extraatje
Capability-based security bestaat al sinds de jaren zeventig. Brokered credentials staan in de OWASP LLM Top 10. Phantom tokens zijn ouder dan het LLM-tijdperk. Niets hiervan ontbreekt omdat niemand het antwoord wist. Het ontbreekt omdat vroege agentplatforms optimaliseerden voor "laat de demo werken" en beveiliging naar een latere release schoven, die vaak nooit kwam.
De volgende generatie platforms moet meer ambiëren. Tokens mogen niet in de modelcontext komen. Bevoegdheden moeten per agent worden gespecificeerd. Privilege-escalatie moet via een mens verlopen. Elke actie moet van begin tot eind te auditen zijn. Niets daarvan is nieuw. Alles zou de basis moeten zijn.
Als u een agentplatform kiest, komt u met "is het veilig?" nergens. Elke leverancier zegt ja. Een betere vraag: laat uw broker zien en leg uit wat er gebeurt als een agent om een scope vraagt die hij niet heeft.
De broker staat standaard voor elke agent op Zero. Connectorinventaris, scopemapping, permissiebeleid en brokerlogica staan allemaal in Zero's bronrepository. Een connector gevonden die we niet ondersteunen? Dien een issue in.
Referenties
Fundamenteel
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (het oorspronkelijke capability-systems-artikel)
- Mark Miller et al., Caja: capability-based security voor het web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Genoemde praktijkvoorbeelden
- PromptArmor, Google Antigravity Exfiltrates Data, november 2025
- Simon Willison, verslag en analyse, november 25, 2025
