PKIaaS för AI-infrastruktur och AI-agenter

AI-agenter är inte längre hypotetiska. De kommer att distribueras i produktionsmiljöer år 2026 för att automatisera arbetsflöden, köra API-anrop, modifiera konfigurationer, utlösa transaktioner och interagera med kritiska system i maskinhastighet och skala. Ett enda agentbaserat AI-arbetsflöde kan innebära att fem eller fler agenter skickar uppgifter mellan varandra, anropar externa API:er, läser från databaser och skriver till poster, allt utan en människa i loopen i varje steg.

Säkerhetsfrågan som de flesta organisationer som driftsätter dessa system inte har helt besvarad är: hur vet man vilken agent som gjorde vad, och hur bevisar man det? De flesta AI-agenter autentiserar idag mot API:er och tjänster med hjälp av statiska autentiseringsuppgifter: API-nycklar, klienthemligheter, delade tokens. Dessa autentiseringsuppgifter har inget identitetsanspråk utöver sitt strängvärde. De kan kopieras. De upphör inte att gälla automatiskt. De tillhandahåller ingen revisionslogg som binder en specifik åtgärd till en specifik agentinstans. Och enligt IBMs rapport om kostnaden för ett dataintrång från 2025 saknade 97 % av organisationerna som upplevde intrång som involverade AI-modeller AI-åtkomstkontroller.

Svaret på problemet med AI-agentidentitet är samma svar som löste problemet med maskinidentitet för servrar, enheter och arbetsbelastningar: kryptografisk identitet som stöds av en styrd certifikatutfärdare. PKI as a Service tillhandahåller CA-infrastrukturen som utfärdar unika, kortlivade, verifierbara identiteter till AI-agenter, vilket möjliggör mTLS för kommunikation mellan agenter, certifikatförankrad OAuth för delegeringskedjor och en revisionslogg som gör varje agentåtgärd kryptografiskt hänförbar till en specifik identitet.

Snabbt svar: Vad gör PKIaaS för AI-agentidentitet?

PKIaaS utfärdar ett unikt X.509-certifikat för varje AI-agent som kodar agentens identitet (dess namn, typ, distributionsmiljö, auktoriserad omfattning och utfärdande organisation). Certifikatet är kortlivat (minuter till timmar för tillfälliga agenter; 24 till 48 timmar för persistenta agenter), roteras automatiskt av identitetsinfrastrukturen och signeras av PKIaaS CA vars rot finns i förtroendepaketet för varje tjänst som agenten anropar. När agenten gör ett API-anrop presenterar den certifikatet; tjänsten verifierar det mot PKIaaS rot-CA; och anslutningen fortsätter endast om verifieringen lyckas. Varje certifikatutfärdande loggas i PKIaaS-granskningsloggen, vilket ger en kryptografiskt hänförbar post över vilken agent som var aktiv under vilket tidsfönster och vilka åtgärder den var auktoriserad att vidta.

Key Takeaways

• Statiska autentiseringsuppgifter (API-nycklar, klienthemligheter, delade tokens) kan inte ge ansvar för AI-agenter. De har inget identitetsanspråk utöver sitt strängvärde, kan kopieras och delas mellan agenter, upphör inte att gälla automatiskt och producerar ingen revisionslogg som binder en specifik åtgärd till en specifik agentinstans. Certifikatbaserad agentidentitet tillhandahåller alla dessa egenskaper strukturellt, inte genom en policy som kan kringgås.
• Även kortlivade AI-agenter som lanseras för en enda uppgift förtjänar en unik kryptografisk identitet. Ett certifikat med en giltighetsperiod på 30 minuter som utfärdats till en kortlivad agent innebär att om certifikatet på något sätt extraheras är det oanvändbart inom 30 minuter. Samma API-nyckel som ges till samma kortlivade agent är giltig tills någon manuellt roterar den, vilket kanske aldrig är fallet.
• Delegeringskedjans problem är det svåraste olösta identitetsproblemet inom agentbaserad AI. När agent A anropar agent B, som anropar ett verktyg som utlöser en transaktion, måste varje hopp i den kedjan vara kryptografiskt bevisbart tillbaka till en ansvarig människa eller principal. Certifikatbaserad identitet i kombination med OAuth 2.0 Token Exchange (RFC 8693) förankrat i dessa certifikat tillhandahåller den tekniska mekanismen för en verifierbar delegeringskedja.
• mTLS för agent-till-tjänst-kommunikation är AI-motsvarigheten till Zero Trust för arbetsbelastningar. En AI-agent som presenterar ett PKIaaS-utfärdat certifikat till ett API verifieras kryptografiskt innan någon begäran på applikationsnivå behandlas. En agent utan ett giltigt PKIaaS-certifikat avvisas på TLS-lagret, oavsett om den påstår sig vara en auktoriserad agent i applikationens nyttolast.
• Regelverket för AI-agenters identitet är i förändring. NIST:s NCCoE publicerade ett konceptdokument 2026 om programvara och AI-agenters identitet och auktorisering. ITU har inrättat en fokusgrupp för AI-agenters förtroende och identitet. EU:s AI-lags ansvarsskyldighet och krav på mänsklig tillsyn skapar implicita granskningsskyldigheter för agentbaserade AI-system. Certifikatbaserad identitet är den mest mogna tekniska mekanismen för att uppfylla dessa framväxande krav.

Problemet med AI-agentens identitet

AI-agenter skiljer sig från traditionell programvara i en kritisk säkerhetsdimension: de agerar autonomt. En webbserver hanterar förfrågningar; den initierar dem inte. En AI-agent gör båda. Den får ett mål, motiverar hur den ska uppnå det och vidtar åtgärder i flera system, API:er och verktyg i följd, utan mänsklig auktorisering i varje steg. Behörigheten att vidta dessa åtgärder delegerades till agenten vid driftsättningstillfället, och kontrollerna över vad agenten kan göra är vanligtvis grovkorniga: en API-nyckel med brett omfång, ett tjänstkonto med breda behörigheter eller en åtkomsttoken på systemnivå som aldrig var avsedd för den specifika agentens uppgift.

Detta skapar en klyfta mellan identitet och ansvar som växer med skalan. När en organisation använder tio AI-agenter är klyftan hanterbar: någon vet vad varje agent har tillgång till. När samma organisation använder tusen agenter över dussintals arbetsflöden kan ingen tillförlitligt svara: vilken agent gjorde det API-anropet klockan 2:47? Var den behörig att göra det? Hur bevisar jag att åtgärden vidtogs av agent A och inte av någon som erhöll agent A:s inloggningsuppgifter?

Palo Alto Networks rapport om identitetssäkerhetslandskapet 2026 fann ett förhållande på 109:1 mellan maskinidentiteter och mänskliga identiteter i företagsmiljöer. AI-agenter är den snabbast växande komponenten av den här typen av maskinidentiteter. Att hantera deras identiteter med samma statiska autentiseringsmodell som användes för tidig företagsprogramvara är inte en säkerhetsåtgärd; det är ett program för ansvarsackumulering.

Varför statiska autentiseringsuppgifter misslyckas för AI-agenter

Statiska autentiseringsuppgifter misslyckas för AI-agenter av samma anledningar som de misslyckas för alla maskinidentiteter, förstärkt av agenternas autonoma beteende:

Ingen identitetsbindning. En API-nyckel bevisar att anroparen innehar nyckeln, inte att anroparen är den auktoriserade agenten. Om nyckeln extraheras från agentens miljö är alla processer med nyckeln oskiljbara från agenten. I en miljö där agenter interagerar med andra agenter (skicka kontext, delegera deluppgifter, dela tillfällig åtkomst) mångdubblas möjligheten till utdrag av autentiseringsuppgifter med varje interaktion mellan agenter.

Inget automatiskt utgångsdatum. API-nycklar löper inte ut om inte någon uttryckligen roterar dem. En AI-agent som är avaktiverad lämnar sin API-nyckel giltig tills driftteamet märker och återkallar den. I en snabbföränderlig miljö där agenter provisioneras och avprovisioneras för specifika uppgifter ackumuleras problemet med överblivna autentiseringsuppgifter snabbt. Ett certifikat som utfärdats till en agent med en giltighetsperiod på 4 timmar löper ut med agenten, vilket inte ger någon överblivna autentiseringsuppgifter och ingen rensningsskyldighet.

Ingen oavvisande funktion. Om en AI-agent orsakar skada genom att anropa ett API som den inte borde ha anropat, eller genom att utlösa en transaktion med felaktiga parametrar, identifierar API-nyckeln i revisionsloggen inte slutgiltigt vilken agent som gjorde anropet om nyckeln delades eller om nyckelns förvaring inte spårades. Ett X.509-certifikat med ett specifikt serienummer, utfärdat till en specifik agentdistribution, ger oavvisande funktion: revisionsloggposten refererar till certifikatet, PKIaaS-revisionsloggen registrerar när certifikatet utfärdades och till vilken agentidentitet, och attributionskedjan är kryptografiskt komplett.

X.509-certifikat som AI-agentidentitet

Ett X.509-certifikat utfärdat av en PKIaaS CA till en AI-agent kodar agentens identitet i ett kryptografiskt verifierbart, standardiserat format. Certifikatets fält Subject Distinguished Name och Subject Alternative Name innehåller agentens identitetsattribut. Ett väl utformat agentidentitetscertifikat kan koda:

• CN (Vanligt namn): Agentens namn och versionsidentifierare (till exempel order-processing-agent-v2.1)
• O (Organisation): Affärsenheten eller teamet som äger agenten
• OU (Organisationsenhet): Distributionsmiljön (produktion, staging, sandlåda)
• URI SAN: Ett SPIFFE-ID om agenten är distribuerad i en SPIFFE-kompatibel miljö (spiffe://trust-domain/agents/order-processing)
• Anpassade OID-tillägg: Agentversion, auktoriserat arbetsflödesomfång eller distributions-ID i anpassade X.509-tillägg om agentauktoriseringsmodellen kräver policyattribut i certifikatet

Certifikatet signeras av PKIaaS CA, vilket gör det verifierbart av alla tjänster som har PKIaaS-rot-CA-certifikatet i sitt förtroendepaket. Den privata nyckeln som motsvarar certifikatet genereras i agentens exekveringsmiljö och lämnar den aldrig. PKIaaS CA signerar certifikatet baserat på agentens CSR (Certificate Signing Request), som innehåller den publika nyckeln. Den privata nyckeln passerar aldrig genom PKIaaS CA, hemlighetshanteraren eller någon delad infrastruktur; den finns endast i agentens säkra minne under certifikatets giltighetstid.

Agentidentitetsprovisionering vid lansering

Flödet för agentidentitetsprovisionering fungerar enligt följande. När en agent startas (oavsett om det är en container i Kubernetes, en serverlös funktion, en process på en virtuell maskin eller ett tillfälligt beräkningsjobb) begär provisioneringssteget ett certifikat från PKIaaS CA. Begäran autentiseras med hjälp av en av flera mekanismer:

• OIDC-tokenutbyte: AI-orkestreringsplattformen utfärdar en kortlivad OIDC-token till agenten vid lanseringstillfället. Agenten presenterar denna token för PKIaaS ACME-slutpunkten (med extern kontobindning) och får ett certifikat i utbyte. GitHub Actions, GitLab CI, AWS STS, Azure AD Workload Identity och GCP Workload Identity utfärdar alla OIDC-tokens som kan tjäna detta syfte. OIDC-token är bootstrap-autentiseringsuppgifterna; certifikatet är den operativa autentiseringsuppgifter som agenten använder för sitt faktiska arbete.
• Plattformsbekräftelse: I Kubernetes-miljöer attesterar SPIRE agentens pod-identitet med hjälp av Kubernetes nodattestering och pod-väljare, och utfärdar sedan ett SVID (SPIFFE Verifiable Identity Document) till agenten direkt via SPIFFE Workload API. Med PKIaaS som SPIRE uppströms CA länkas detta SVID till PKIaaS-roten.
• Bootstrap för hemlighetshanterare: För agenter som inte är i Kubernetes innehar en auktoriserad hemlighetshanterare (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) en engångsregistreringsautentiseringsuppgift som agenten använder för att autentisera sin första certifikatbegäran. Registreringsuppgiften förbrukas vid användning och agentens efterföljande åtgärder använder det utfärdade certifikatet.

mTLS för agent-till-tjänst och agent-till-agent-kommunikation

När en agent har ett PKIaaS-utfärdat certifikat använder den det certifikatet för ömsesidig TLS-autentisering med varje tjänst den anropar. mTLS för kommunikation mellan agenter och tjänster tillhandahåller två säkerhetsegenskaper som statiska autentiseringsuppgifter inte kan:

Tjänstverifiering av agenten: Agenten verifierar tjänstens TLS-certifikat mot PKIaaS-rot-CA:ns förtroendepaket innan någon data skickas. En AI-agent som anropar en förfalskad API-slutpunkt (en man-in-the-middle-attack avsedd att stjäla agentkontext eller manipulera agentåtgärder) upptäcks vid TLS-handskakningen eftersom den förfalskade slutpunkten inte kan presentera ett certifikat som signerats av PKIaaS-CA:n. Agentens begäran når aldrig ett system som den inte har kryptografiskt verifierat.

Agentverifiering av tjänsten: Tjänsten verifierar agentens certifikat mot PKIaaS-rot-CA:s förtroendepaket innan någon begäran behandlas. En obehörig agent eller en komprometterad process som försöker utge sig för att vara en agent kan inte uppvisa ett giltigt PKIaaS-utfärdat certifikat (certifikatet är kryptografiskt bundet till den privata nyckel som genererades i den legitima agentens exekveringskontext). Tjänsten avvisar anslutningen innan någon logik på applikationsnivå exekveras.

För kommunikation mellan agenter i arbetsflöden med flera agenter gäller samma mTLS-mönster. Agent A presenterar sitt certifikat för agent B; agent B verifierar det mot PKIaaS-roten; agent B presenterar sitt certifikat för agent A; agent A verifierar det. Ingen av agenterna kan imiteras av en process som inte innehar motsvarande privata nyckel.

Certifikatbaserad OAuth: Säkra agentauktoriseringsflöden

Många AI-agenter interagerar med API:er som använder OAuth 2.0 för auktorisering. Standardmönstret för OAuth för maskinklienter är beviljandet av klientuppgifter: klienten (agenten) presenterar ett klient-ID och en klienthemlighet för att få en åtkomsttoken. Klienthemligheten är en statisk autentiseringsuppgift med alla problem som beskrivs ovan.

Certifikatbaserad OAuth ersätter klienthemligheten med agentens X.509-certifikat. I det här mönstret, som använder OAuth 2.0 Mutual-TLS Client Authentication (RFC 8705), autentiserar agenten sig mot OAuth-auktoriseringsservern med hjälp av sitt PKIaaS-utfärdade certifikat i TLS-handskakningen (mTLS-klientautentisering) istället för att presentera en klienthemlighet i begäran. Auktoriseringsservern verifierar certifikatet mot PKIaaS CA-förtroendepaketet och utfärdar en åtkomsttoken som är bunden till certifikatets fingeravtryck. Denna åtkomsttoken är endast giltig när den presenteras tillsammans med certifikatet som användes för att hämta den: bärartoken och klientcertifikatet måste matcha, vilket gör stulna åtkomsttokens värdelösa utan motsvarande privata nyckel.

För arbetsflöden med flera agenter möjliggör OAuth 2.0 Token Exchange-specifikationen (RFC 8693) för agenter att erhålla åtkomsttokens som kodar delegeringskedjan: Agent B kan begära en token som bevisar att den agerar under behörighet delegerad från Agent A, vilken auktoriserades av användaren eller systemansvarig som initierade arbetsflödet. Kombinerat med certifikatbaserad autentisering vid varje hopp blir delegeringskedjan kryptografiskt verifierbar: varje åtkomsttoken i kedjan är kopplad till ett specifikt certifikat, varje certifikat utfärdades av PKIaaS CA till en specifik agentidentitet, och PKIaaS-granskningsloggen registrerar utfärdandehistoriken.

Delegeringskedjans problem i arbetsflöden med flera agenter

Den tekniskt mest komplexa identitetsutmaningen inom agentisk AI är delegeringskedjan: när agent A delegerar en uppgift till agent B, som anropar ett verktyg som utlöser en betalning i ett finansiellt system, behöver varje system i den kedjan känna till den auktoritetskedja som producerade den slutliga åtgärden. Utan kryptografiska delegeringskedjor ser det finansiella systemet bara "Agent B gjorde denna begäran" utan att veta att agent B agerade under agent A:s auktoritet, som beviljades av en mänsklig arbetsflödesägare, vilken omfattades av en organisationspolicy.

Detta är viktigt av tre skäl. För det första, auktorisering: det finansiella systemet måste verifiera att den yttersta auktoriteten i kedjan (den mänskliga eller organisatoriska huvudmannen) hade rätt att auktorisera den betalning som agent B begär. För det andra, ansvarsskyldighet: när revisorn frågar vem som auktoriserade en specifik transaktion måste svaret kunna spåras genom varje agent i kedjan tillbaka till ett beslut som var mänskligt ansvarigt. För det tredje, inneslutning: om agent B komprometteras eller är felkonfigurerad är omfattningen av skadan begränsad till vad delegeringskedjan auktoriserar, inte till allt som agent B:s API-nyckel har åtkomst till.

Den tekniska mekanismen för kryptografiska delegeringskedjor kombinerar certifikatbaserad identitet med tokenutbyte. Agent A har ett PKIaaS-certifikat som kodar dess identitet. Agent A autentiserar sig mot auktoriseringsservern med hjälp av det certifikatet och erhåller en åtkomsttoken som är kopplad till dess auktoriserade arbetsflöde. När agent A delegerar till agent B använder den RFC 8693 Token Exchange för att erhålla en delegerad åtkomsttoken för agent B, som kodar både agent A:s identitet och agent B:s identitet (och delegeringens omfattningsbegränsningar). Agent B använder sitt eget PKIaaS-certifikat för mTLS-autentisering när denna delegerade token presenteras. Alla systemanrop från agent B kan verifiera hela delegeringskedjan från tokenets anspråk och från certifikatet som presenteras i mTLS-handskakningen.

Säkra AI-infrastruktur: Bortom agentidentitet

AI-agentidentitet är det mest synliga PKI-användningsfallet för AI-infrastruktur, men inte det enda. Infrastrukturen som stöder AI kräver också PKI-baserad säkerhet.

Modellserverinfrastruktur

AI-modellens inferensslutpunkter (oavsett om de är lokalt, i molnleverantörers ML-plattformar eller via API-tjänster) fungerar som backends som agenter frågar efter. Dessa slutpunkter behöver TLS-certifikat för säker transport, och i miljöer där endast auktoriserade agenter ska kunna anropa inferensslutpunkter måste inferensslutpunkten också verifiera agentens identitet (mTLS på inferens-API-lagret). En PKIaaS CA som utfärdar certifikat till både inferensinfrastrukturen och agenterna skapar förtroenderoten för denna dubbelriktade verifiering.

Utbildning och finjustering av infrastruktur

AI-modellträning och finjusteringsinfrastruktur hanterar känsliga data: träningsdataset, modellviktningar, utvärderingsresultat och feedbackdata. Kommunikation mellan komponenter i träningsinfrastrukturen (dataladdare, beräkningsnoder, modellkontrollpunktslagring, experimentspårningstjänster) bör använda TLS-certifikat utfärdade av organisationens PKIaaS CA snarare än självsignerade certifikat. Detta säkerställer att träningsinfrastrukturens interna kommunikation autentiseras och krypteras under organisationens förtroendehierarki, och att granskningsloggar fångar certifikatidentiteten för varje komponent som är involverad i modellträningen.

Modellartefaktsignering

AI-modellartefakter (vikter, konfigurationsfiler, promptmallar, verktygsdefinitioner) bör signeras med kodsigneringscertifikat utfärdade av PKIaaS CA. En modellartefakt som har signerats av organisationens PKIaaS CA kan verifieras som autentisk (producerad av organisationens auktoriserade modellutvecklingsprocess) och omodifierad (signaturen är ogiltig om artefakten har manipulerats efter signering). Detta är AI:s motsvarighet till säkerhet i programvaruleveranskedjan: precis som kodsignering säkerställer att distribuerad programvara producerades av en auktoriserad byggpipeline, säkerställer modellartefaktsignering att distribuerade modeller producerades av en auktoriserad utbildnings- eller finjusteringspipeline.

Agentramverkets infrastruktur

Infrastrukturkomponenterna i agentbaserade AI-ramverk (orkestratörer, minneslagrar, verktygsregister, API:er för agenthantering, observationsplattformar) är själva tjänster som agenter och operatörer interagerar med. Dessa komponenter bör ha TLS-certifikat utfärdade av PKIaaS CA, och de API:er de exponerar bör kräva mTLS-autentisering från de agenter och operatörer som anropar dem. Ett orkestrerings-API som vilken oautentiserad process som helst kan anropa är inte ett säkert orkestreringslager; det är en sårbarhet i kontrollplanet som väntar på att utnyttjas av en agent vars autentiseringskontext har manipulerats.

Maskinidentitetsinventering för AI-agenter

Utmaningen med maskinidentitetsinventering som beskrivs i tidigare inlägg om arbetsbelastningsidentitet är akut för AI-agenter eftersom agenter distribueras och avprovisioneras snabbare än traditionella arbetsbelastningar. En agentbaserad AI-plattform kan starta hundratals agenter per timme, var och en med ett unikt certifikat. Utan en maskinidentitetsinventering som spårar vilka certifikat som har utfärdats till vilka agenter, och vilka agenter som fortfarande är aktiva respektive avaktiverade, förlorar organisationen insyn i sin AI-agentidentitetsegendom nästan omedelbart efter att distributionen påbörjats i stor skala.

En CLM-plattform ansluten till PKIaaS CA tillhandahåller maskinidentitetsinventeringen för AI-agenter: varje certifikatutfärdande registreras med agentens identitetsattribut, utfärdandets tidsstämpel, giltighetsperioden och PKIaaS-granskningsloggposten som länkar certifikatet till utfärdandebegäran. För agentcertifikat med kort livslängd (1 timme till 24 timmar) visar inventeringen den aktuella aktiva agentpopulationen: vilka agenter som har certifikat som för närvarande är giltiga och vilka certifikat som har löpt ut (och motsvarande agenter ska inte längre vara aktiva). Om CLM-inventeringen visar ett aktivt certifikat för en agent vars distribution har avslutats, är det en signal om att agentens uppsägning inte inkluderade korrekt rensning av autentiseringsuppgifter eller att certifikatet exfiltrerades innan agenten avslutades.

För styrning av AI-agenter tillhandahåller CLM-inventeringen även policytillämpning: certifikat som utfärdas till AI-agenter som överskrider den maximalt tillåtna giltighetsperioden, som utfärdas till agenter med namngivningskonventioner som bryter mot organisationens policy, eller som utfärdas till agenter i miljöer de inte är behöriga att verka i, framträder alla som policyöverträdelser som kan flaggas för åtgärd innan agenten orsakar en incident.

Revisionsspåret: Att göra AI-åtgärder attributbara

Ett av styrningskraven för agentbaserad AI i reglerade miljöer är att AI-åtgärder måste vara tillskrivbara: när en AI-agent fattar ett beslut, ändrar en post eller utlöser en transaktion måste det finnas en granskningsbar registrering av vilken agent som fattade beslutet, under vems auktoritet och under vilket tidsfönster. Certifikatbaserad agentidentitet tillhandahåller denna tillskrivning på infrastrukturnivå snarare än att förlita sig på loggning på applikationsnivå som agenterna själva kontrollerar.

Attribueringskedjan fungerar enligt följande. PKIaaS CA utfärdar ett certifikat till agent X vid tidpunkt T med serienummer S, giltigt i 4 timmar. Agent X använder detta certifikat för att autentisera mot transaktions-API:et. Transaktions-API:ets åtkomstlogg registrerar klientcertifikatets serienummer S och information om begäran. PKIaaS-granskningsloggen registrerar att certifikat S utfärdades till agentidentiteten "order-processing-agent-v2.1/production" vid tidpunkt T med en giltighetstid på 4 timmar. Genom att kombinera de två loggarna får man en fullständig attribution: "Klockan 14:32:07 anropade order-processing-agent-v2.1-instansen i produktionsmiljön (certifikat S, utfärdat kl. 14:00:00) transaktions-API:et och initierade betalningstransaktion #4472."

Denna attribution är kryptografiskt obestridlig: certifikatets serienummer i åtkomstloggen motsvarar en specifik privat nyckel som genererades i den specifika agentinstansens exekveringskontext. Ingen annan process kunde ha presenterat certifikat S utan att inneha motsvarande privata nyckel, och den privata nyckeln genererades i agentens minne, inte lagrades någonstans där en annan process kunde komma åt den. Attributionen är inte beroende av agentens egen loggning, vilket en motståndare som har komprometterat agenten skulle kunna ändra.

Framväxande regleringssignaler för AI-agentidentitet

Regelverket för AI-agenters identitet är i sin linda men utvecklas snabbt. Flera signaler från 2025 och 2026 indikerar riktningen:

NIST NCCoE (2026): NIST National Cybersecurity Center of Excellence publicerade ett konceptdokument år 2026 om identitet och auktorisering av programvara och AI-agenter, vilket indikerade att formell vägledning om kryptografisk identitet för AI-agenter är under utveckling från det primära amerikanska standardiseringsorganet för cybersäkerhet. Organisationer som bygger certifikatbaserad agentidentitet nu ligger före vad som sannolikt kommer att bli en formell rekommendation.

ITU-fokusgrupp: Internationella telekommunikationsunionen inrättade en fokusgrupp år 2026 om förtroende och identitet för AI-agenter, med mandat att utveckla internationella ramverk för agentidentitet och ansvarsskyldighet. Detta signalerar att AI-agentidentitet behandlas som ett problem på internationell standardnivå, inte bara ett leverantörsspecifikt implementeringsval.

Ansvarsskyldighetskrav enligt EU:s AI-lag: EU:s AI-lag, som fasades in från och med augusti 2024, kräver att AI-system som klassificeras som högrisk ska föra loggar över verksamheten som är tillräckliga för mänsklig tillsyn och ansvarsskyldighet i efterhand. För agentbaserade AI-system som vidtar autonoma åtgärder i högriskkategorier (anställningsbeslut, kreditvärdering, hantering av kritisk infrastruktur) uppfylls ansvarsskyldighetskravet enklast genom kryptografisk tillskrivning av agentåtgärder, vilket certifikatbaserad identitet tillhandahåller.

Förväntningar på AI-styrning av finanssektorn: EBA (Europeiska bankmyndigheten) och andra tillsynsmyndigheter inom finanssektorn införlivar AI-styrning i riktlinjerna för IKT-riskhantering. För finansinstitut som använder AI-agenter för att automatisera handel, kreditbeslut, kundservice eller bedrägeriupptäckt inkluderar förväntningarna på AI-styrning granskningsbarhet av automatiserade beslut, vilket kräver tillskrivbara agentidentiteter.

Hur krypteringskonsulting kan hjälpa

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande tillhandahåller CA-infrastrukturen för AI-agentidentitet: ACME+EAB för OIDC-baserad agentcertifikatprovisionering, REST API för direkt integration med AI-orkestreringsplattformar, SPIFFE uppströms CA-plugin för Kubernetes-baserade agentdistributioner och certifikatprofiler utformade för kortlivad, efemär agentidentitet (giltighetstid från 15 minuter till 4 timmar). Kontakta oss på Krypteringskonsulting för att diskutera er arkitektur för AI-agentens identitet.
• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare tillhandahåller maskinidentitetsinventeringslagret för AI-agentcertifikat: kontinuerlig identifiering av PKIaaS-utfärdade agentcertifikat, övervakning av utgångsdatum med spårning av aktiva agenter, policytillämpning för certifikatgiltighetsperioder och namngivningskonventioner, och SIEM-integration som matar agentcertifikatens livscykelhändelser in i säkerhetsövervakningsstacken tillsammans med API-gatewayåtkomstloggar för attributionskorrelationen som beskrivs i det här inlägget.
• CBOM-säker: För organisationer som utvärderar sin AI-infrastrukturs kryptografiska ställning innan de distribuerar certifikatbaserad agentidentitet, Encryption Consultings CBOM-säkerhet tillhandahåller kryptografisk identifiering som avslöjar befintliga statiska autentiseringsuppgifter (API-nycklar, tokens, klienthemligheter) som används av AI-agenter och infrastruktur, vilket möjliggör prioriterad migrering från statiska autentiseringsuppgifter till certifikatbaserad identitet.
• PKI-tjänster: För organisationer som utformar AI-agentidentitetsarkitekturen från grunden, inklusive konfiguration av OIDC-tokenutbyte, design av certifikatprofiler för agentidentitetsattribut, mTLS-konfiguration för inferensslutpunkter och orkestrerings-API:er, samt design av delegeringskedjor med RFC 8693 Token Exchange, Encryption Consultings PKI-tjänster ge arkitekturrådgivning och implementeringsstöd genom varje komponent i agentidentitetsprogrammet.
• Rådgivningstjänster för efterlevnad: För organisationer inom reglerade sektorer som använder agentbaserad AI (finansiella tjänster enligt DORA, hälso- och sjukvård enligt HIPAA, federala myndigheter enligt FISMA/FedRAMP eller EU-enheter enligt AI-lagen), Encryption Consultings Rådgivning om efterlevnad kartlägga AI-agentens identitetsarkitektur mot tillämpliga regulatoriska ansvars- och granskningskrav, och ta fram ett ramverk för efterlevnadsbevis som visar hur certifikatbaserad agentidentitet uppfyller de relevanta skyldigheterna.

Slutsats

AI-agenter är maskiner. De behöver maskinidentitet. Tekniken för kryptografisk maskinidentitet har produktionstestats i årtionden inom PKI; det nya är att den tillämpas på en klass av maskiner som är snabbare, mer autonoma och mer betydelsefulla än traditionella arbetsbelastningar. En AI-agent som modifierar konfigurationer, utlöser betalningar eller interagerar med kritiska system bör inte vara mindre välidentifierad än en webbserver eller en domänansluten bärbar dator. Den bör identifieras mer noggrant, eftersom konsekvenserna av en oidentifierad eller imiterad AI-agent inte är ett 503-fel; de är autonoma åtgärder som vidtas med fel auktorisering.

PKIaaS tillhandahåller CA-infrastrukturen för att utfärda unika, kortlivade, verifierbara identiteter till AI-agenter i den skala och hastighet som agentbaserade AI-distributioner kräver. Mönstren, OIDC-tokenutbyte för provisionering, SPIFFE/SPIRE för Kubernetes-baserade agenter, mTLS för agent-till-tjänst-kommunikation, certifikatbaserad OAuth för auktoriseringsflöden och RFC 8693 Token Exchange för delegeringskedjor, är alla produktionsklara idag. Arbetet ligger i att konfigurera och integrera dem med de specifika AI-orkestreringsplattformar och infrastruktur som organisationen använder.

De organisationer som bygger in certifikatbaserad AI-agentidentitet i sina agent-AI-program nu, innan agentdistributionerna skalar upp förbi den punkt där eftermontering är praktisk, kommer att ha den revisionslogg, ansvarsskyldighet och åtkomstkontroller som tillsynsmyndigheter rör sig mot och som säkerhetsteam så småningom kommer att kräva. De organisationer som väntar tills ett regelkrav tvingar fram problemet kommer att eftermontera identitetsinfrastruktur på en distribuerad agentpopulation som utformades utan den.

Om din organisation använder AI-agenter och vill utforma en certifikatbaserad identitetsarkitektur för dem, kontakta Encryption Consulting.

Detta inlägg granskas var sex månader och när NIST, ITU, implementeringsförordningar för EU:s AI-lag eller större AI-ramverk för agenter publicerar väsentliga uppdateringar av krav eller rekommendationer för AI-agenters identitet.

Vanliga frågor om partihandel med mat och dryck

Varför behöver AI-agenter kryptografisk identitet snarare än API-nycklar?

API-nycklar är statiska, delbara, löper inte ut automatiskt och ger inget kryptografiskt bevis på vilken specifik agent som använde dem. Ett PKIaaS-utfärdat X.509-certifikat är kortlivat, kryptografiskt bundet till den specifika agentens exekveringskontext, oförnekanligt och roteras automatiskt. Ett stulet certifikat är värdelöst efter giltighetsperioden; en stulen API-nyckel är användbar tills den roteras manuellt. IBMs rapport Cost of Data Breach 2025 fann att 97 % av organisationerna som upplevde AI-modellintrång saknade AI-åtkomstkontroller.

Vad är problemet med delegeringskedjan för AI-agenter?

I arbetsflöden med flera agenter delegerar agent A uppgifter till agent B, som anropar verktyg och utlöser transaktioner. Varje hopp måste vara kryptografiskt bevisbart tillbaka till en ansvarig principal. Utan kryptografiska delegeringskedjor kan vilken agent som helst göra anspråk på vilken auktorisering som helst. Certifikatbaserad identitet i kombination med OAuth 2.0 Token Exchange (RFC 8693) förankrad i PKIaaS-utfärdade certifikat tillhandahåller den tekniska mekanismen för en verifierbar delegeringskedja där varje hopps identitet och auktoriseringsomfång är kryptografiskt bevisbart.

Hur fungerar mTLS för kommunikation mellan AI och tjänst?

mTLS kräver att både AI-agenten och tjänsten presenterar och verifierar certifikat innan anslutningen fortsätter. Agenten verifierar tjänstens certifikat (förhindrar anrop till förfalskade slutpunkter) och tjänsten verifierar agentens certifikat (avvisar obehöriga agenter på TLS-lagret). Certifikatbaserad OAuth (RFC 8705) utökar detta genom att binda OAuth-åtkomsttokens till agentens certifikatfingeravtryck, vilket gör stulna åtkomsttokens oanvändbara utan motsvarande privata nyckel.

Hur kortlivade bör AI-agentcertifikat vara?

För tillfälliga agenter som startas för en enskild uppgift: 15 minuter till 4 timmar, vilket matchar den förväntade uppgiftens varaktighet. För permanenta agentdistributioner: 24 till 48 timmar med automatisk förnyelse före utgångsdatum. Giltighetsperioden bör vara tillräckligt kort så att ett komprometterat certifikat löper ut innan en angripare meningsfullt kan utnyttja det, och tillräckligt lång så att den automatiserade förnyelseinfrastrukturen tillförlitligt ersätter det innan agenten körs utan giltig autentiseringsuppgift.

Vilken är den regulatoriska statusen för identitetskrav för AI-agenter?

Framväxande men snabbt växande. NIST:s NCCoE publicerade 2026 ett konceptdokument om programvara och AI-agenters identitet och auktorisering. ITU inrättade 2026 en fokusgrupp om förtroende och identitet för AI-agenter. EU:s AI-lag skapar ansvarsskyldigheter och granskningsskyldigheter för AI-system med hög risk. Tillsynsmyndigheter inom finanssektorn införlivar AI-styrning i riktlinjer för IKT-riskhantering. Certifikatbaserad kryptografisk identitet är den mest mogna tekniska mekanismen för att uppfylla dessa framväxande ansvars- och tillskrivningskrav.