- Key Takeaways
- Varför alla leverantörer konvergerar kring identitet
- Hur Entrust och Encryption Consulting närmar sig Agentics AI-säkerhet
- Fem identitetscentrerade kontroller som varje Agentic AI-program behöver
- Var ett ramverk slutar och verksamheten börjar
- Att omsätta identitetscentrerade kontroller i praktiken
- Hur krypteringskonsulting hjälper
- Relaterad läsning från Encryption Consulting
- Slutsats
- Vanliga frågor om partihandel med mat och dryck
En autonom agent med för mycket åtkomst behöver inte ett stulet lösenord. Den behöver bara en uppgift, en uppsättning verktyg och ingen som tittar på vad den gör med dem.
Organisationer som upplevde en AI-relaterad säkerhetsincident under det senaste året saknade grundläggande AI-åtkomstkontroller i 97 % av fallen, enligt IBMs rapport om kostnaden för ett dataintrång från 2025, som citerats i Entrusts säkerhetsforskning om agentisk AI. Den siffran fångar kärnproblemet väl: agentisk AI-säkerhet är ett identitetsproblem innan det är ett modellproblem.
Encryption Consulting har tidigare behandlat mekanismerna bakom det identitetsproblemet, i vår utbildningsguide till agentisk AI-säkerhet och i AI Agent Governance Starts With Machine Identity . Den här artikeln ställer istället en köpares fråga: när både Entrust och Encryption Consulting säger "identitetscentrerad", vad menar var och en av dem egentligen, och vilka kontroller behöver ett säkerhetsteam införa oavsett vilket leverantörsspråk de föredrar?
Key Takeaways
- Entrust och Encryption Consulting utformar båda agentbaserad AI-säkerhet kring identitet, men de betonar olika lager: policy- och autonominivåer (Entrust) och fullständig certifikatlivscykelhantering kopplad till PKI (Encryption Consulting).
- Fem identitetscentrerade kontroller återkommer i båda metoderna: verifierbar identitet per agent, begränsad auktorisering, kryptografiskt bevis på åtgärd, livscykelstyrning och kontinuerlig granskningsbarhet.
- Statiska API-nycklar och delade inloggningsuppgifter är den felpunkt som alla leverantörer påpekar. Certifikat och kortlivade tokens är den delade rekommendationen.
- Jämförelsetabellen nedan visar identitetsgrund, auktoriseringsmodell, autentiseringsuppgifter, livscykelhantering och revisionslogg för varje metod.
- Ett namngivet ramverk är inte detsamma som ett operativsystem. CertSecure Manager och PKI-as-a-Service omvandlar identitetscentrerade kontroller till automatiserad utfärdande, rotation och återkallelse på agentnivå.
Varför alla leverantörer konvergerar kring identitet
AI-agenter är inte chattrobotar som svarar på frågor och slutar. De anropar API:er, frågar efter databaser, utlöser arbetsflöden och delegerar uppgifter till andra agenter, och vart och ett av dessa steg har verkliga konsekvenser. Entrust beskriver den resulterande exponeringen som en "sammansatt explosionsradie": ett fel eller en manipulerad instruktion förblir inte begränsad till ett system, den sprider sig över alla verktyg och plattformar som agenten kan nå. IDC förutspår att 45 % av organisationerna kommer att köra AI-agenter över kärnverksamhetens funktioner inom fem år, vilket innebär att explosionsradien skalas upp samtidigt som styrningen fortfarande hinner ikapp.
Entrust hanterar detta med ett autonomispektrum: fem nivåer som sträcker sig från skrivskyddad åtkomst, via rekommendation och mänskligt godkänd exekvering, till tidsfördröjd och helt autonom drift, var och en med sin egen riskprofil och nödvändiga kontroller. Det är ett policysvar på ett verkligt problem. Det lämnar fortfarande den operativa frågan öppen om hur dessa policyer faktiskt tillämpas på autentiseringslagret, vilket är där Encryption Consultings tillvägagångssätt börjar.
Hur Entrust och Encryption Consulting närmar sig Agentics AI-säkerhet
Tabellen nedan jämför varje leverantörs egen publicerade positionering gällande agentisk AI-säkerhet, baserad på deras nuvarande offentliga innehåll snarare än funktionspåståenden som vi inte kan verifiera.
| Dimensionera | Anförtro | Krypteringskonsulting |
|---|---|---|
| Identitetsgrund | PKI och hemlighetshantering binder varje agent till en distinkt, kryptografiskt verifierbar identitet. | X.509-certifikat utfärdade från en hanterad PKI, via PKI-as-a-Service eller en befintlig företags-CA, samma förtroenderot som redan används för arbetsbelastningar och enheter. |
| Auktoriseringsmodell | Kontextuell policy mappad till ett autonomispektrum med fem nivåer, från skrivskyddad till helt autonom körning. | Omfattning med lägst behörighet kopplad till en enskild ägare och uppgift, inte ett delat tjänstkonto. |
| Inloggningstyp | Distinkta identiteter utfärdade per agent, knutna till ägare, syfte och auktoritetsomfattning. | Kortlivade certifikat och signerade åtgärdstokens roteras automatiskt snarare än att utfärdas en gång och glömmas bort. |
| Livscykelhantering | Provisionering, övervakning och återkallelse utformade som styrningssteg inom en bredare identitetsplattform. | Fullständig livscykelautomatisering genom CertSecure Manager: identifiering, utfärdande, rotation och återkallelse för alla CA som används. |
| Revision och bevis | Ansvarsskyldighet levereras genom styrningsramverk och policyefterlevnad. | Signerade agentåtgärder plus kontinuerlig certifikatsynlighet, så att varje åtgärd tolkas tillbaka till en identitet och en certifikatpost. |
| Primärt fokus | Styrning av företagsidentitet över IT-verksamhet, säkerhetsverksamhet, DevOps och kundverksamhet. | Hantering av operativa certifikatlivscykelr, PKI-design och kryptografisk identifiering som infrastrukturens identitetsstyrning är beroende av. |
Läs igenom raden för livscykelhantering så blir luckan tydlig. Att namnge provisionering, rotation och återkallelse som styrningssteg är inte samma sak som att automatisera dem över tusentals kortlivade agentidentiteter. Det är precis i den luckan som ett operativt certifikatlivcykelhanteringslager förtjänar sin plats.
Fem identitetscentrerade kontroller som varje Agentic AI-program behöver
Om man tar bort leverantörsspråket dyker samma fem kontroller upp i alla trovärdiga agentbaserade AI-säkerhetsmetoder, inklusive vår egen. En organisation behöver inte anta en leverantörs ramverk i sin helhet för att dra nytta av att implementera alla fem.
1. Verifierbar identitet per agent
Varje agent behöver sin egen identitet, som utfärdas specifikt till den snarare än lånas från en person eller delas mellan en mängd olika agenter. En verifierbar identitet, vanligtvis ett X.509-certifikat eller en kortlivad token, är det som låter ett system skilja en legitim agent från en imitatör eller en manipulerad kopia av samma uppgift.
2. Omfattande auktorisering
Identitet svarar på vem agenten är. Auktorisering svarar på vad den har tillstånd att röra vid, och den måste begränsas till de specifika resurser och uppgifter som agenten faktiskt kräver, inte den breda åtkomst som gör det lättare att bygga en agent. En agent med överbehörighet förvandlar en enda manipulerad prompt till en incident som når betydligt fler system än vad uppgiften någonsin behövde.
3. Kryptografiskt bevis på handling
En verifierbar identitet bör också kunna bevisa vad den gjorde. Signeringsagentens åtgärder och begäranden kopplar en specifik, tillskrivbar identitet till en specifik åtgärd, så en omtvistad eller misstänkt händelse kan spåras tillbaka till exakt den agent och autentiseringsuppgifter som är ansvariga för den snarare än ett delat konto som kunde ha varit vem som helst.
4. Livscykelstyrning
Agentidentiteter behöver samma livscykeldisciplin som alla andra autentiseringsuppgifter: etablering som registrerar en ägare och ett syfte, automatisk rotation så att ingenting förblir statiskt länge, och omedelbar återkallelse i det ögonblick en agent tas ur bruk eller börjar bete sig utanför sitt förväntade mönster. Hanteras manuellt är detta den första kontrollen som halkar efter när agentpopulationen växer.
5. Kontinuerlig granskningsbarhet
Varje agentåtgärd bör hänföras till en identitet, och varje identitet bör hänföras till en ägare. Det är den kedjan som förvandlar en hög med loggar till bevis som en revisor, en tillsynsmyndighet eller en incidentbehandlare faktiskt kan använda, och det är den kontroll som de flesta agentbaserade AI-implementeringar upptäcker att de saknar först efter att något redan har gått fel.
Var ett ramverk slutar och verksamheten börjar
Här kommer vi att tydligt ange vår egen ståndpunkt. Det är nödvändigt att namnge rätt pelare, och Entrust namnger dem korrekt. Men ett policyramverk eller en protokollrekommendation utfärdar inte i sig ett certifikat, roterar en nyckel eller återkallar åtkomst klockan 02:00 när en agent börjar bete sig konstigt. Någon måste fortfarande köra PKI:n, och den PKI:n måste fortfarande hålla jämna steg med CA/Browser Forums schema som minskar maximal giltighetstid för offentliga TLS till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. De flesta agentidentitetsramverk, inklusive SPIFFE/SPIRE och de identitetsmodeller som stora molnleverantörer lanserar, stöds av just denna typ av kortlivat X.509-certifikat.
Det är det lagret där identitetscentrerad säkerhet antingen blir verklighet eller förblir en glida i en styrningsöversikt. En agentpopulation som fördubblas varje kvartal behöver en certifikatlivscykel som kan utfärda, förnya och återkalla i samma takt, för varje certifikatutfärdare som organisationen redan använder, utan att en person manuellt godkänner varje begäran. Detta är det operativa lagret som Encryption Consulting bygger, och det är den del som ett namngivet ramverk inte kan ersätta.
Att omsätta identitetscentrerade kontroller i praktiken
Att omvandla de fem kontrollerna ovan till ett fungerande program följer en konsekvent sekvens, oavsett vilken leverantörsterminologi ett team föredrar:
- Upptäck alla agenter som redan är igång. Agenter skapas inuti SaaS-plattformar, molntjänster och kodningsverktyg, ofta utan att säkerhet någonsin är integrerad. Bygg upp inventeringen innan du skriver en enda policy.
- Utfärda en unik, verifierbar identitet till var och en. Ersätt delade API-nycklar och lånade mänskliga inloggningsuppgifter med certifikat eller kortlivade tokens utfärdade från en hanterad PKI.
- Omfattningsbehörighet för den enskilda agenten och uppgiften. Undvik att bevilja åtkomst av tjänstkontotyp som överlever det specifika jobb som agenten skapades för.
- Signera agentens åtgärder. Gör varje begäran hänförlig till en specifik inloggningsuppgifter, inte en delad identitet som kan tillhöra vem som helst.
- Automatisera livscykeln. Rotation och återkallelse måste ske enligt ett schema som matchar hur snabbt agenter skapas och tas bort, inte enligt ett schema som matchar hur snabbt en person kan behandla en ärendekö.
- Revision sker kontinuerligt. För register över vilken agent som gjorde vad, när och under vilken behörighet, så att svaret är klart innan en tillsynsmyndighet eller en incidentberedskapsperson ber om det.
Hur krypteringskonsulting hjälper
Encryption Consultings AI Agent Identity-lösning tillämpar denna sekvens direkt: upptäcka befintliga agentuppgifter, utfärda kortlivade X.509-certifikat per agent, begränsa åtkomst till en enskild ägare snarare än ett delat tjänstkonto, automatisera hanteringen av certifikatens livscykel och producera signerade, granskningsbara register över vad varje agent gjorde.
CertSecure Manager är motorn under den lösningen. Det är en leverantörsneutral plattform för hantering av certifikatlivscykeln som centraliserar identifiering, automatiserad utfärdande, rotation och återkallelse mellan offentliga och privata certifikatutfärdare, med stöd av ISO/IEC 27001:2022 och SOC 2-certifierade metoder. Där en organisation behöver själva utfärdandeinfrastrukturen designar och driver våra PKI-tjänster den, och CBOM Secure utökar identifieringen bortom certifikat till det fullständiga kryptografiska landskap som en agenttung miljö är beroende av.
Relaterad läsning från Encryption Consulting
- Agentic AI-säkerhet: Identitet och signering för AI-agenter täcker de centrala definitionerna och kontrollerna som denna jämförelse bygger på.
- Styrning av AI-agenter börjar med maskinidentitet bryter ner varför identitet, inte promptlagret, är där agentstyrning faktiskt gäller.
- Topp 10 icke-mänskliga identitetsrisker täcker de bredare maskinidentitetsrisker som agent AI bidrar till.
- Vad är modellkontextprotokollet (MCP)? täcker den kontaktstandard som refereras till i denna jämförelse.
- Identitetskrisen vid kanten av agentisk AI täcker hårdvarurotad identitet för agenter som körs utanför datacentret.
Slutsats
Alla större leverantörer är nu överens om att agentbaserad AI-säkerhet börjar med identitet. Skillnaderna visar sig i vad som händer efter det avtalet, i huruvida en organisation faktiskt kan utfärda, omfånga, rotera och återkalla agentuppgifter i den takt agenter skapas och tas ur bruk. Det är där ett styrningsramverk blir ett operativt program, och det är den del som Encryption Consulting bygger genom CertSecure Manager, PKI Services och PKI-as-a-Service.
Vanliga frågor om partihandel med mat och dryck
Hur skiljer sig Encryption Consultings tillvägagångssätt för agentbaserad AI-säkerhet från Entrusts?
Båda behandlar identitet som grunden för agentisk AI-säkerhet, men var och en bygger på ett annat lager. Entrust mappar autonominivåer till styrningspolicy. Encryption Consulting bygger certifikatlivscykelhanteringen och PKI-infrastrukturen som utfärdar, roterar och återkallar de autentiseringsuppgifter som policyn är beroende av, genom CertSecure Manager och PKI-as-a-Service.
Vad är identitetscentrerade kontroller för AI-agenter?
Identitetscentrerade kontroller behandlar varje AI-agent som en icke-mänsklig identitet som behöver sin egen verifierbara autentiseringsuppgift, begränsad auktorisering, kryptografiskt bevis på de åtgärder den vidtar, livscykelstyrning från utfärdande till återkallelse och en kontinuerlig revisionslogg. Målet är att göra en agents handlingar identifierbara, auktoriserade och spårbara snarare än anonyma.
Behöver AI-agenter sina egna certifikat istället för API-nycklar?
Ja. Statiska API-nycklar är delade hemligheter som sällan roteras och är svåra att tillskriva en specifik agent. X.509-certifikat eller kortlivade tokens ger varje agent en unik, verifierbar identitet som stöder lägsta möjliga privilegier, automatisk rotation och en tydlig revisionslogg, samma disciplin som redan tillämpas på arbetsbelastningar och enheter.
Hur stöder certifikatlivscykelhantering agentsäkerhet för AI?
Certifikatlivscykelhantering automatiserar utfärdande, förnyelse och återkallelse av de autentiseringsuppgifter som stöder agentidentiteter. Utan det kan team inte hålla jämna steg med en växande agentpopulation, särskilt eftersom giltighetstiden för offentliga TLS-certifikat krymper till 47 dagar år 2029 enligt CA/Browser Forums schema. CertSecure Manager tillämpar denna automatisering på alla certifikatutfärdare som en organisation använder.
Vad bör ett säkerhetsteam utvärdera innan de väljer en agentbaserad AI-säkerhetsmetod?
Titta bortom ramverksspråket och ställ tre operativa frågor: kan metoden automatiskt utfärda en verifierbar identitet till varje agent, tillämpar den lägsta behörighetsnivå på individuell agentnivå snarare än ett delat tjänstkonto, och kan den rotera och återkalla autentiseringsuppgifter tillräckligt snabbt för att matcha hur snabbt agenter skapas och tas ur bruk.
- Key Takeaways
- Varför alla leverantörer konvergerar kring identitet
- Hur Entrust och Encryption Consulting närmar sig Agentics AI-säkerhet
- Fem identitetscentrerade kontroller som varje Agentic AI-program behöver
- Var ett ramverk slutar och verksamheten börjar
- Att omsätta identitetscentrerade kontroller i praktiken
- Hur krypteringskonsulting hjälper
- Relaterad läsning från Encryption Consulting
- Slutsats
- Vanliga frågor om partihandel med mat och dryck
