We're deploying autonomous systems that can read files, call APIs, send messages, and execute code — and we can't answer the most basic question: who is this agent? We're deploying autonomous systems that can read files, call APIs, send messages, and execute code — and we can't answer the most basic question: who is this agent? In September 2025, the Cloud Security Alliance surveyed 285 IT and security professionals about how their organizations manage AI agents. One finding stood out: only 21.9% treat AI agents as independent, identity-bearing entities within their security model. The rest? Shared service accounts, static API keys, username-password pairs. Meanwhile, 80.9% of technical teams have already moved AI agents into active testing or production. We are deploying autonomous systems at scale and authenticating them with the security equivalent of a Post-it note on a monitor. The three identity models that don't fit Every identity system we have was built for one of three actors: humans, services, or bots. AI agents are none of these. Humans authenticate interactively. OAuth 2.0, OIDC, passkeys — these flows assume a person is present to consent, to approve scopes, to respond to MFA challenges. An AI agent operates autonomously. There's no human in the loop at execution time to approve each action. Humans Services authenticate with static credentials. API keys, client certificates, service accounts. These work because services are deterministic: a payment microservice always does the same thing with the same permissions. An AI agent is non-deterministic. The same agent, given the same tool, may take different actions depending on its context, prompt, conversation history, and the model's probabilistic output. A static permission set either over-privileges the agent for most tasks or under-privileges it for some. Services Bots are automated scripts with narrow, predefined behavior. A CI bot runs a pipeline. A Slack bot responds to commands. Their actions are enumerable. An AI agent's actions are not — they emerge from the interaction between the model, the user's request, available tools, and the agent's context window. Bots The result: organizations default to whatever's easiest. The Gravitee State of AI Agent Security 2026 report, surveying over 900 practitioners, found that 45.6% use shared API keys for agent-to-agent authentication. Only 17.8% use mTLS. The delegation problem When a human asks an AI agent to "summarize my recent emails," a chain of delegation begins that has no proper security model. The user delegates authority to the agent. The agent connects to an MCP server that provides email access. The MCP server calls an API on the user's behalf. At each hop, a trust decision is made — and none of them are formally scoped. OAuth 2.0 has a concept of delegation: a user authorizes a client application to act on their behalf, with specific scopes. But an AI agent doesn't fit the OAuth client model cleanly. It's not a fixed application with a registered redirect URI and a static set of scopes. It's a runtime that decides which tools to call, with which parameters, based on a natural language conversation. The IETF recognized this gap. In May 2025, an Internet-Draft proposed a new OAuth 2.0 grant type specifically for AI agents: urn:ietf:params:oauth:grant-type:agent-authorization_code. The flow works like this: urn:ietf:params:oauth:grant-type:agent-authorization_code The client application initiates an authorization request with a requested_agent parameter
The user authenticates and explicitly consents to the agent acting on their behalf
An authorization code is issued
The agent exchanges this code — along with its own agent token and a PKCE verifier — for a delegated access token
The resulting JWT contains both the user's identity (sub) and the agent's identity (act), creating an auditable delegation chain The client application initiates an authorization request with a requested_agent parameter requested_agent The user authenticates and explicitly consents to the agent acting on their behalf An authorization code is issued The agent exchanges this code — along with its own agent token and a PKCE verifier — for a delegated access token The resulting JWT contains both the user's identity (sub) and the agent's identity (act), creating an auditable delegation chain sub act This is a meaningful step. But it's a draft. Not a standard. Not implemented in any production MCP client today. The multi-hop trust chain The delegation problem compounds when agents interact with multiple tools and services. Consider a realistic setup: User → Agent → MCP Server A (file system) → reads config
                                            → finds database URL
             → MCP Server B (database)     → queries with URL from Server A
             → MCP Server C (email)        → sends results User → Agent → MCP Server A (file system) → reads config
                                            → finds database URL
             → MCP Server B (database)     → queries with URL from Server A
             → MCP Server C (email)        → sends results Three MCP servers. Each one was independently authorized. But the agent's behavior across them creates an emergent permission set that nobody approved. The agent can read a file, extract a database connection string from it, query the database, and email the results — a data exfiltration pipeline assembled from individually benign tools. No MCP server in this chain knows about the others. Server C (email) doesn't know that the data it's sending came from Server B (database), which got its connection string from Server A (file system). The agent is the only entity with full context, and it has no mechanism to enforce boundaries between tool interactions. This is the cross-origin problem that web browsers solved with the Same-Origin Policy and CORS. In the browser model, a script from origin A cannot freely access resources from origin B. In the MCP model, every tool from every server shares the same execution context — the agent — with no isolation between them. What happens without agent identity The consequences of this identity gap are already visible. You can't audit agent actions. When an agent sends an email, modifies a database, or deploys code — who is responsible? The CSA survey found that only 28% of organizations can reliably trace agent actions back to human sponsors across all environments. Nearly 80% cannot determine in real-time what their autonomous AI systems are doing. You can't audit agent actions. You can't detect compromised agents. If a tool poisoning attack modifies an agent's behavior — through a manipulated tool description or a compromised MCP server — how would you know? Without unique agent identity, there's no behavioral baseline to compare against. The Gravitee report found that more than 50% of agents operate without security oversight or logging. You can't detect compromised agents. You can't enforce least privilege. The principle of least privilege requires knowing who's requesting what. If the agent is authenticated as a shared service account, every agent gets the same permissions. There's no way to scope access to "this specific agent, running this specific task, on behalf of this specific user." You can't enforce least privilege. You can't comply with regulations. Auditors need to trace decisions to accountable entities. A trading agent that makes autonomous financial decisions at 3 AM needs an identity that answers: which agent instance, running which model version, with which prompt and tools, made this specific decision? Generic service account credentials can't answer any of these questions. You can't comply with regulations. What agent identity should look like The building blocks exist. They're just not connected yet. SPIFFE (Secure Production Identity Framework for Everyone) provides workload identity without static credentials. SPIFFE IDs are URIs tied to workloads, not humans, and they support short-lived, automatically rotating credentials. HashiCorp has explicitly positioned SPIFFE as a framework for "securing the identity of agentic AI and non-human actors." SPIFFE But current SPIFFE deployments in Kubernetes assign identical identities to all replicas of a deployment. For stateless microservices, that's fine. For AI agents, it's not — because two instances of the same agent deployment can behave entirely differently based on their context. Each agent instance needs a unique identity: spiffe://org.example/ns/production/agent/research-agent/instance/a1b2c3 spiffe://org.example/ns/production/agent/research-agent/instance/a1b2c3 Not just "research-agent," but this specific instance, with its specific context, tools, and session. The IETF agent delegation draft introduces the right token structure. A JWT with sub (user), act (agent), and azp (client) creates an auditable chain: "Agent X performed action Y on behalf of User Z through Client W." This is the minimum information needed for meaningful audit trails. The IETF agent delegation draft sub act azp Google's A2A protocol adds agent-to-agent identity. Each agent publishes an agent.json file listing its capabilities and supported authentication flows. A2A v0.3 (July 2025) added signed security cards, which are verifiable claims about an agent's identity and capabilities. When Agent A calls Agent B, both can verify each other's identity and scope. Google's A2A protocol agent.json NIST is now actively working on this. On February 17, 2026, NIST's Center for AI Standards and Innovation launched the AI Agent Standards Initiative, specifically covering agent identity and authorization. Their concept paper, "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization," is collecting stakeholder input through April 2, 2026. NIST What a complete agent identity stack looks like Putting these building blocks together, here is what a production agent identity architecture requires: Layer 1: Instance identity. Each agent instance gets a unique, cryptographically verifiable identity — via SPIFFE, or a similar workload identity framework. This identity is short-lived and automatically rotated. It answers: "which specific agent process is this?" Layer 1: Instance identity. Layer 2: Delegated authorization. When an agent acts on behalf of a user, the delegation is explicit and scoped. The IETF agent authorization flow (or similar) produces tokens that bind user identity, agent identity, and permitted actions. It answers: "what is this agent allowed to do, and on whose behalf?" Layer 2: Delegated authorization. Layer 3: Tool-level policy. Each tool invocation is authorized individually, not just the connection to the MCP server. Connecting to a database server doesn't grant blanket query access — the agent is authorized for specific operations. It answers: "is this specific action, with these specific parameters, permitted?" Layer 3: Tool-level policy. Layer 4: Cross-agent trust. When agents communicate (via A2A or similar protocols), both parties verify identity and scope. Agent A can verify that Agent B is who it claims to be and is authorized for the interaction. It answers: "is the agent making this request trustworthy for this specific interaction?" Layer 4: Cross-agent trust. Layer 5: Continuous audit. Every action is logged with full context: agent instance ID, user delegation, tool called, parameters passed, result returned. Not monthly reviews — real-time monitoring with anomaly detection. It answers: "what happened, and does it match expected behavior?" Layer 5: Continuous audit. No production deployment today implements all five layers. Most implement zero. The gap between now and then The industry data paints a clear picture of where we are: What's needed

Current state

Source



Agents as independent identities

21.9% of orgs do this

CSA Survey, Oct 2025



Real-time agent inventory

21% maintain one

CSA Survey, Oct 2025



Secure auth (mTLS) for agent-to-agent

17.8% use it

Gravitee Report, 2026



Full security approval for agents

14.4% have it

Gravitee Report, 2026



Traceable agent actions to human sponsors

28% can do this

CSA Survey, Oct 2025



Agents monitored and secured

47.1% of orgs

Gravitee Report, 2026 What's needed

Current state

Source



Agents as independent identities

21.9% of orgs do this

CSA Survey, Oct 2025



Real-time agent inventory

21% maintain one

CSA Survey, Oct 2025



Secure auth (mTLS) for agent-to-agent

17.8% use it

Gravitee Report, 2026



Full security approval for agents

14.4% have it

Gravitee Report, 2026



Traceable agent actions to human sponsors

28% can do this

CSA Survey, Oct 2025



Agents monitored and secured

47.1% of orgs

Gravitee Report, 2026 What's needed

Current state

Source What's needed What's needed Current state Current state Source Source Agents as independent identities

21.9% of orgs do this

CSA Survey, Oct 2025 Agents as independent identities Agents as independent identities 21.9% of orgs do this 21.9% of orgs do this CSA Survey, Oct 2025 CSA Survey, Oct 2025 Real-time agent inventory

21% maintain one

CSA Survey, Oct 2025 Real-time agent inventory Real-time agent inventory 21% maintain one 21% maintain one CSA Survey, Oct 2025 CSA Survey, Oct 2025 Secure auth (mTLS) for agent-to-agent

17.8% use it

Gravitee Report, 2026 Secure auth (mTLS) for agent-to-agent Secure auth (mTLS) for agent-to-agent 17.8% use it 17.8% use it Gravitee Report, 2026 Gravitee Report, 2026 Full security approval for agents

14.4% have it

Gravitee Report, 2026 Full security approval for agents Full security approval for agents 14.4% have it 14.4% have it Gravitee Report, 2026 Gravitee Report, 2026 Traceable agent actions to human sponsors

28% can do this

CSA Survey, Oct 2025 Traceable agent actions to human sponsors Traceable agent actions to human sponsors 28% can do this 28% can do this CSA Survey, Oct 2025 CSA Survey, Oct 2025 Agents monitored and secured

47.1% of orgs

Gravitee Report, 2026 Agents monitored and secured Agents monitored and secured 47.1% of orgs 47.1% of orgs Gravitee Report, 2026 Gravitee Report, 2026 Meanwhile, 82% of executives feel confident their existing policies protect them from unauthorized agent actions. The gap between that confidence and the data above is where breaches happen. What you can do today The full stack described above is where the industry needs to go. But you don't need to wait for NIST or the IETF to ship before improving your posture. Stop using shared credentials for agents. If every agent authenticates with the same API key, you have no identity — you have a shared password. Issue per-agent credentials, even if it's just unique API keys as an interim step. Stop using shared credentials for agents. Log everything at the tool level. Don't just log that an agent connected to a server. Log every tool call, every parameter, every response. This is the audit trail you'll need when something goes wrong. Log everything at the tool level. Scope tool access per agent. Not every agent needs every tool. If an agent's job is to summarize documents, it doesn't need access to email sending or code deployment tools. Enforce this at the MCP server level or through a gateway. Scope tool access per agent. Pin your MCP server versions. An agent's identity is meaningless if the tools it connects to can change underneath it. Pin versions, hash tool definitions, and alert on changes. Pin your MCP server versions. Treat agent security like infrastructure security. AI agents are infrastructure now. They deserve the same rigor as your production services: unique identities, scoped permissions, monitored access, and incident response procedures. Treat agent security like infrastructure security. The standards are coming. NIST is working on it. The IETF is drafting extensions. SPIFFE is being adapted. But your agents are running in production today, and the identity gap exists right now. The best time to close it was before deployment. The second best time is now. References: References: Cloud Security Alliance, "AI Agent Identity Crisis" survey, September–October 2025 (n=285)
Gravitee, "State of AI Agent Security 2026" report (n=900+)
IETF Internet-Draft, "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents," T. S. Senarath, May 2025
NIST AI Agent Standards Initiative announcement, February 17, 2026
HashiCorp, "SPIFFE: Securing the Identity of Agentic AI and Non-Human Actors"
Solo.io, "Agent Identity and Access Management — Can SPIFFE Work?"
Google A2A Protocol specification, v0.3, July 2025
MCP Authorization Specification, 2025-03-26 and 2025-11-25 revisions Cloud Security Alliance, "AI Agent Identity Crisis" survey, September–October 2025 (n=285) Cloud Security Alliance, "AI Agent Identity Crisis" survey, September–October 2025 (n=285) Gravitee, "State of AI Agent Security 2026" report (n=900+) Gravitee, "State of AI Agent Security 2026" report (n=900+) IETF Internet-Draft, "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents," T. S. Senarath, May 2025 IETF Internet-Draft, "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents," T. S. Senarath, May 2025 NIST AI Agent Standards Initiative announcement, February 17, 2026 NIST AI Agent Standards Initiative announcement, February 17, 2026 HashiCorp, "SPIFFE: Securing the Identity of Agentic AI and Non-Human Actors" HashiCorp, "SPIFFE: Securing the Identity of Agentic AI and Non-Human Actors" Solo.io, "Agent Identity and Access Management — Can SPIFFE Work?" Solo.io, "Agent Identity and Access Management — Can SPIFFE Work?" Google A2A Protocol specification, v0.3, July 2025 Google A2A Protocol specification, v0.3, July 2025 MCP Authorization Specification, 2025-03-26 and 2025-11-25 revisions MCP Authorization Specification, 2025-03-26 and 2025-11-25 revisions

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

AI Agents Don’t Have Identities and That’s a Security Crisis

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Why Traditional IAM Systems Fail in the Age of AI Agents

AI Coding Tip 007 - Protect Your AI Agents from Malicious Skills

Living With the Lethal Trifecta: How to Run OpenClaw Securely

PromptDesk: Simplifying Prompt Management in a Rapidly Evolving AI Landscape

'Multimodal is the most unappreciated AI breakthrough' says DoNotPay CEO Joshua Browder

From Chat-Bots to Killer-Bots?

Why Traditional IAM Systems Fail in the Age of AI Agents

AI Coding Tip 007 - Protect Your AI Agents from Malicious Skills

Living With the Lethal Trifecta: How to Run OpenClaw Securely

PromptDesk: Simplifying Prompt Management in a Rapidly Evolving AI Landscape

'Multimodal is the most unappreciated AI breakthrough' says DoNotPay CEO Joshua Browder

From Chat-Bots to Killer-Bots?

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps