Säkra AI-till-AI-kommunikation med privat PKI

En säkerhetsagent är behörig att karantänera enheter och återställa åtkomst som svar på hot. Någon förgiftar en loggfil med skadliga instruktioner som är utformade för att se ut som en hotvarning. Agenten läser loggen, bearbetar den inbäddade instruktionen och karantänerar en flotta av produktionsmaskiner som aldrig varit under attack. Explosionsradien sprids över alla system som agenten var kopplad till innan någon granskar en enda varning.

Detta scenario är inte hypotetiskt. Det beskriver en typ av attack som kallas snabb injektion via miljöinput, och det blir betydligt farligare när kanalen mellan AI-agenter, mellan agenter och modell-API:er, och mellan agenter och interna automationssystem inte har någon kryptografisk identitetsgaranti. Utan ömsesidig TLS och privat PKI som backar upp anslutningarna finns det ingen teknisk mekanism för att verifiera att loggfilen som agenten läste kom från den auktoriserade loggningstjänsten snarare än från en angripare som avlyssnade anslutningen. Det finns ingen teknisk mekanism för att verifiera att agenten som utfärdar karantänkommandot är den auktoriserade säkerhetsagenten snarare än en komprometterad process som påstår sig vara en. Och det finns ingen omedelbar kill switch när agenten börjar bete sig på ett sätt den inte borde.

Privat PKI är det kryptografiska identitetslager som tillhandahåller alla tre. Det här inlägget förklarar hur, specifikt för AI-till-AI-kommunikation, agent-till-modell-API-anrop och de interna automatiseringsarbetsflöden där agentsystem utför sitt mest betydande arbete.

Snabbt svar: Vad gör privat PKI för AI-till-AI-kommunikation?

Privat PKI tillhandahåller den certifikatinfrastruktur som gör varje AI-till-AI-anslutning kryptografiskt verifierbar: båda sidor av anslutningen presenterar och verifierar certifikat innan någon applikationsdata passerar. Detta framtvingar tre säkerhetsegenskaper som ingen API-nyckel, delad token eller identitetsanspråk på applikationsnivå kan tillhandahålla. För det första, kanalintegritet: TLS-sessionen är krypterad och autentiserad, så avlyssnad trafik kan inte läsas eller injiceras. För det andra, dubbelriktad identitet: varje part vet att den pratar med rätt motpart, inte en imitatör eller en mellanperson. För det tredje, omedelbar återkallbarhet: certifikatet är åtkomstuppgifterna, och om det återkallas avslutas agentens möjlighet att kommunicera med alla tjänster som kontrollerar återkallningsstatus, inom några sekunder.

Key Takeaways

• AI-till-AI-kommunikation är en attackyta som befintliga identitetskontroller inte helt åtgärdar. När agenter anropar andra agenter, läser från verktygsutdata eller tar emot instruktioner från orkestreringslager kan innehållet i dessa meddelanden manipuleras om kanalen inte är kryptografiskt skyddad. Privat PKI säkrar kanalen, inte bara anroparens identitet.
• Standard TLS autentiserar endast servern. Agent-till-agent-kommunikation kräver ömsesidig TLS (mTLS), där både den anropande agenten och den mottagande tjänsten presenterar och verifierar certifikat. En agent utan ett giltigt privat PKI-certifikat avvisas vid TLS-handskakningen, innan någon begäran på applikationsnivå behandlas.
• Den privata CA:ns förtroendegräns definierar kommunikationsgränsen. Agenter vars certifikat utfärdas av samma privata CA kan verifiera varandras identitet direkt. Tjänster utanför förtroendedomänen kräver explicit förtroendekonfiguration. Detta gör den privata CA:ns design till den primära arkitekturkontrollen över vilka agenter som kan kommunicera med vilka system.
• Certifikatprofiler tillämpar lägsta behörighet på kommunikationslagret. De utökade nyckelanvändnings-OID:erna, alternativa ämnesnamn och anpassade tillägg i ett certifikat definierar vad certifikatet kan användas till. Tjänster som läser dessa attribut kan fatta auktoriseringsbeslut baserat på vad certifikatet säger att agenten är behörig att göra, inte på vad agenten gör anspråk på i applikationens nyttolast.
• OCSP-återkallelse är den avgörande faktorn för agenter som skenar. Att återkalla ett certifikat upphör med dess möjlighet att slutföra TLS-handskakningar med alla tjänster som utför OCSP-kontroll, inom den tid det tar för återkallelsen att spridas genom OCSP-respondern. För AI-agenter som kan agera över många system på några sekunder är denna snabba återkallningsfunktion det primära inneslutningsverktyget när något går fel.

Kommunikationssäkerhetsgapet i Agent AI

Säkerhetsdiskussionen kring AI-agenter har fokuserat starkt på vad agenter har åtkomst till: vilka behörigheter de har, vilka verktyg de kan anropa och vilka data de kan läsa. Detta är viktigt, men det tar bara upp halva attackytan. Den andra halvan är själva kommunikationskanalen: hur data flödar mellan agenter, hur agentinstruktioner skickas från orkestratorer till arbetare och hur verktygsutdata returneras till agenten som begärde dem.

Var och en av dessa kommunikationshopp är en potentiell manipulationspunkt. En agent som läser från ett verktyg vars utdata har manipulerats behöver inte direkt komprometteras; dess beteende komprometteras genom dess indata. En agent som tar emot instruktioner från en orkestrator över en oautentiserad kanal kan få dessa instruktioner ersatta under överföring. En agent som anropar ett modell-API över en anslutning utan certifikatverifiering på serversidan kan dirigeras till en förfalskad slutpunkt som returnerar manipulerade utdata snarare än genuina modellsvar.

Dessa är inte teoretiska attackvektorer som kräver sofistikerade motståndare. Nätverksavlyssning inom företagsmiljöer, kompromisser med verktygsslutpunkter i leveranskedjan och adversariell snabb injektion genom miljöinput är alla dokumenterade attackklasser i säkerhetsforskning 2025 och 2026. Den agentiska AI-kontexten gör dem mer betydelsefulla eftersom agentens autonoma handling förstärker effekten: en manipulerad input i ett mänskligt arbetsflöde får en människa att fatta ett dåligt beslut, vilket en annan människa kan upptäcka. En manipulerad input i ett agentiskt arbetsflöde får en agent att vidta en dålig åtgärd, vilket kan spridas genom flera nedströmsagenter innan någon granskar utdata.

Vad privat PKI säkrar i AI-kommunikationsflöden

Det finns fyra distinkta kommunikationsflöden i en typisk arkitektur med flera agenter, vart och ett med specifika säkerhetsegenskaper som privat PKI tillhandahåller.

Agent-till-agent-kommunikation

När en koordinerande agent delegerar en uppgift till en arbetsagent skickar den kontext: uppgiftsdefinitionen, relevanta data, begränsningar för vad arbetaren är behörig att göra och auktoriseringskedjan som beviljar delegeringen. Denna kontext är det mest känsliga innehållet i agentens arbetsflöde, eftersom den avgör vad arbetsagenten ska göra och inom vilka gränser.

Privat PKI säkrar kommunikation mellan agenter via ömsesidig TLS. Den koordinerande agenten presenterar sitt certifikat; arbetsagenten verifierar det mot den privata CA-roten innan den accepterar uppgiftskontexten. Arbetsagenten presenterar sitt certifikat; den koordinerande agenten verifierar det innan den litar på arbetarens svar. Ingen av agenterna accepterar kommunikation från en part som den inte har verifierat mot det privata CA-förtroendepaketet.

Den praktiska konsekvensen: en angripare som får nätverksåtkomst mellan de två agenterna kan inte injicera instruktioner i uppgiftskontexten. TLS-sessionen krypterar kanalen och certifikathandskakningen verifierar båda identiteterna. Att manipulera den krypterade kanalen utan certifikatets privata nyckel är inte beräkningsmässigt genomförbart med nuvarande algoritmer. Agenten tar emot vad den auktoriserade avsändaren skickade, eller så tar den emot ingenting (en misslyckad TLS-handskakning är detekterbar och loggbar).

Agent-till-modell-API-kommunikation

AI-agenter frågar efter modellinferensslutpunkter för att generera utdata, utvärdera alternativ, sammanfatta resultat eller bearbeta indata. Modell-API:et är den mest beräkningsmässigt kraftfulla komponenten i agentarbetsflödet och ofta den mest tillåtna: många modell-API-distributioner accepterar alla autentiserade HTTP-förfrågningar från vilken källa som helst i nätverket.

Privat PKI skärper detta på två sätt. Ur agentens perspektiv säkerställer verifiering av TLS-certifikat på serversidan att agenten frågar den legitima modellens inferensslutpunkt, inte en förfalskad tjänst som returnerar manipulerade utdata. Agentens TLS-bibliotek verifierar slutpunktens certifikat mot den privata CA-roten innan HTTPS-sessionen upprättas. Ur modell-API:ets perspektiv säkerställer kravet på mTLS-klientcertifikatautentisering att endast agenter som innehar ett giltigt privat PKI-certifikat kan skicka inferensförfrågningar. En obehörig process som får nätverksåtkomst till modell-API:ets nätverkssegment avvisas vid TLS-handskakningen, inte vid en API-nyckelkontroll på applikationsnivå som potentiellt skulle kunna kringgås.

För interna modelldistributioner (självhostad inferens, finjusterade modellslutpunkter eller modellserverande infrastruktur som körs lokalt eller i ett privat moln) är privat PKI den lämpliga TLS-infrastrukturen eftersom offentliga CA-utfärdade certifikat är utformade för offentligt tillgängliga tjänster, inte för privat intern infrastruktur som endast ska kunna nås av auktoriserade agenter inom organisationens förtroendedomän.

Agent-till-intern-automatiseringssystem-kommunikation

AI-agenter anropar ofta interna automationssystem: ärendeplattformar, CI/CD-pipelines, konfigurationshanteringssystem, databehandlingsarbetsflöden och automatiseringstjänster för affärsprocesser. Dessa system har ofta breda behörigheter per definition eftersom de byggdes för mänskliga operatörer med lämplig åtkomst. När en AI-agent anropar dem ärver agenten ytan av dessa system.

Privat PKI som tillämpas på dessa anslutningar ger samma kanalintegritet och egenskaper för dubbelriktad autentisering som andra kommunikationsflöden. Men det lägger till något specifikt till automatiseringskontexten: åtkomstdifferentiering baserad på certifikatprofiler. Olika agenter som anropar samma automatiseringssystem kan presentera certifikat med olika profiler, och automatiseringssystemet kan fatta routnings- eller åtkomstbeslut baserat på certifikatattributen. En övervakningsagent och en konfigurationsändringsagent kan båda vara behöriga att anropa konfigurationshanterings-API:et, men övervakningsagentens certifikat markerar det som skrivskyddat omfång, och konfigurationshanterings-API:et upprätthåller detta genom att kontrollera certifikatets utökade nyckelanvändning eller ett anpassat policyattribut innan skrivförfrågningar bearbetas. Detta är kryptografiskt upprätthållet lägsta privilegium på kommunikationslagret: åtkomstgränsen finns i certifikatet, inte i en behörighetskontroll på applikationsnivå som kan vara felkonfigurerad eller kringgådd.

Kommunikation mellan orkestrator och medarbetare

Agentramverk placerar ett orkestreringslager ovanför enskilda agenter: det koordinerar uppgiftsfördelning, hanterar kontextöverföring, tillämpar arbetsflödesbegränsningar och övervakar agentutdata. Orkestratorn är den komponenten med högst privilegium i arkitekturen eftersom den har insyn i och kontroll över alla agenter under sig.

En orkestrator som kommunicerar med sina arbetsagenter via oautentiserade kanaler är en enda imitationspunkt för hela agentflottan. Om en angripare framgångsrikt kan imitera orkestratorn (genom att presentera en falsk orkestrator-slutpunkt för arbetsagenter) kan de utfärda godtyckliga instruktioner till varje agent i flottan samtidigt. Privat PKI förhindrar detta: orkestratorns certifikat utfärdas av den privata certifikatutfärdaren och är den enda autentiseringsuppgifter som arbetsagenter accepterar som bevis på orkestratorns identitet. Alla processer som försöker imitera orkestratorn utan orkestratorns certifikats privata nyckel kommer att misslyckas med TLS-handskakningen och avvisas av varje arbetsagent den försöker kontakta.

Design av betrodd domän för AI-agentarkitekturer

Den privata certifikatutfärdarens förtroendegräns är den arkitektoniska gränsen för kommunikation mellan AI-agenter. Agenter och tjänster som delar en gemensam rot-certifikatutfärdare i sitt förtroendearkiv kan verifiera varandras certifikat direkt. Agenter och tjänster i olika förtroendedomäner kan inte verifiera varandras certifikat utan uttrycklig korscertifiering eller konfiguration av förtroendearkivet.

För de flesta implementeringar av AI-agenter på företag är en enda privat PKI-hierarki med specialbyggda utfärdande certifikatutfärdare den lämpliga arkitekturen. Rot-certifikatutfärdaren etablerar det övergripande förtroendeankaret. En eller flera mellanliggande certifikatutfärdare sitter under roten, organiserade efter agentkategori, distributionsmiljö eller risknivå. Utfärdande certifikatutfärdare längst ner i hierarkin utfärdar själva agent- och servicecertifikaten. Denna hierarki ger organisationen kontroll över vilka agenter som finns i vilken förtroendenivå, utan att det krävs en separat rot-certifikatutfärdare för varje agentkategori.

Det viktigaste beslutet om förtroendedomändesign för AI-agentarkitekturer är miljöseparation. Agenter som körs i produktion bör ha certifikat från en annan utfärdande certifikatutfärdare än agenter som körs i utveckling eller mellanlagring, även om båda utfärdande certifikatutfärdarna är kedjade till samma rot. Detta innebär att en utvecklingsagent inte kan autentisera mot en produktionstjänst (produktionstjänstens mTLS-konfiguration kräver ett certifikat från den produktionsutfärdande certifikatutfärdaren, och den utvecklingsutfärdande certifikatutfärdaren finns inte i produktionstjänstens förtroendearkiv). Miljöseparation med certifikatutfärdare är den tekniska tillämpningen av segmenteringsprincipen som förhindrar att testmiljöåtgärder sprids till produktionssystem, vilket är en av de vanligaste vektorerna för expansionsradie i agentiska AI-incidenter.

För agentkommunikation mellan flera organisationer eller domäner (när en agent i en organisations PKI-hierarki behöver anropa en tjänst som styrs av en annan organisations privata PKI) tillåter korscertifiering eller konfiguration av förtroendelager specifika anrop mellan domäner samtidigt som isoleringen av båda hierarkierna bibehålls. Detta är mer operativt komplext än kommunikation inom samma domän men är rätt tillvägagångssätt för B2B-agentarbeten där varje organisation behöver upprätthålla oberoende kontroll över sitt förtroendeankare.

Certifikatprofiler som kryptografisk minsta behörighet

Minsta privilegium för AI-agenter är en designprincip som de flesta identitetsramverk anger men få tillämpar kryptografiskt. De flesta implementeringar av lägsta privilegium för agenter förlitar sig på behörighetskontroller på applikationsnivå: agenten presenterar en API-nyckel eller bärartoken, och den mottagande tjänsten kontrollerar ett behörighetsarkiv för att avgöra vad agenten kan göra. Detta är bättre än ingen åtkomstkontroll, men det har två svagheter. Behörighetsarkivet kan vara felkonfigurerat. Och agentens autentiseringsuppgifter på applikationsnivå (API-nyckeln eller token) innehåller inte behörighetsomfånget; det är en söknyckel, inte en inbäddad policy.

Certifikatprofiler i privata PKI flyttar behörighetsomfånget till själva autentiseringsuppgifterna. Ett certifikat som utfärdats till en agent med ett specifikt Extended Key Usage OID, ett specifikt URI SAN eller ett anpassat OID-tillägg innehåller dessa attribut i en struktur som är kryptografiskt signerad av CA. Den mottagande tjänsten kan läsa certifikatattributen och fatta auktoriseringsbeslut baserat på dem, utan att konsultera ett externt behörighetsarkiv. CA:ns signatur på certifikatet är garantin för att attributen har ställts in av en auktoriserad myndighet (CA-operatören), inte av agenten själv. En agent kan inte lägga till en behörighet till sitt eget certifikat; den kan bara presentera det certifikat som CA utfärdat till den, med de attribut som CA:ns utfärdandepolicy tillåter.

I praktiken innebär detta: säkerhetsagenten som kan sätta enheter i karantän har ett certifikat med en EKU- och SAN-profil som specifikt tillåter karantän-API-anrop. Övervakningsagenten som läser samma system har ett certifikat med en skrivskyddad profil. Båda certifikaten är giltiga och är kopplade till samma rot-CA. Men karantän-API-slutpunkten kontrollerar den anropande agentens certifikatprofil innan någon skrivförfrågan bearbetas, och övervakningsagentens certifikatprofil inkluderar inte karantän-EKU:n. Övervakningsagenten kan inte utfärda ett karantänkommando via API:et även om dess logik på applikationsnivå försöker göra det. Principen finns i certifikatet, tillämpas på TLS och applikationslagret, inte i ett behörighetsarkiv som kan vara tillfälligt felkonfigurerat eller kringgått.

Återkallelse som AI-agentens kill switch

När en AI-agent börjar bete sig oväntat, oavsett om det beror på kompromisser, snabb injektion, ett konfigurationsfel eller oväntade modellutdata, måste säkerhetsteamet stoppa den innan dess åtgärder sprider sig ytterligare. Agenten kan göra API-anrop över dussintals system samtidigt. Att stoppa den genom mekanismer på applikationsnivå kräver att man vet vilka specifika API-anrop som ska blockeras och har tillgång till varje systems individuella hastighetsbegränsande eller blocklistningskontroller. Detta är långsamt och felbenäget under incidenter.

Återkallelse av certifikat via OCSP är en enkelåtgärds-avstängningsbrytare. CA-operatören återkallar agentens certifikatserienummer. CA:ns OCSP-responder återspeglar omedelbart återkallningsstatusen. Varje tjänst som agenten försöker ansluta till härnäst utför en OCSP-sökning innan TLS-handskakningen slutförs. OCSP-svaret returnerar "återkallad". TLS-handskakningen misslyckas. Anslutningen nekas. Agenten kan inte anropa någon tjänst som kontrollerar OCSP, oavsett vilken API-slutpunkt den riktar sig mot, oavsett om applikationslagret vet att agenten har återkallats.

Hastigheten hos denna mekanism är det som gör den lämplig för agentbaserad AI-inneslutning. OCSP-svar är vanligtvis tillgängliga inom sekunder efter återkallelse. För agenter som arbetar med maskinhastighet i många system är skillnaden mellan en 30-sekunders inneslutning och en 30-minuters inneslutning skillnaden mellan en innesluten incident och en som har spridit sig över hela agentflottans API-yta.

Korta giltighetsperioder för certifikat förstärker fördelen med återkallelse. Ett agentcertifikat som är giltigt i 4 timmar men som komprometteras vid minut 200 är en autentiseringsuppgift med 40 minuters återstående livslängd även utan återkallelse. Efter återkallelse är den effektiva återstående livslängden tiden till OCSP-spridning, mätt i sekunder. Jämför detta med en statisk API-nyckel som komprometteras när som helst: dess effektiva återstående livslängd är till manuell rotation, vilket branschdata konsekvent visar i genomsnitt månader till år i de flesta organisationer. Kombinationen av kortlivade certifikat och OCSP-återkallelse skapar en autentiseringsuppgiftsregim där fönstret för utnyttjande mäts i sekunder, inte månader.

Nollförtroende tillämpat på agent-till-agent-kommunikation

Zero Trust-arkitekturen tillämpas på AI-agentkommunikation på ett enkelt sätt: ingen agent är betrodd som standard, oavsett dess nätverksplats eller vilken annan agent som skickade den. Varje agent-till-agent-anslutning verifieras mot det privata PKI-betrodda paketet innan anslutningen fortsätter. En agent som har verifierats i en anslutning är inte automatiskt betrodd i nästa; verifiering sker vid varje TLS-handskakning.

Detta är särskilt viktigt för multi-hop agent-arbetsflöden. Om agent A anropar agent B och agent B anropar agent C, bör agent C inte lita på agent B:s påstående om agent A:s auktorisering. Agent C bör verifiera agent B:s certifikat direkt (och bekräfta att agent B är den den utger sig för att vara) och bör fatta sitt eget åtkomstbeslut baserat på agent B:s certifikatattribut (och bekräfta att agent B är behörig att göra just denna begäran). Det faktum att agent A:s certifikat var giltigt tidigare i arbetsflödeskedjan har ingen betydelse för agent B:s nuvarande auktorisering att anropa agent C.

Detta förhindrar en typ av lateral förflyttning där en komprometterad eller manipulerad mellanliggande agent använder sin position i arbetsflödeskedjan för att göra anrop som den orkestrerande agenten inte skulle ha varit behörig att göra direkt. Med Zero Trust tillämpat vid varje hopp, upprätthåller varje certifikat-till-certifikat-verifieringssteg oberoende åtkomstgränsen, och ingen mellanliggande agent kan överskrida sitt eget certifikats behörigheter genom att agera på uppdrag av en uppströms agent med högre behörighet.

Privat PKI är den tekniska grunden för Zero Trust i agent-till-agent-kommunikation eftersom den tillhandahåller den verifierade identitet som principen "aldrig lita på, alltid verifiera" kräver. Det finns inget sätt att tillämpa Zero Trust på agentkommunikation utan en mekanism för varje part att verifiera den andra partens identitet kryptografiskt. Nätverksplats verifierar inte identitet. Bärartokens på applikationslagret verifierar inte identitet (de verifierar innehav av autentiseringsuppgifter, inte identitet). X.509-certifikat som utfärdas av en privat CA och verifieras via mTLS verifierar identitet: den privata nyckeln som motsvarar certifikatet måste finnas för att slutföra TLS-handskakningen, och den privata nyckeln genereras i och är bunden till den specifika agentens exekveringskontext.

Post-kvantumberedskap för AI-agentkommunikation

AI-agentinfrastruktur som driftsätts 2026 kommer fortfarande att vara i drift 2030 och framåt, efter NIST IR 8547:s tidslinje för att avveckla RSA och ECC (ungefär 2030) och förbjuda dem (2035). Certifikatinfrastrukturen som säkrar AI-till-AI-kommunikation idag behöver en planerad migreringsväg till post-kvantalgoritmer innan avvecklingsfönstret stängs.

NIST slutförde FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024. För AI-agentkommunikation som säkras av privat PKI innebär migreringsvägen att nya agentcertifikat utfärdas med ML-DSA-signaturer (för autentisering och integritet) och att TLS-sessioner konfigureras för att använda ML-KEM för nyckelutbyte. Privat PKI är kryptoagil till sin natur: CA kan utfärda certifikat med nya signaturalgoritmer när certifikatprofilerna uppdateras, och agentens TLS-stack måste stödja de nya algoritmerna. Organisationer som nu distribuerar privat PKI för AI-agentkommunikation bör bekräfta att deras PKIaaS-leverantör eller PKI-programvara stöder hybridcertifikatutfärdande (som kombinerar klassisk ECDSA med ML-DSA i ett enda certifikat för kompatibilitet under övergångsperioden) och att deras agentkörningar inkluderar stöd för ML-KEM och ML-DSA i sina TLS-bibliotek.

För mer information om hur Encryption Consulting hanterar PQC-migrering i PKI-sammanhang, se vår PQC Readiness -tjänst och PQC Center of Excellence.

Implementeringschecklista: Privat PKI för kommunikation med AI-agenter

För säkerhetsarkitekter som utformar privata PKI för AI-till-AI-kommunikation täcker följande checklista de kritiska designbesluten:

• Certifikat per agentidentitet, inte per agenttyp. Varje agentdistribution får sitt eget certifikat som kodar dess specifika identitet, distributionsmiljö och auktoriserade omfattning. Delade certifikat mellan agenter av samma typ omintetgör egenskapen icke-avvisande och gör det omöjligt att återkalla en enskild komprometterad agent utan att alla agenter som delar certifikatet återkallar det.
• mTLS tillämpas vid varje slutpunkt för agentkommunikation. Alla tjänster som agenter anropar, inklusive modellinferens-API:er, verktygsslutpunkter, orkestrerings-API:er och meddelandeköer mellan agenter, måste kräva mTLS-klientcertifikatautentisering. Standard-TLS som endast autentiserar serversidan verifierar inte den anropande agentens identitet.
• Certifikatets giltighetsperioder matchade agentens livscykel. Tillfälliga agenter (som skapas för en enskild uppgift) får certifikat som är giltiga för den förväntade uppgiftens varaktighet plus en buffert (15 minuter till 4 timmar). Persistenta agenter får certifikat som är giltiga i 24 till 48 timmar med automatisk förnyelse. Ingen av agenttyperna bör ha autentiseringsuppgifter med giltighetsperioder på flera månader.
• OCSP-tillämpning vid mottagande tjänster. Alla tjänster som accepterar mTLS-anslutningar för agenter måste utföra OCSP-kontroll innan TLS-handskakningen slutförs. OCSP måste konfigureras som hard-fail (vägra anslutningen om OCSP inte kan nås), inte soft-fail (tillåta anslutningen om OCSP inte kan nås), för att säkerställa att kill switch fungerar under nätverksavbrottsförhållanden.
• Miljöseparation genom utfärdande CA. Produktionsagenter, mellanlagringsagenter och utvecklingsagenter utfärdas certifikat från olika utfärdande certifikatutfärdare. Produktionstjänsternas förtroendelager inkluderar endast den produktionsutfärdande certifikatutfärdaren. En utvecklingsagent vars certifikat utfärdades av utvecklingscertifikatutfärdaren kan inte autentisera mot en produktionstjänst, oavsett vad agenten påstår i sin begäran på applikationslagret.
• Certifikatprofilpolicy för tillämpning av omfång. Definiera och tillämpa en certifikatprofil för varje agentkategori (övervakning, skrivskyddad dataåtkomst, skrivåtgärder, privilegierade åtgärder, anrop mellan domäner). Tjänster som tar emot agentanslutningar kontrollerar det anropande certifikatets profilattribut innan de bearbetar begäranden utanför profilens omfattning.
• Automatiserad certifikatprovisionering vid agentstart. Certifikatutgivning måste automatiseras via OIDC-tokenutbyte, SPIFFE/SPIRE-attestering eller bootstrap för Secrets Manager. Manuell certifikatprovisionering skalas inte till agenters AI-distributionshastigheter och introducerar den risk för mänskliga fel som automatisering är utformad för att eliminera.
• CLM-synlighet över hela den aktiva agentens certifikategendom. En plattform för hantering av certifikatlivscykeln bör kontinuerligt inventera alla aktiva agentcertifikat, flaggcertifikat som närmar sig utgångsdatum utan pågående förnyelse och ytliga avvikelser som aktiva certifikat för agenter vars distributioner har avslutats.

Hur krypteringskonsulting kan hjälpa

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande tillhandahåller den privata CA-infrastrukturen för AI-agentkommunikationssäkerhet: ACME+EAB för automatiserad provisionering av agentcertifikat, REST API för integration med AI-orkestreringsplattformar, SPIFFE uppströms CA-stöd för Kubernetes-baserade agentarkitekturer, certifikatprofiler för agentomfattningskontroll och OCSP-infrastruktur dimensionerad för högfrekvent agentcertifikatvalidering. Kontakta oss på Krypteringskonsulting för att diskutera er säkerhetsarkitektur för kommunikation med AI-agenter.
• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare tillhandahåller CLM-synlighetslagret för AI-agentcertifikat: kontinuerlig identifiering av aktiva agentcertifikat, övervakning av utgångsdatum, avvikelsedetektering för överblivna certifikat, övervakning av OCSP- och CRL-status och SIEM-integration som korrelerar agentcertifikathändelser med API-gatewayåtkomstloggar för säkerhetsövervakning.
• PKI-tjänster: För organisationer som utformar privat PKI-arkitektur för AI-agentmiljöer, Encryption Consultings PKI-tjänster tillhandahålla hierarkidesign för CA (utfärdande CA-organisation efter agentnivå och miljö), utveckling av certifikatprofiler för varje agentkategori, rådgivning om mTLS-konfiguration för modellinferensslutpunkter och orkestrerings-API:er, samt design av förtroendedomäner för agentarbetsflöden i flera organisationer eller molnöverskridande.
• PQC-rådgivningstjänster: Kommunikationsinfrastrukturen för AI-agenter som används idag behöver en plan efter kvantmigrering. Encryption Consultings PQC-rådgivningstjänster integrera PQC-migreringsplanering för AI-agentcertifikat i NIST IR 8547-tidslinjen för utfasning, inklusive utfärdande av hybrid ML-DSA-certifikat för kompatibilitet under övergångsperioden och PQC-beredskapsbedömning av TLS-bibliotek för agentkörningar.
• CBOM-säker: Innan organisationer utformar privat PKI för kommunikation med AI-agenter behöver de veta vilka kryptografiska tillgångar som redan finns i deras AI-infrastruktur: vilka agenter har vilka autentiseringsuppgifter, vilken algoritm de befintliga TLS-slutpunkterna använder och var statiska autentiseringsuppgifter fortfarande används. Encryption Consultings CBOM-säkerhet tillhandahåller denna kryptografiska inventering och positionsbedömning som baslinje för kommunikationssäkerhetsdesignen.

Slutsats

De identitetskontroller som säkerhetsteam tillämpar på AI-agenter (minsta möjliga behörighet, just-in-time-åtkomst, miljösegmentering, snabb återkallelse) är de rätta principerna. Privat PKI är det som gör dem tekniskt verkställbara snarare än policyberoende. Du kan inte kringgå en misslyckad TLS-handskakning genom att göra anspråk på ytterligare behörigheter i applikationens nyttolast. Du kan inte personifiera en orchestrator utan orchestratorns certifikats privata nyckel. Du kan inte förlänga giltigheten av en återkallad autentiseringsuppgift genom att fortsätta använda den: OCSP kommer att misslyckas vid nästa handskakning.

Sprängningsradien för en komprometterad AI-agent är proportionell mot vad agenten kan nå innan komprometteringen upptäcks och begränsas. Privat PKI begränsar vad agenten kan nå genom kryptografiskt upprätthållna förtroendegränser, och möjliggör inneslutning genom OCSP-återkallelse som fungerar med en hastighet som är lämplig för autonoma agenter som agerar i maskinhastighet.

AI-agentdistributioner som är utformade utan privat PKI-baserad kommunikationssäkerhet förlitar sig på applikationslagerkontroller och nätverkssegmentering för att begränsa hot som verkar på det kryptografiska lagret. Det är ett designval som kommer att bli allt svårare att försvara i takt med att agentbaserade AI-distributioner skalas upp och i takt med att sofistikeringen av attacker som riktar sig mot kommunikationskanalerna mellan agenter ökar.

Om din organisation utformar säkerhetsarkitektur för AI-agentkommunikation och vill utvärdera den privata PKI-metoden, kontakta Encryption Consulting.

Det här inlägget granskas var sexte månad och när NIST PQC-migreringsvägledning, IETF mTLS-specifikationer eller större agentiska AI-ramverkssäkerhetsmodeller publicerar väsentliga uppdateringar som påverkar säkerhetsdesignen för AI-till-AI-kommunikation.

Vanliga frågor om partihandel med mat och dryck

Vilken är säkerhetsrisken i AI-till-AI-kommunikation?

Kommunikationskanalen mellan AI-agenter är en attackyta oberoende av agenternas egen säkerhet. Utan kryptografisk kanalsäkerhet kan angripare injicera skadliga instruktioner i agentens inmatningsström (snabb injektion via nätverksavlyssning), läsa känslig kontext som agenten skickar mellan system, eller utge sig för att vara en legitim tjänst för att mata agenten med falska data. Privat PKI adresserar alla tre genom att autentisera båda ändar av anslutningen och kryptera kanalen med TLS, vilket gör det kryptografiskt omöjligt för en obehörig part att presentera en giltig identitet i TLS-handskakningen.

Varför är mTLS särskilt viktigt för agent-till-agent-kommunikation snarare än standard-TLS?

Standard TLS autentiserar endast servern; servern verifierar inte klientens identitet. För kommunikation med AI-agenter måste den mottagande agenten verifiera att den anropande agenten är auktoriserad, inte bara att servern den ansluter till är legitim. mTLS kräver att båda parter presenterar och verifierar certifikat innan anslutningen fortsätter, vilket innebär att en obehörig agent avvisas på TLS-lagret innan den kan skicka en enda byte med applikationsdata.

Vad är en PKI-förtroendedomän för AI-agenter?

En PKI-förtroendedomän är den uppsättning agenter och tjänster som delar ett gemensamt rot-CA-certifikat i sina förtroendearkiv och därför accepterar certifikat från den CA-hierarkin som bevis på identitet. Förtroendedomänens gräns avgör vilka agenter som kan autentisera sig till vilka tjänster. Miljöseparation genom att utfärda CA (separata CA:er för produktions-, staging- och utvecklingsagenter) är den primära tekniska kontrollen som förhindrar miljööverskridande explosionsradie i agent-AI-incidenter.

Hur fungerar återkallelse av certifikat som en avstängningsknapp för AI-agenter?

Att återkalla ett agentcertifikat gör att CA:s OCSP-responder returnerar "återkallad" för det certifikatets serienummer. Alla tjänster som agenten därefter försöker ansluta till utför en OCSP-sökning och får statusen återkallad, vilket gör att TLS-handskakningen misslyckas. Anslutningen nekas innan data på applikationsnivå utbyts. För OCSP-konfigurationer med hård felfunktion (den rekommenderade inställningen) fungerar detta även om agenten redan har upprättat en session med vissa tjänster: nya anslutningsförsök efter återkallelse kommer att misslyckas, och de flesta TLS-implementeringar verifierar OCSP-status igen vid återupptagande av sessionen.

Hur tillämpar privat PKI lägsta möjliga privilegium för kommunikation med AI-agenter?

Certifikatprofiler kodar agentens auktoriserade omfattning i kryptografiskt signerade fält: Utökade nyckelanvändnings-OID:er, alternativa ämnesnamn eller anpassade X.509-tillägg. Dessa attribut signeras av certifikatutfärdaren och kan inte ändras av agenten. Tjänster som tar emot agentanslutningar läser dessa attribut och fattar auktoriseringsbeslut baserat på vad certifikatet säger att agenten har tillstånd att göra. En agent kan inte överskrida det omfattning som är kodat i sitt certifikat, oavsett vad den anger i applikationens nyttolast, eftersom tjänsten tillämpar policyn på certifikatattributlagret innan någon begäran bearbetas.