Tre namn i samma uppdrag
Mira ber en AI-agent att hitta en mötestid med kollegorna. Det låter som en enda handling. För kalendern är det däremot en kedja: Mira ger ett uppdrag, agentprogrammet planerar arbetet, ett kalenderverktyg skickar anropet och kalendertjänsten avgör om anropet ska släppas igenom.
En handlande AI-agent är alltså mer än språkmodellen som formulerar ett svar. I NIST:s konceptpapper beskrivs en agentarkitektur som ett system som tar emot instruktioner, hämtar mer sammanhang, bearbetar det, kan utföra en handling och lämnar ett resultat.[2]
Kedjan blir lättare att granska om varje del har ett eget namn eller ID. Då kan kalendern se både att anropet kommer från agent 7 och att agenten arbetar åt Mira. Om allt i stället ser ut som ”Mira” går det efteråt inte att skilja hennes egna klick från agentens handlingar.
Inloggning svarar bara på första frågan
Att kontrollera en uppgiven identitet kallas autentisering. NIST beskriver det som att verifiera identiteten hos exempelvis en användare, process eller enhet. Behörighet, eller auktorisering, är nästa beslut: vilka resurser och handlingar får den autentiserade parten använda?[3]
Mira kan därför logga in helt korrekt samtidigt som agenten saknar rätt att skicka ett mejl. Inloggningen visar vem Mira är. Den säger inte i sig om agenten får läsa hela inkorgen, skapa utkast eller trycka på ”Skicka”.
Ett sätt att bära behörighetsbeslutet mellan tjänster är en åtkomsttoken. Tokenen visar att tillgång har delegerats, men namnet säger inte hur beviset ser ut: en token kan vara en signerad JWT, men kan också vara ogenomskinlig för programmet som använder den. IETF:s standard för tokenutbyte kan, när informationen finns i en JWT eller i svaret från en tokenkontroll, uttrycka både den part som företräds och den aktör som handlar. Den skiljer uttryckligen delegering, där agenten behåller sin egen identitet, från imitation, där handlingen ser ut att komma direkt från användaren.[4]
Det digitala passerkortet är en förenklad bild av en sådan lösning. I verkligheten kan identiteten och behörigheten ligga i flera uppgifter och kontrolleras av flera tjänster; en del uppgifter kan vara signerade. Den viktiga poängen är att ”agent 7 åt Mira” ska gå att bevara genom kedjan.
Ett uppdragspass ska vara litet
En säkerhetsprincip säger att varje användare eller process bara ska få de resurser och rättigheter som behövs för uppgiften. Principen kallas minsta privilegium. IETF:s aktuella säkerhetsråd för OAuth säger på samma sätt att ett åtkomstbevis bör begränsas till minsta nödvändiga behörighet och till den tjänst där det ska användas.[5]
För Miras uppdrag kan passet därför säga: använd kalenderverktyget, läs endast ledig/upptagen-information i arbetskalendern, föreslå tider men skapa inget möte och sluta gälla efter 30 minuter. RFC 9396 visar hur finmaskiga behörighetsuppgifter kan ange bland annat handlingar, platser och datatyper i stället för ett enda brett ord som ”kalenderåtkomst”.[6]
Vänster visas en bred huvudnyckel; höger visas ett uppdragspass med fyra angivna gränser.
Gränserna behöver kontrolleras där handlingen sker. RFC 9700 rekommenderar att åtkomstbevis binds till en bestämd mottagande tjänst, och RFC 8693 pekar ut snävt omfång och kort giltighet som skydd mot missbruk vid delegering.[7] Ett snyggt godkännandefönster hjälper alltså bara om kalendern faktiskt nekar allt som ligger utanför passet.
En underagent får inte sudda ut kedjan
Anta att mötesagenten lämnar deluppgiften ”hämta restider” till en annan agent. RFC 8693 har ett fält för den handlande aktören och kan även bära en kedja av tidigare aktörer. Därmed går det att uttrycka att trafikagenten handlar åt mötesagenten, som i sin tur handlar åt Mira.[8]
Representationen behöver följas av en regel i tjänsten som utfärdar nästa pass. En enkel säkerhetsregel är att en deluppgift får samma eller mindre räckvidd än uppdraget ovanför – aldrig mer.
Det betyder också att en underagent inte bör få Miras vanliga inloggningsuppgifter. Den ska få ett nytt, smalare pass för just restidsfrågan. När deluppgiften är klar kan det passet sluta gälla utan att resten av Miras konto påverkas.
Loggen är kvittot och återkallelse är stoppknappen
Ett granskningsbart system behöver spara vad som hände, när och var det hände, varifrån händelsen kom, vilket resultat den fick och vilka identiteter som var inblandade. Det är de grundfält som NIST SP 800-53 anger för revisionsposter.[9]
För ett agentuppdrag behövs dessutom sambandet till godkännandet. NIST:s agentkoncept lyfter därför fram loggning som knyter agentens handlingar till dess icke-mänskliga identitet och ger insyn i handlingar, data och resultat. Dokumentet frågar också hur agentens avsikt och kopplingen till mänskligt godkännande kan göras verifierbar.[10]
Ett konstruerat loggexempel kan då visa: Mira godkände tidsförslag klockan 14.00; agent 7 läste ledig/upptagen; kalendern nekade ett försök att läsa mötesrubriker; inget möte skapades. En nekad handling är viktig information, inte bara ett tekniskt fel.
Åtkomsten behöver också kunna stoppas innan sluttiden. NIST SP 800-53 tar upp både avstängning av utgångna eller avvikande konton och omedelbar återkallelse av rättigheter genom dynamisk behörighetsstyrning.[11] För användaren betyder det en synlig stoppknapp, inte en instruktion om att vänta tills agenten själv blir klar.
Byggstenarna är färdiga – agentreceptet är det inte
Flera viktiga delar är redan publicerade IETF-dokument: tokenutbyte med delegering i RFC 8693 från januari 2020, finmaskiga behörighetsuppgifter i RFC 9396 från maj 2023 och säkerhetsråd för OAuth i RFC 9700 från januari 2025. De två första är dokument på standards track och det tredje är en Best Current Practice.[12]
De dokumenten beskriver byggstenar för digitala tjänster i allmänhet, men bestämmer inte ensamma hur en AI-agent ska namnges, hur en föränderlig plan ska översättas till tillåtna handlingar eller hur en lång kedja av underagenter ska visas för en vanlig användare. Den 23 augusti 2026 beskrev NIST sin AI Agent Standards Initiative som arbete med framtida riktlinjer, öppna protokoll, forskning och branschledd standardisering. Det länkade identitetsdokumentet var märkt ”Draft”, och NCCoE-projektet stod i läget ”Reviewing Comments”. Det är därför mer korrekt att kalla NIST-materialet en riktning och ett planerat demonstrationsarbete än en färdig agentidentitetsstandard.[13]
NIST:s sammanställning av svar på en offentlig förfrågan från maj 2026 redovisar en bred samsyn bland svarande: grundläggande cybersäkerhetsprinciper är fortfarande relevanta för agenter, men behöver anpassas. Sammanställningen är en redovisning av inkomna synpunkter, inte ett bevis för att en viss lösning redan har blivit standard.[14]
NCCoE:s utkast pekar bland annat på OAuth, OpenID Connect, identiteter för programvarulaster, automatiserad livscykelhantering och regelbaserad åtkomstkontroll som möjliga byggdelar. Samma dokument ställer fortfarande öppna frågor om agentmetadata, stark autentisering, delegering, minsta privilegium och verifierbar loggning.[15]
Fem frågor före ”Tillåt”
En vanlig användare behöver inte bedöma alla protokoll. Det räcker långt att kräva tydliga svar innan en agent får tillgång till mejl, kalender, filer eller köp:
- Vem är agenten? Finns ett eget namn eller ID som skiljer den från mig och andra agenter?
- Vem företräder den? Syns det om uppdraget kommer från mig, min arbetsgivare eller en annan agent?
- Vad får den göra – och var? Är tjänst, handling och dataområde angivna var för sig?
- När slutar åtkomsten? Finns både en kort sluttid och en stoppknapp som fungerar direkt?
- Vilket kvitto får jag? Kan jag se godkännanden, utförda och nekade försök, resultat och vilka identiteter som deltog?
Minnesregeln är kort: namn, uppdrag, gräns, klocka, kvitto. En agent blir inte pålitlig bara för att den kan logga in. Den blir lättare att styra när varje handling kan kopplas till rätt agent, rätt uppdragsgivare, ett litet tillstånd, en sluttid och ett spår som går att läsa efteråt.
Källor
- NCCoE: Accelerating the Adoption of Software and AI Agent Identity and Authorization
- NCCoE: Software and AI Agent Identity and Authorization
- NIST: AI Agent Standards Initiative
- NIST: Summary Analysis of Responses to the RFI Regarding Security Considerations for AI Agents
- IETF: RFC 8693 – OAuth 2.0 Token Exchange
- IETF: RFC 9396 – OAuth 2.0 Rich Authorization Requests
- IETF: RFC 9700 – Best Current Practice for OAuth 2.0 Security
- NIST CSRC: authentication
- NIST CSRC: least privilege
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations