Sikkerhed for AI-agenter starter med én regel: din AI-agent må aldrig opbevare dine legitimationsoplysninger. Her er det 38 år gamle mægler-mønster, der håndhæver det.
AI-agenter er forvirrede stedfortrædere. Det er et 38 år gammelt sikkerhedsmønster, og svaret er lige så gammelt: indsæt en mægler — et betroet, observerbart, deterministisk, reviderbart, uforfalskeligt, snævert afgrænset, politikstyret, ikke-AI mellemlag — mellem agenten og de SaaS-API'er, den skal kalde, og lad mægleren opbevare de legitimationsoplysninger, din agent ikke bør have.
I 1988 udgav Norm Hardy en kort artikel, hvor han beskrev en virkelig hændelse fra sin tid hos Tymshare. En Fortran-kompilator kaldet FORT lå i en systemmappe ved navn SYSX. For at indsamle brugsstatistik skulle kompilatoren skrive til (SYSX)STAT, så operativsystemet havde givet FORT en "home files license", der gav tilladelse til at skrive til enhver fil i SYSX. Systemets faktureringsfil, (SYSX)BILL, lå også der. En bruger, der kørte kompilatoren, kunne angive et filnavn for at modtage valgfri fejlsøgningsoutput. En dag angav en bruger (SYSX)BILL. Kompilatoren bad OS'et om at åbne den fil til skrivning; OS'et, der så home files license, tillod det. Faktureringsdataene blev overskrevet. Kompilatoren gjorde præcis, hvad den var designet til. Fejlen var arkitektonisk.
Hardy kaldte det the confused deputy problem: Et privilegeret program (stedfortræderen) har egen autoritet; en mindre privilegeret kalder beder det gøre noget; stedfortræderen bliver forvirret over, hvis autoritet den handler på, og bruger sin egen. Løsningen er at fjerne den autoritet fra stedfortræderen og placere den bag et separat lag, der formidler kaldet efter behov. Det lag er mægleren.
38 år senere er enhver AI-agent, din virksomhed kører, en forvirret stedfortræder. Og de fleste kører uden en mægler.
Hvorfor AI-agenter forværrer sikkerhedsproblemet
Hardys FORT havde én inputkanal: kommandolinjen. En moderne AI-agent har dusinvis: e-mail-indhold, hentede websider, uploadede PDF'er, værktøjsoutput fra MCP-servere, beskeder fra andre agenter i et multi-agent system. Alt, der lander i kontekstvinduet, kan afgive instruktioner, og agenten behandler dem alle som legitime.
Det bryder en antagelse, som traditionel adgangskontrol afhænger af: at kalderen kontrollerer inputtet. I en webapp kommer kalderen (den autentificerede session) og inputtet (HTTP-request body) fra samme sted. For en agent er kalderen den, der former prompten, hvilket betyder, at en angriber, der kan skrive en e-mail eller manipulere et søgeresultat, også er en kalder.
I november 2025 viste sikkerhedsforskere hos PromptArmor hvordan det ser ud i praksis. De skjulte ondsindede instruktioner i 1-punkts skrift på en integrationsvejledning. Da en udvikler pegede Googles Antigravity IDE på den, omgik agenten sin egen .gitignore-baserede filbeskyttelse ved at kalde cat. Derefter lækkede den indholdet af .env-filer til en angriberstyret webhook.site-URL via Antigravitys egen browser-underagent. Brugeren havde sat det korrekt op. Sandkassen holdt. Agenten kunne bare ikke skelne mellem, hvad brugeren bad om, og hvad inputtet instruerede den til at gøre.
Samme mønster som Hardys FORT, årtier senere: bred autoritet, utroværdigt input, ingen måde at adskille de to på.
Fællesskabet har svarene. De er bare spredte.
Dette er ikke et nyt problem. Sikkerhedsfællesskabet har skrevet svarene i årtier:
Kapabilitetsbaseret sikkerhed (Dennis & Van Horn, 1966; senere E-sproget og Mark Millers Caja-arbejde hos Google). Princippet: giv ikke implicit autoritet baseret på identitet eller placering; giv eksplicitte, uforfalskelige kapabiliteter for hver ressource, programmet må tilgå. En kapabilitet samler hvad du kan gøre med hvad du kan gøre det på, og kan ikke forveksles med andet.
Mæglerbaserede legitimationsoplysninger (kodificeret af OWASP LLM Top 10). Læg ikke API-tokens i LLM'ens kontekst. Et betroet mellemlag foretager kaldet på agentens vegne; modellen beslutter hvad der skal gøres, mægleren håndterer hvordan. Prompt-injektion, der beder modellen udskrive sine legitimationsoplysninger, får intet brugbart. Oplysningerne er der ikke.
Phantom Token-mønsteret (Curity, oprindeligt til OAuth i mikrotjenester). Agenten har kun et uigennemsigtigt sessionshåndtag, ikke det rigtige bearer-token. En proxy validerer håndtaget, indsætter den rigtige legitimationsoplysning ved netværksgrænsen og videresender opstrøms. Hvis agenten lækker sit miljø, får angriberen en streng, der udløber, når sessionen slutter.
Just-in-time legitimationsindsprøjtning (workload identity-systemer som Aembit). Opret en kortvarig, snævert afgrænset legitimationsoplysning pr. kald i stedet for at udstede langvarige tokens.
Intet af dette mangler i litteraturen. Det mangler i standarderne. De fleste agentplatforme giver stadig modellen et OAuth-token uden en mægler imellem og håber på det bedste.
Sådan fungerer Zeros mægler
Vi har ikke opfundet nogen af ovenstående mønstre. Vi har samlet dem i en enkelt mægler, der kører som standard for hver agent på Zero. Det er det betroede mellemlag, disse mønstre beskriver, bygget til en AI-agentplatform. Hvert kald, en agent foretager til en connector, går igennem den. Hver connector er én ekstern SaaS (Slack, GitHub, Notion osv.).
Mægleren sidder mellem hver agent og hver connector. Rigtige legitimationsoplysninger findes kun på mæglerens side af den stiplede linje.
Tænk på det som tre lag.
1. Isolering af legitimationsoplysninger
Agentens sandkasse opbevarer aldrig en rigtig connector-legitimationsoplysning. Når du forbinder en SaaS til Zero, lever OAuth-tokenet eller API-nøglen på mæglerens side. Sandkassen får en pladsholder-streng, der ligner en miljøhemmelighed nok til, at eksisterende værktøjer fortsat fungerer, men ingen opstrøms SaaS vil acceptere den.
Når agenten sender en anmodning til en registreret connector-vært, matcher mægleren anmodningen, løser connectorens auth-skabelon og indsætter den rigtige legitimationsoplysning ved netværksgrænsen. Anmodningen går opstrøms med gyldig auth; agenten havde aldrig noget brugbart. En prompt-injiceret agent, der dumper sine miljøvariabler, giver angriberen en pladsholder, ikke SaaS-tokenet.
Dette er phantom token-mønsteret anvendt på AI-agenter.
2. Connector-politikport
En connector i Zero bør være mere end en tænd/sluk-knap. Hver connector beskriver de API-baser, den dækker, og hvordan auth skal indsættes. Hvor opstrøms-tjenesten udgiver en stabil mapping fra scope til endpoint, kan den også beskrive, hvilken navngiven tilladelse der dækker hver metode og sti. Slacks slack-api-ref er et godt eksempel.
Så når en agent forbundet til Slack kalder chat.postMessage, kan mægleren matche anmodningen til chat:write. Når den læser revisionslogge, er det admin.analytics:read. For hver agent definerer permission_policies, hvordan disse navngivne tilladelser opfører sig: tillad, afvis eller spørg. Politikken håndhæves i mægleren før auth-indsprøjtning, ikke som et hint til modellen. Hvis agenten forsøger at foretage et kald dækket af en afvist tilladelse, måske fordi den blev prompt-injiceret, når kaldet aldrig op til netværket.
Ikke alle connectors får den opløsning i dag. Nogle opstrøms-API'er udgiver ikke en stabil mapping fra scope til endpoint. GitHubs GraphQL-overflade er det klassiske eksempel: REST-siden kan matches, men GraphQL-siden kan endnu ikke. For disse connectors kontrollerer mægleren stadig legitimationsindsprøjtning og netværksstien, mens tilladelsesporten falder tilbage til den grovere connector- eller værtspolitik, platformen faktisk kan håndhæve. Vi udfylder disse, efterhånden som opstrømsdata bliver tilgængelige. Vi påstår ikke dækning, vi ikke har bygget.
Tokens bærer ikke implicit autoritet. Autoritet mægles pr. agent, på det opløsningsniveau opstrøms understøtter. Det er den kapabilitetsbaserede del af svaret.
3. Operationel løkke og revision
Mindste privilegium virker kun, hvis fejlsituationen er brugbar. Agenter udvikler sig. Seks uger inde kan en forskningsagent, der startede med at læse fra Notion, få brug for at skrive et resumé tilbage. De typiske fejlsituationer andre steder: agenten kører tavst uden den nye tilladelse og fejler, eller operatøren overgiver for mange rettigheder i panik og får dem aldrig tilbage igen.
En afvist connector-anmodning returnerer en struktureret 403: connector, metode, sti, basis-URL og de matchende tilladelsesnavne, når mægleren kan identificere dem. Agentens systemprompt fortæller, hvordan den diagnosticerer afslaget og beder om præcis den tilladelse, den netop ramte, hvilket giver et ét-klik godkendelseslink til brugeren eller admin. Det holder eskalationsvejen knyttet til den præcise tilladelse, der anmodes om, i stedet for at ende med "giv bare alt".
Anmodninger om tilladelsesændringer havner i en kø. Ejere og administratorer kan godkende eller afvise dem fra dashboardet; godkendte anmodninger opdaterer agentens politik, og næste forsøg går igennem. De fleste platforme springer denne løkke over. Uden den forbliver "mindste privilegium" på præsentationssliden i stedet for at køre i produktion.
Samme mæglersti fodrer revisionen. Netværkslogs pr. run registrerer sandkassens netværksaktivitet på tværs af HTTP, TCP, DNS og lavere lag for ikke-TCP-trafik. Connector-matchede anmodninger inkluderer struktureret mægler-metadata: connector, matchet tilladelse når tilgængelig, tillad/afvis-udfald, auth-opløsningsmetadata og faktureringsflag. Hvis nogen senere spørger "hvad lavede denne agent tirsdag kl. 15?", kan du rekonstruere svaret fra disse poster. Forebyggelse overser ting. Revisionssporet er måden, du finder ud af det på.
Hvad vi ikke har løst
Selv med alt ovenstående kan en agent med en legitim chat:write stadig overtales til at poste en pinlig besked i en kanal, den allerede har adgang til. Mægleren indsnævrer skadesomfanget; den eliminerer det ikke.
Den anden halvdel af svaret er godkendelse af handlinger med høj risiko, outputvalidering og at behandle værktøjsresultater som utroværdige som standard. Det arbejde er på køreplanen, ikke i produktet endnu. Enhver, der påstår at have løst confused deputy-problemet end-to-end, sælger dig noget.
Dette bør være standard, ikke en funktion
Kapabilitetsbaseret sikkerhed har eksisteret siden 1970'erne. Mæglerbaserede legitimationsoplysninger er på OWASP LLM Top 10. Phantom tokens er ældre end LLM-æraen. Intet af dette mangler, fordi ingen kendte svaret. Det mangler, fordi tidlige agentplatforme optimerede for "få demoen til at virke" og udskød sikkerheden til en senere version, som ofte aldrig kom.
Næste generation af platforme bør sigte højere. Tokens bør ikke komme ind i modelkonteksten. Autoritet bør opregnes pr. agent. Privilegieeskalering bør gå gennem et menneske. Hver handling bør kunne revideres fra ende til anden. Intet af det er nyt. Alt det bør være grundlaget.
Når du vælger en agentplatform, kommer du ingen vegne med "er den sikker?". Alle leverandører siger ja. Et bedre spørgsmål: vis mig din mægler, og gennemgå hvad der sker, når en agent beder om et scope, den ikke har.
Mægleren sidder foran hver agent på Zero som standard. Connector-oversigt, scope-mapping, tilladelsespolitikker og mæglerlogik findes alle i Zeros kildekode-repository. Har du fundet en connector, vi ikke har dækket? Opret en sag.
Referencer
Grundlæggende
- 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 (det grundlæggende kapabilitetssystem-paper)
- Mark Miller m.fl., Caja: kapabilitetsbaseret sikkerhed til web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Virkelige hændelser nævnt
- PromptArmor, Google Antigravity Exfiltrates Data, november 2025
- Simon Willison, dækning og analyse, november 25, 2025
