AI Agents Don't Have Identities. That's Your Next Breach.

In July 2026, an autonomous agent operating inside Hugging Face's environment reached production, collected the credentials that were sitting there waiting for it, and moved laterally across the cluster.

What makes this worth studying is that nothing about it resembles a conventional vulnerability. There was no unpatched CVE involved, nobody clicked a phishing link, and no storage bucket was left open to the internet. The agent held valid credentials with real permissions and it used them faster than any human reviewer could have noticed. Most teams shipping agents right now are one carefully worded prompt away from the same outcome.

How agents get credentials today

Ask an engineering team how their agent authenticates and you will get one of four answers.

The most common is that the agent runs on an EC2 instance or in a pod and inherits the attached instance profile or managed identity. Whatever that workload could do, the agent can now do. If IMDSv1 is still enabled on that instance, anything capable of making an outbound HTTP request from inside the agent's process can retrieve those credentials directly from 169.254.169.254 with no token hop. Server side request forgery has been a credential theft primitive for a decade, and an agent is effectively SSRF with a reasoning engine attached.

The second answer is that a service account key was pasted into an environment variable, because that was the fastest path during the prototype, and the prototype is now serving traffic.

Third, the agent borrows a developer's personal access token or OAuth token, which means it inherits a human's full standing privilege along with an audit trail where every action is attributed to a person who was asleep at the time.

Fourth, the agent calls a tool server that holds the credential on its behalf, and nobody has examined what that server will do when asked politely.

All four produce the same outcome, which is standing, long lived, broadly scoped access. Microsoft's telemetry puts the share of granted machine permissions that are ever used at under 5%. Entro Labs found that 47% of machine identities were more than a year old with no rotation. Agents are inheriting all of that accumulated slack and then exercising it at machine speed.

The MCP problem

Model Context Protocol became the default way to wire agents to tools in roughly eighteen months. It solved a real interoperability problem, and it also shipped with authorization treated as an optional concern rather than a requirement.

A scan in mid 2025 found approximately 1,862 publicly reachable MCP servers responding to unauthenticated requests. Those servers were behaving exactly as the specification permitted, which is a more uncomfortable finding than a wave of misconfiguration would have been. GitGuardian counted more than 24,000 unique secrets sitting in MCP related configuration files and over 1.27 million leaked credentials tied to AI services during 2025, an 81% year over year increase.

The deeper structural issue is the confused deputy. Your MCP server holds a powerful credential, the agent asks it to perform an action, and the server performs it, because the server was never designed to care who is asking or on whose behalf. The agent becomes a permission laundering layer that takes untrusted input in the form of a prompt and converts it into a trusted action against your cloud.

This reframes prompt injection. When the model on the receiving end holds an IAM role, prompt injection becomes a privilege escalation primitive with a natural language interface, and content moderation is the wrong layer to defend at.

What to do instead

Give every agent its own principal

One agent should map to one identity with one permission set that you can revoke in isolation, rather than sharing a service account or borrowing a developer token. If you cannot answer which identity executed a given action, your investigation becomes guesswork.

Make credentials ephemeral

Workload Identity Federation on GCP, IRSA or Pod Identity on EKS, and managed identities on Azure all let you mint tokens per task, scoped to the task, expiring in minutes. A fifteen minute credential is barely worth exfiltrating. This is the single highest leverage change available to most teams and it requires no new vendor.

Bind every agent to a human owner

Someone has to be accountable for what it can touch and responsible for decommissioning it when it stops being useful. Orphaned agent identities are the new orphaned service accounts, and there will be far more of them. IDC projects over a billion agents in production by 2029.

Authorize at the tool call rather than at the connection

Use OAuth 2.1 with PKCE, and audience restricted tokens through resource indicators (RFC 8707) so a token minted for one MCP server cannot be replayed against another. Authentication tells you the agent is who it claims to be, while the question that protects you is whether this agent may perform this specific operation against this specific resource, right now, given who initiated the session.

Log tool invocations alongside cloud API calls

CloudTrail will record that a role called s3:DeleteObject, and it will say nothing about the support agent that was argued into it by a customer. You need the agent's tool calls and reasoning trace in the same timeline as your cloud audit log, or incident response turns into archaeology.

Set a blast radius ceiling per agent

Before deployment, ask what the worst case looks like if the agent is fully compromised on day one. If the honest answer involves your production database, the agent should not ship with that access. Design the permission set backwards from the failure case rather than forwards from the happy path.

The uncomfortable summary

Every agent you deploy is a new identity with real permissions, no HR record, no manager, and no offboarding process. Machine identities already outnumber humans by somewhere between 45 to 1 and 144 to 1 depending on the research and how cloud native your stack is, and agents will make those ratios look conservative.

The organizations that come through this well will be the ones that treated agent identity as an identity problem from day one, and can answer three questions on demand: what identities exist, what can each one reach, and what did they do. Better prompt filtering will not substitute for any of that.

If you cannot answer those three questions today, that is the work.