Active Directory, Decentralized identity and verifiable credentials, IAM Technologies, Identity, Privacy, Privileged access management, SSO/MFA

Identity Protocols Were Not Built for AI Agents

(Adobe Stock)

Current identity protocols assume a human operator grants consent, authenticates, and maintains session control. AI agents operate autonomously at machine scale, breaking these foundational assumptions in ways that create new attack surfaces and operational blind spots.

How AI Agents Break Protocol Assumptions

OAuth assumes a human grants consent through an interactive authorization flow. OIDC assumes a user authenticates and maintains session context. SAML assumes a person is logging in and can respond to identity provider challenges. AI agents operate without human intervention, making thousands of API calls under delegated authority with no interactive capability.

This mismatch creates four technical gaps. First, consent grant mechanisms require a human in the loop to authorize scope and duration. An AI agent cannot complete an OAuth authorization code flow or respond to step-up authentication challenges. Second, session and token lifetimes assume periodic human re-authentication. Standard refresh token flows expect a user to re-authenticate when tokens expire, but agents need continuous operation without human intervention.

Third, no native mechanism exists for autonomous delegation to sub-agents. When a root agent spawns sub-agents for parallel processing, current protocols lack a standard way to delegate scoped authority down the chain. Fourth, no standard exists for trust chain verification across agent invocations. Unlike certificate chains, identity protocols provide no mechanism to verify that Agent A legitimately delegated authority to Agent B, which then delegated to Agent C.

Test your environment: identify AI workloads currently using OAuth or OIDC flows and document where they fail at consent, re-authentication, or delegation points. (Source: openid.net)

Service Account Workarounds and Their Risks

Teams typically solve AI agent identity with service accounts, but this approach amplifies existing NHI risks. Service accounts share credentials across multiple agent instances with no per-agent scoping. A single service account might authenticate hundreds of agent instances, making it impossible to trace actions to specific agent behaviors or revoke access for a misbehaving agent without affecting the entire fleet.

Service accounts provide no audit trail per agent invocation, only per account. When Agent A and Agent B both use the same service account credentials, security teams cannot distinguish their actions in logs or trace attack paths to specific agent decision chains. This creates forensic blind spots during incident response.

Service account credentials outlive workload lifecycles when deployment pipelines lack identity lifecycle integration. Unlike human accounts with termination processes, service accounts persist after the workloads they were created for are decommissioned. Container orchestrators frequently create new agent workloads without corresponding credential cleanup.

Service accounts accumulate privileges when agents need different access at different operational stages. An agent that needs read access during data ingestion and write access during model training typically receives both permissions permanently, violating least privilege principles.

This pattern creates the NHI governance blind spots identified in enterprise risk frameworks but at greater scale. AI agents can invoke operations at machine scale under a single service account, accumulating access events that overwhelm traditional session-based monitoring designed for human users.

Audit your service accounts: count how many AI workloads share each account and whether you can trace individual agent actions in your logs.

Workload Identity and Short-Lived Credentials

SPIFFE/SPIRE provides cryptographic identity tied to workload attributes rather than static credentials. Instead of shared service account passwords, SPIFFE issues SVIDs (SPIFFE Verifiable Identity Documents) based on workload properties like Kubernetes namespace, service account, and container image digest. (Source: SPIFFE)

SVIDs are X.509 certificates with SPIFFE IDs in the Subject Alternative Name field, automatically issued and rotated without human intervention. The SPIRE agent running on each node validates workload identity through attestation plugins that verify platform-specific attributes. For Kubernetes workloads, this includes the pod's service account token and namespace.

Short-lived credentials with automatic rotation change the risk posture for AI workloads. SVIDs typically expire within hours and rotate automatically before expiration. This eliminates the attack window for stolen credentials and removes manual rotation requirements. Each workload receives unique credentials scoped to its specific identity and role, enabling per-agent audit trails and granular revocation.

For environments not running SPIFFE/SPIRE, consider scoped service principals as an intermediate approach. (Source: Microsoft Entra Agent Identities) Cloud providers offer service principals with automatic credential rotation and workload-specific scoping. AWS IAM Roles for Service Accounts (IRSA) and Azure Workload Identity provide similar capabilities without requiring a separate certificate authority infrastructure.

Evaluate whether your AI workloads can operate with credential lifetimes measured in hours rather than months. Operational complexity versus reduced credential exposure windows.

Credential Delegation and Sub-Agent Trust Chains

AI agents frequently spawn sub-agents for parallel processing or specialized tasks. The root agent receives delegated credentials but needs to pass scoped authority to sub-agents without sharing its primary credentials. Current identity protocols lack a native trust chain mechanism for autonomous agent hierarchies.

OAuth 2.0 Token Exchange (RFC 8693) provides the closest existing mechanism for delegation flows. The specification allows an agent to exchange its access token for a new token with different scope or audience, enabling limited delegation to sub-components.

However, Token Exchange has specific limitations for autonomous agent chains. Scope negotiation is static and defined at policy configuration time, preventing dynamic scope adjustment based on runtime conditions. No mechanism exists for dynamic sub-agent registration or trust chain verification. The receiving system cannot verify that Token B was legitimately derived from Token A through a valid delegation path.

Without native delegation support, teams solve sub-agent identity through credential sharing or API key inheritance. Both approaches break audit trail continuity and create blast radius risks when any node in the chain is compromised. If Agent C is compromised, the attacker gains the same privileges as the root Agent A, despite Agent C operating with supposedly limited scope.

Map your agent delegation patterns: identify where root agents pass credentials to sub-agents and whether you can revoke sub-agent access without affecting the parent.

Emerging Standards and What Is Still Missing

Standards bodies are addressing AI agent identity, but key gaps remain. The IETF OAuth Working Group has active drafts extending Token Exchange for agentic workflows, but these remain in working group status without ratified specifications. The SPIFFE Steering Committee is developing federation mechanisms for cross-cluster agent identity, though implementation timelines depend on community adoption.

The OpenID Foundation has working group activity on machine-to-machine authentication flows, but current drafts focus on single-agent scenarios rather than agent hierarchies.

What does not exist yet: no ratified standard for multi-agent trust chains, no protocol-level mechanism for dynamic scope negotiation between agent layers, and no standard revocation model for agent credential chains. When Agent B's credentials need revocation, protocols lack a standard way to invalidate derived credentials held by its sub-agents.

These gaps force organizations to implement proprietary delegation mechanisms, creating vendor lock-in and interoperability challenges as AI agent deployments scale across hybrid cloud environments.

Plan for standards evolution: design agent identity architectures with protocol abstraction layers that can adapt to emerging standards without requiring workload changes. (Source: www.nist.gov)

Getting Started Checklist

AI Agent Identity Posture Assessment:

  • [ ] Enumerate AI workloads using service accounts: Identify which AI agents authenticate with shared service account credentials rather than unique identities
  • [ ] Assess credential rotation and scoping per agent instance: Document credential lifetimes and whether individual agents can be re-credentialed independently
  • [ ] Identify delegation patterns with no audit trail: Map where root agents pass credentials to sub-agents and verify whether you can trace actions to specific agent instances
  • [ ] Flag workloads with no SPIFFE or workload identity integration: List AI workloads using static credentials that could benefit from automatic rotation and workload-scoped identity
  • [ ] Test revocation granularity: Verify whether you can revoke access for a single misbehaving agent without affecting other agents in the same workflow
  • [ ] Document protocol gaps: Note where your AI agents cannot complete standard OAuth/OIDC flows due to missing interactive capability

Sources

SC Media Editorial Intelligence, reviewed by Peter Orlowski

This content was reviewed and approved by a cybersecurity practitioner participating in CyberRisk Alliance’s Expert Review Program. Reviewers assess technical accuracy, relevance, and alignment with current industry practices.

Peter Orlowski is a Principal Security Engineer and IAM Architect at Providence, where he leads enterprise identity and access management strategy for a large-scale healthcare environment. He specializes in modernizing identity platforms, reducing privileged access risk, and aligning security capabilities with business outcomes. Peter focuses on scalable identity architectures, service account governance, and Zero Trust principles to improve both security posture and user experience. He is known for bridging engineering, security, and business priorities to deliver measurable risk reduction and operational resilience, and for shaping IAM strategy and governance frameworks that strengthen regulatory alignment and enterprise risk posture across complex organizations.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds