AI-agentens säkerhet börjar med en regel: din AI-agent ska aldrig ha dina inloggningsuppgifter. Här är det 38 år gamla mäklarmönstret som upprätthåller det.
AI-agenter är förvirrade ställföreträdare. Det är ett 38 år gammalt säkerhetsmönster, och svaret är lika gammalt: sätt in en mäklare — ett pålitligt, observerbart, deterministiskt, granskningsbart, oförfalskbart, avgränsat och policystyrt, icke-AI-mellanlager — mellan agenten och de SaaS-API:er den behöver anropa, och låt mäklaren hålla de inloggningsuppgifter din agent inte ska ha.
År 1988 publicerade Norm Hardy en kort artikel om en verklig incident från sin tid på Tymshare. En Fortran-kompilator kallad FORT låg i en systemkatalog som hette SYSX. För att samla användningsstatistik behövde kompilatorn skriva till (SYSX)STAT, så operativsystemet hade gett FORT en "home files license" som tillät den att skriva till vilken fil som helst i SYSX. Systemets faktureringsfil, (SYSX)BILL, låg också där. En användare som körde kompilatorn kunde ange ett filnamn för att få valfri felsökningsutdata. En dag angav en användare (SYSX)BILL. Kompilatorn bad operativsystemet öppna den filen för skrivning; operativsystemet, som observerade home files license, tillät det. Faktureringsdata skrevs över. Kompilatorn gjorde exakt vad den var designad för. Felet var arkitektoniskt.
Hardy kallade det the confused deputy problem: ett privilegierat program (ställföreträdaren) har egen behörighet; en mindre privilegierad anropar det; ställföreträdaren blir förvirrad om vems behörighet den agerar på och använder sin egen. Lösningen är att ta bort den behörigheten från ställföreträdaren helt och lägga den bakom ett separat lager som förmedlar anropet vid behov. Det lagret är mäklaren.
Trettiåtta år senare är varje AI-agent ditt företag kör en förvirrad ställföreträdare. Och de flesta körs utan mäklare.
Varför AI-agenter förvärrar säkerhetsproblemet
Hardys FORT hade en inmatningskanal: kommandoraden. En modern AI-agent har dussintals: e-postmeddelanden, hämtade webbsidor, uppladdade PDF:er, verktygsutdata från MCP-servrar, meddelanden från andra agenter i ett multi-agent-system. Allt som hamnar i kontextfönstret kan ge instruktioner, och agenten behandlar dem alla som legitima.
Det bryter mot ett antagande som traditionell åtkomstkontroll bygger på: att anroparen kontrollerar inmatningen. I en webbapp kommer anroparen (den autentiserade sessionen) och inmatningen (HTTP-request body) från samma plats. För en agent är anroparen den som formar prompten, vilket innebär att en angripare som kan skriva ett mejl eller påverka ett sökresultat också är en anropare.
I november 2025 visade säkerhetsforskare på PromptArmor hur det ser ut i produktion. De gömde skadliga instruktioner i 1-punkters teckenstorlek på en integrationsguide. När en utvecklare riktade Googles Antigravity IDE mot den, kringgick agenten sitt eget .gitignore-baserade filskydd genom att köra cat. Sedan läckte den innehållet i .env-filer till en angriparkontrollerad webhook.site-URL via Antigravitys egen webbläsarunderagent. Användaren hade satt upp allt korrekt. Sandlådan höll. Agenten kunde bara inte skilja på vad användaren bad om och vad inmatningen sa åt den att göra.
Samma mönster som Hardys FORT, decennier senare: bred behörighet, opålitlig inmatning, inget sätt att separera dem.
Gemenskapen har svaren. De är bara utspridda.
Detta är inget nytt problem. Säkerhetsgemenskapen har skrivit svar i decennier:
Kapabilitetsbaserad säkerhet (Dennis & Van Horn, 1966; senare E-språket och Mark Millers Caja på Google). Principen: ge inte generell behörighet baserat på identitet eller plats; ge explicita, oförfalskbara kapabiliteter för varje resurs programmet får använda. En kapabilitet knyter vad du kan göra till vad du kan göra det på, och kan inte förväxlas med något annat.
Mäklade inloggningsuppgifter (kodifierat av OWASP LLM Top 10). Lägg inte API-tokens i LLM:ens kontext. Ett pålitligt mellanlager gör anropet åt agenten; modellen bestämmer vad som ska göras, mäklaren hanterar hur. Prompt-injektion som ber modellen skriva ut sina inloggningsuppgifter får inget användbart. Uppgifterna finns inte där.
Phantom Token Pattern (Curity, ursprungligen för OAuth i mikrotjänster). Agenten har ett otydligt sessions-ID, inte den riktiga bearer-token. En proxy validerar ID:t, byter in den riktiga uppgiften vid nätverksgränsen och skickar vidare. Om agenten läcker sin miljö får angriparen en sträng som upphör att gälla när sessionen avslutas.
Just-in-time credential injection (arbetsbelastningsidentitetssystem som Aembit). Skapa en kortlivad, avgränsad inloggningsuppgift per anrop istället för att utfärda långlivade tokens.
Inget av detta saknas i litteraturen. Det saknas i standardinställningarna. De flesta agentplattformar ger fortfarande modellen en OAuth-token, utan mäklare emellan, och hoppas på det bästa.
Så fungerar Zeros mäklare
Vi har inte uppfunnit något av ovanstående mönster. Vi har kopplat ihop dem i en enda mäklare som körs som standard för varje agent på Zero. Det är det pålitliga mellanlagret dessa mönster beskriver, byggt för en AI-agentplattform. Varje anrop en agent gör till en connector går genom den. Varje connector är en extern SaaS (Slack, GitHub, Notion, och så vidare).
Mäklaren sitter mellan varje agent och varje connector. Riktiga inloggningsuppgifter finns bara på mäklarens sida av den streckade linjen.
Tänk på det som tre lager.
1. Isolering av inloggningsuppgifter
Agentens sandlåda har aldrig en riktig connector-inloggningsuppgift. När du kopplar en SaaS till Zero, lagras OAuth-token eller API-nyckel på mäklarens sida. Sandlådan får en platshållarsträng som ser tillräckligt ut som en miljöhemlighet för att befintliga verktyg ska fungera, men ingen SaaS accepterar den.
När agenten gör en begäran till en registrerad connector-värd matchar mäklaren begäran, löser connectorns autentiseringsmall och injicerar den riktiga inloggningsuppgiften vid nätverksgränsen. Begäran går uppströms med giltig autentisering; agenten hade aldrig något användbart. En prompt-injicerad agent som dumpar sina miljövariabler ger angriparen en platshållare, inte SaaS-token.
Detta är phantom token-mönstret, tillämpat på AI-agenter.
2. Connector-policygrind
En connector i Zero ska vara mer än en av/på-knapp. Varje connector beskriver vilka API-baser den täcker och hur autentisering ska injiceras. Där upstream-tjänsten publicerar en stabil mappning mellan scope och endpoint kan den också beskriva vilken namngiven behörighet som täcker varje metod och sökväg. Slacks slack-api-ref är ett bra exempel.
Så när en agent kopplad till Slack anropar chat.postMessage kan mäklaren mappa den begäran till chat:write. När den läser granskningsloggar är det admin.analytics:read. För varje agent definierar permission_policies hur dessa namngivna behörigheter beter sig: tillåt, neka eller fråga. Policyn verkställs av mäklaren före autentiseringsinjektion, inte som en ledtråd till modellen. Om agenten försöker göra ett anrop som täcks av en nekad behörighet, kanske på grund av prompt-injektion, når anropet aldrig nätverket uppströms.
Alla connectors har inte den upplösningen idag. Vissa upstream-API:er publicerar inte en stabil scope-till-endpoint-mappning. GitHubs GraphQL-yta är det klassiska exemplet: REST-sidan kan mappas, men GraphQL-sidan kan det ännu inte. För dessa connectors styr mäklaren fortfarande autentiseringsinjektion och nätverkssökväg, medan behörighetsgrinden faller tillbaka på den grövre connector- eller värdpolicyn som plattformen faktiskt kan verkställa. Vi fyller på dessa när upstream-data blir tillgängliga. Vi påstår inte täckning vi inte byggt.
Tokens bär inte generell behörighet. Behörighet mäklas per agent, på den upplösning upstream stöder. Det är den kapabilitetsbaserade halvan av svaret.
3. Operativ loop och revision
Minsta privilegium fungerar bara om felhanteringen är användbar. Agenter växer. Sex veckor in kan en forskningsagent som började läsa från Notion behöva skriva tillbaka en sammanfattning. Vanliga fel på andra håll: agenten kör tyst utan den nya behörigheten och går sönder, eller så överbeviljar operatören i panik och återkallar aldrig.
En nekad connector-begäran returnerar en strukturerad 403: connector, metod, sökväg, bas-URL och matchande behörighetsnamn när mäklaren kan identifiera dem. Agentens systemprompt berättar hur den ska diagnostisera nekandet och hur den ska be om exakt den behörighet den just nekades, vilket ger en engångslänk för användaren eller administratören att bevilja. Det håller eskaleringen kopplad till exakt den begärda behörigheten istället för att bli "bevilja allt".
Begäran om behörighetsändring hamnar i en kö. Ägare och administratörer kan godkänna eller avslå dem från instrumentpanelen; godkända begäranden uppdaterar agentens policy och nästa försök går igenom. De flesta plattformar hoppar över denna loop. Utan den stannar "minsta privilegium" på presentationsbilden istället för att köras i produktion.
Samma mäklarväg matar revisionen. Nätverksloggar per körning registrerar sandlådans nätverksaktivitet över HTTP, TCP, DNS och lägre nivåers paketobservationer för icke-TCP-trafik. Connector-matchade anrop inkluderar strukturerad mäklar-metadata: connector, matchad behörighet när tillgänglig, tillåt/nekad-resultat, autentiseringsupplösningsmetadata och debiteringsflagga. Om någon senare frågar "vad gjorde denna agent på tisdag kl 15?" kan du återskapa svaret från dessa poster. Prevention missar saker. Revisionsspåret är hur du får veta vad.
Vad vi inte har löst
Även med allt ovan kan en agent med legitim chat:write fortfarande övertalas att posta ett pinsamt meddelande i en kanal den redan har tillgång till. Mäklaren minskar skadan; den eliminerar den inte.
Den andra halvan av svaret är godkännande av högriskåtgärder, utdata-validering och att behandla verktygsresultat som opålitliga som standard. Det arbetet är på väg, men inte i produkten än. Den som påstår sig ha löst confused deputy-problemet från början till slut säljer dig något.
Detta borde vara golvet, inte en funktion
Kapabilitetsbaserad säkerhet har funnits sedan 1970-talet. Mäklade inloggningsuppgifter finns i OWASP LLM Top 10. Phantom tokens är äldre än LLM-eran. Inget av detta saknas för att ingen visste svaret. Det saknas för att tidiga agentplattformar optimerade för "få demon att fungera" och sköt säkerheten till en senare version, som ofta aldrig kom.
Nästa generations plattformar bör sikta högre. Tokens ska inte hamna i modellens kontext. Behörighet ska specificeras per agent. Privilegieförhöjning ska gå via en människa. Varje åtgärd ska kunna granskas från början till slut. Inget av detta är nytt. Allt borde vara grundnivå.
När du väljer en agentplattform leder "är den säker?" ingenstans. Varje leverantör säger ja. En bättre fråga: visa mig din mäklare och gå igenom vad som händer när en agent ber om en behörighet den inte har.
Mäklaren sitter framför varje agent på Zero som standard. Connector-inventering, scope-mappningar, behörighetspolicys och mäklarlogik finns i Zeros källkodsförråd. Hittat en connector vi inte täcker? Skicka in ett ärende.
Referenser
Grundläggande
- 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 (den grundläggande kapabilitetssystemartikeln)
- Mark Miller m.fl., Caja: kapabilitetsbaserad säkerhet för webben, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Citerade verkliga incidenter
- PromptArmor, Google Antigravity Exfiltrates Data, november 2025
- Simon Willison, bevakning och analys, november 25, 2025
