Sikkerhet for AI-agenter starter med én regel: AI-agenten din skal aldri ha dine påloggingsdetaljer. Her er det 38 år gamle mekler-mønsteret som håndhever dette.
AI-agenter er forvirrede stedfortredere. Det er et 38 år gammelt sikkerhetsmønster, og svaret er like gammelt: sett inn en mekler — et pålitelig, observerbart, deterministisk, reviderbart, uforfalskbart, avgrenset og policy-styrt, ikke-AI mellomlag — mellom agenten og de SaaS-API-ene den må bruke, og la mekleren holde påloggingsdetaljene agenten ikke skal ha.
I 1988 publiserte Norm Hardy en kort artikkel om en virkelig hendelse fra sin tid hos Tymshare. En Fortran-kompilator kalt FORT lå i en systemmappe ved navn SYSX. For å samle bruksstatistikk måtte kompilatoren skrive til (SYSX)STAT, så operativsystemet hadde gitt FORT en "home files license" som ga tillatelse til å skrive til alle filer i SYSX. Systemets faktureringsfil, (SYSX)BILL, lå også der. En bruker som startet kompilatoren kunne oppgi et filnavn for å få valgfri feilsøkingsutskrift. En dag oppga en bruker (SYSX)BILL. Kompilatoren ba OS-et åpne denne filen for skriving; OS-et, som så home files license, tillot det. Faktureringsdataene ble overskrevet. Kompilatoren gjorde nøyaktig det den var laget for. Feilen var arkitektonisk.
Hardy kalte det forvirret stedfortreder-problemet: Et privilegert program (stedfortrederen) har egen myndighet; en mindre privilegert innringer ber det gjøre noe; stedfortrederen blir forvirret over hvilken myndighet den handler på vegne av, og bruker sin egen. Løsningen er å fjerne denne myndigheten fra stedfortrederen og plassere den bak et eget lag som megler samtalen ved behov. Det laget er mekleren.
Trettiåtte år senere er hver AI-agent virksomheten din kjører en forvirret stedfortreder. Og de fleste kjører uten en mekler.
Hvorfor AI-agenter forverrer sikkerhetsproblemet
Hardys FORT hadde én inngangskanal: kommandolinjen. En moderne AI-agent har dusinvis: e-postinnhold, hentede nettsider, opplastede PDF-er, verktøyutdata fra MCP-servere, meldinger fra andre agenter i et multi-agent-system. Alt som havner i kontekstvinduet kan gi instruksjoner, og agenten behandler dem alle som legitime.
Det bryter en forutsetning tradisjonell tilgangskontroll bygger på: innringeren kontrollerer input. I en nettapp kommer innringeren (den autentiserte økten) og input (HTTP-forespørselen) fra samme sted. For en agent er innringeren den som former prompten, noe som betyr at en angriper som kan skrive en e-post eller manipulere et søkeresultat også er en innringer.
I november 2025 viste sikkerhetsforskere hos PromptArmor hvordan dette ser ut i praksis. De skjulte ondsinnede instruksjoner i 1-punkts skrift på en integrasjonsveiledning. Da en utvikler pekte Googles Antigravity IDE mot denne, omgås agenten sin egen .gitignore-baserte filbeskyttelse ved å bruke cat. Deretter lekket den innholdet i .env-filer til en angriperstyrt webhook.site-URL via Antigravitys egen nettleser-underagent. Brukeren hadde satt opp alt riktig. Sandkassen holdt. Agenten kunne bare ikke skille mellom hva brukeren ba om og hva inputen instruerte den til å gjøre.
Samme mønster som Hardys FORT, flere tiår senere: bred myndighet, upålitelig input, ingen måte å skille dem på.
Fellesskapet har svarene. De er bare spredt.
Dette er ikke et nytt problem. Sikkerhetsmiljøet har skrevet svar i flere tiår:
Kapabilitetsbasert sikkerhet (Dennis & Van Horn, 1966; senere E-språket og Mark Millers Caja-arbeid hos Google). Prinsippet: ikke gi generell myndighet basert på identitet eller plassering; gi eksplisitte, uforfalskbare kapabiliteter for hver ressurs programmet får bruke. En kapabilitet samler hva du kan gjøre med hva du kan gjøre det på, og kan ikke forveksles med noe annet.
Meklede påloggingsdetaljer (kodifisert av OWASP LLM Top 10). Ikke legg API-nøkler i LLM-ens kontekst. Et pålitelig mellomlag utfører kallet på agentens vegne; modellen bestemmer hva som skal gjøres, mekleren håndterer hvordan. Prompt-injeksjon som ber modellen skrive ut sine påloggingsdetaljer får ingenting nyttig. Påloggingsdetaljene er ikke der.
Phantom Token Pattern (Curity, opprinnelig for OAuth i mikrotjenester). Agenten har et ugjennomsiktig sesjonshåndtak, ikke den ekte bærertoken. En proxy validerer håndtaket, bytter inn ekte påloggingsdetaljer ved nettverksgrensen og videresender oppstrøms. Hvis agenten lekker sitt miljø, får angriperen en streng som utløper når økten avsluttes.
Just-in-time påloggingsinjeksjon (arbeidsbelastningsidentitetssystemer som Aembit). Opprett en kortvarig, avgrenset påloggingsdetalj per kall i stedet for å utstede langvarige nøkler.
Ingenting av dette mangler i litteraturen. Det mangler i standardoppsettet. De fleste agentplattformer gir fortsatt modellen en OAuth-nøkkel uten mekler imellom, og håper på det beste.
Slik fungerer Zeros mekler
Vi har ikke funnet opp noen av mønstrene over. Vi har koblet dem sammen i en enkelt mekler som kjører som standard for hver agent på Zero. Det er det pålitelige mellomlaget disse mønstrene beskriver, bygget for en AI-agentplattform. Hvert kall en agent gjør til en kobling går gjennom denne. Hver kobling er én ekstern SaaS (Slack, GitHub, Notion osv.).
Mekleren sitter mellom hver agent og hver kobling. Ekte påloggingsdetaljer finnes kun på meklerens side av den stiplede linjen.
Tenk på det som tre lag.
1. Isolasjon av påloggingsdetaljer
Agentens sandkasse har aldri en ekte koblingspåloggingsdetalj. Når du kobler en SaaS til Zero, lagres OAuth-tokenet eller API-nøkkelen på meklerens side. Sandkassen får en plassholder-streng som ligner nok på en miljøhemmelighet til at eksisterende verktøy fungerer, men ingen oppstrøms SaaS vil akseptere den.
Når agenten gjør en forespørsel til en registrert koblingsvert, matcher mekleren forespørselen, løser koblingens autentiseringsmal og injiserer ekte påloggingsdetaljer ved nettverksgrensen. Forespørselen går oppstrøms med gyldig autentisering; agenten hadde aldri noe nyttig. En prompt-injisert agent som dumper miljøvariablene sine gir angriperen en plassholder, ikke SaaS-nøkkelen.
Dette er phantom token-mønsteret, brukt på AI-agenter.
2. Policy-gate for koblinger
En kobling i Zero bør være mer enn en av/på-bryter. Hver kobling beskriver hvilke API-baser den dekker og hvordan autentisering skal injiseres. Der oppstrømstjenesten publiserer et stabilt mapping mellom scope og endepunkt, kan den også beskrive hvilken navngitt tillatelse som dekker hver metode og sti. Slacks slack-api-ref er et godt eksempel.
Så når en agent koblet til Slack kaller chat.postMessage, kan mekleren mappe denne forespørselen til chat:write. Når den leser revisjonslogger, er det admin.analytics:read. For hver agent definerer permission_policies hvordan disse navngitte tillatelsene oppfører seg: tillat, nekt eller spør. Policyen håndheves i mekleren før autentisering injiseres, ikke som et hint til modellen. Hvis agenten prøver å gjøre et kall dekket av en nektet tillatelse, kanskje fordi den ble prompt-injisert, når kallet aldri oppstrøms nettverk.
Ikke alle koblinger får denne oppløsningen i dag. Noen oppstrøms API-er publiserer ikke et stabilt mapping mellom scope og endepunkt. GitHubs GraphQL-overflate er det klassiske eksempelet: REST-siden kan mappes, men GraphQL-siden kan det ikke ennå. For disse koblingene kontrollerer mekleren fortsatt påloggingsinjeksjon og nettverksbanen, mens tillatelsesporten faller tilbake til en grovere koblings- eller vertsnivå-policy plattformen faktisk kan håndheve. Vi fyller inn disse etter hvert som oppstrømsdata blir tilgjengelig. Vi påstår ikke dekning vi ikke har bygget.
Nøkler gir ikke generell myndighet. Myndighet megles per agent, på det detaljnivået oppstrømstjenesten støtter. Det er den kapabilitetsbaserte delen av svaret.
3. Operasjonell sløyfe og revisjon
Minste privilegium fungerer bare hvis feilmønsteret er brukbart. Agenter vokser. Seks uker inn kan en forskningsagent som startet med å lese fra Notion trenge å skrive et sammendrag tilbake. Vanlige feilmønstre ellers: agenten kjører stille uten ny tillatelse og feiler, eller operatøren gir for mye tilgang i panikk og trekker det aldri tilbake.
En nektet koblingsforespørsel returnerer en strukturert 403: kobling, metode, sti, base-URL og de samsvarende tillatelsesnavnene når mekleren kan identifisere dem. Agentens systemprompt forteller hvordan den skal diagnostisere avslaget og hvordan den kan be om akkurat den tillatelsen den nettopp traff, og lager en ett-klikks godkjenningslenke for bruker eller admin. Det holder eskaleringsveien knyttet til nøyaktig den tillatelsen som etterspørres, i stedet for å bli til "gi tilgang til alt".
Tillatelsesendringsforespørsler havner i en kø. Eiendomshavere og administratorer kan godkjenne eller avvise dem fra dashbordet; godkjente forespørsler oppdaterer agentens policy, og neste forsøk går gjennom. De fleste plattformer hopper over denne sløyfen. Uten den forblir "minste privilegium" på presentasjonen i stedet for i produksjon.
Samme meklerbane gir revisjon. Nettverkslogger per kjøring registrerer sandkassens nettverksaktivitet på tvers av HTTP, TCP, DNS og lavere nivåer for ikke-TCP-trafikk. Koblingsmatchede forespørsler inkluderer strukturert meklermetadata: kobling, matchet tillatelse når tilgjengelig, tillat/nekt-resultat, metadata for autentiseringsoppløsning og fakturerbar flagg. Hvis noen senere spør "hva gjorde denne agenten tirsdag kl. 15?", kan du rekonstruere svaret fra disse loggene. Forebygging fanger ikke alt. Revisjonssporet viser hva som faktisk skjedde.
Hva vi ikke har løst
Selv med alt over kan en agent med legitim chat:write fortsatt overtales til å poste en pinlig melding i en kanal den allerede har tilgang til. Mekleren begrenser skadeomfanget; den eliminerer det ikke.
Den andre halvdelen av svaret er godkjenning for handlinger med høy risiko, validering av utdata og å behandle verktøyresultater som upålitelige som standard. Dette arbeidet står på veikartet, men er ikke i produktet ennå. Alle som hevder de har løst forvirret stedfortreder-problemet fra ende til ende, selger deg noe.
Dette bør være standard, ikke en funksjon
Kapabilitetsbasert sikkerhet har eksistert siden 1970-tallet. Meklede påloggingsdetaljer er i OWASP LLM Top 10. Phantom tokens er eldre enn LLM-æraen. Ingenting av dette mangler fordi ingen visste svaret. Det mangler fordi tidlige agentplattformer optimaliserte for "få demoen til å virke" og utsatte sikkerheten til en senere versjon, som ofte aldri kom.
Neste generasjon plattformer bør sikte høyere. Nøkler skal ikke inn i modellens kontekst. Myndighet bør listes per agent. Privilegier bør eskaleres via et menneske. Hver handling bør kunne revideres fra ende til ende. Ingenting av dette er nytt. Alt bør være grunnlaget.
Når du velger en agentplattform, kommer du ingen vei med "er den sikker?". Alle leverandører sier ja. Et bedre spørsmål: vis meg mekleren din, og forklar hva som skjer når en agent ber om et scope den ikke har.
Mekleren står foran hver agent på Zero som standard. Koblingsoversikt, scope-mappinger, tillatelsespolicyer og meklerlogikk finnes i Zeros kildekode. Fant du en kobling vi ikke har dekket? Opprett en sak.
Referanser
Grunnleggende
- 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 grunnleggende kapabilitetssystem-papiret)
- Mark Miller m.fl., Caja: kapabilitetsbasert sikkerhet for web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Virkelige hendelser nevnt
- PromptArmor, Google Antigravity Exfiltrates Data, november 2025
- Simon Willison, dekning og analyse, november 25, 2025
