Every AI Agent Is a Non-Human Identity That Needs Governance

A few weeks ago I watched myself create a security problem in about thirty seconds, and it felt like getting work done. I was wiring up an agent to handle a real task, the kind that touches an internal API and changes something on the other side. To let it act, I did what almost everyone does: I grabbed a token, dropped it into an environment variable, and pointed the agent at it. It worked on the first try. Demo complete, ship it. What I had really done was mint a new identity. It carried all of my standing privileges. It had no expiration. No system owned it, no process would ever rotate it, and nothing anywhere recorded that it existed. If that agent ever did something it shouldn't, the audit log would calmly report that I had done it. I have spent most of my career in platform security, and the reflex that job builds is to ask one question first: who is this principal, and what can it do? In security, a principal is just any identity that can authenticate and act on its own: a user, a service, and now an agent. Looking at my own thirty-second shortcut, the answer was uncomfortable. A brand new principal, with my full access, that nobody is watching. The scary part of agentic AI is not the model. It is the identity you create the moment you let an agent act. We are arguing about the wrong threat Most of the AI security conversation right now is about prompt injection and jailbreaks. Those are real and they matter. But they are the exploit, not the damage. An injected instruction only becomes an incident because of what the agent's identity is allowed to reach. If the agent can read one narrow resource for five minutes, a successful injection is an annoyance. If the agent is holding your personal token, a successful injection is a breach. And these identities are multiplying faster than anyone is governing them. Salesforce's 2026 Connectivity Benchmark put the average enterprise at around a dozen AI agents already in use and climbing toward twenty, with half of those agents operating in isolation rather than as part of a coordinated system. At the same time, Orchid Security's Identity Gap: 2026 Snapshot found that unmanaged, invisible identities have grown to outweigh the managed, visible ones, by 57 percent to 43 percent. We are pouring new principals into our systems and losing track of them in the same motion. So here is the reframe I want to push. Prompt injection is how you influence the deputy. The deputy's privileges are the damage. We spend almost all of our attention on the first half of that sentence and almost none on the second. We already solved this, for humans and for services Here is the part that should be reassuring and is instead a little embarrassing. We know how to do this. Identity engineering is one of the most mature, boring, well-trodden areas in all of software. For human employees we have single sign-on and multi-factor authentication. For people and services alike we have role-based access control and scoped tokens, so a principal gets the access a task needs and nothing more. We have provisioning and, just as importantly, de-provisioning: an identity is created through a process and destroyed through one. We have short-lived credentials and rotation, so a leaked secret has a short shelf life. We have secrets managers and workload identity so that nothing has to embed a static key in the first place. And we have audit logs that attribute every action to a specific principal, so "who did this" always has an answer. We would never accept, for a human employee, a shared credential that never expires, grants full access, is never rotated, and shows up in the logs as somebody else. We would treat that as an obvious finding and fix it the same week. Yet that is the default way most teams hand credentials to their agents. The point is not that agents need some new, AI-native identity magic. The point is the opposite. Agents are a new kind of principal, and they belong inside the identity lifecycle we already run. We just have not onboarded them into it. How agent identity gets handled today Walk the lifecycle stage by stage and the gap shows up at every single one. \n Provisioning *:* there usually isn't any. An engineer pastes a token into a config file or an environment variable. No request, no owner, no record that the identity was ever born. Authentication *:* the agent authenticates as a human, using that person's borrowed token, or as a shared service account that several agents quietly reuse. Authorization *:* the agent inherits the human's full standing scope. Nobody downscopes it to the one thing the task needs, because that is extra work and the broad token already works. Rotation *:* the credential is long-lived and static. It is the kind of secret that is still valid two years later because nobody remembered it was there. Audit and attribution *:* this is the one that should keep you up at night. The agent acts with the human's identity, so the logs say the human did it. When something goes wrong, you cannot even tell a person apart from their agent. De-provisioning *:* the agent gets switched off, the project ends, and the credential lives on. An orphaned secret with real access and no owner. Every one of those is a known identity failure. We have names and controls for all of them. We simply stopped applying them the moment the principal stopped being a person. The confused deputy, now running on its own There is a classic security problem called the confused deputy. It describes a privileged intermediary that gets tricked into misusing its authority on someone else's behalf. The deputy is not malicious. It is just powerful, and it does what it is told. An AI agent that reads untrusted input and also holds broad credentials is the textbook confused deputy. The only thing that has changed is the tempo. The agent acts at machine speed, and it composes its steps live instead of following a fixed script, so it can improvise its way through your environment in a way a hardcoded attack never could. This is not hypothetical. In May 2026, Sysdig's threat research team documented an intrusion in which, after an initial vulnerability was exploited, an LLM agent drove the post-exploitation itself: harvesting credentials from the host, pivoting through a secrets store and a bastion with them, and exfiltrating an internal database in under two minutes. The agent did not break the identity model. It used the model exactly as configured. The standing access was already there for the taking. The defense for this is not a cleverer prompt. It is identity-shaped: scope, delegation, and attribution. (How you keep untrusted input from steering the agent in the first place is its own topic. Here I am focused on bounding what the agent can do once it has been steered.) What good agent identity looks like The fixes are not exotic. They are the same controls we already use, pointed at a new kind of principal. Give each agent its own identity . An agent is a principal, so treat it like one. It should not be borrowing a human's token or hiding inside a shared service account. Per-agent, and per-task where you can manage it, is the target. Issue scoped, short-lived, attributable credentials . Instead of handing over a broad, long-lived secret, mint a downscoped token for the specific task, give it a short time to live, and preserve the delegation chain so the audit trail can say "this agent, acting for this user." OAuth 2.0 Token Exchange (RFC 8693) is the standard mechanism for exactly this, with the user as the subject and the agent as the actor. In the cloud, scoped STS session credentials are the analog. \ # Anti-pattern: the agent inherits everything you can do, forever. client = VendorAPI(token=os.environ["MY_PERSONAL_TOKEN"])  # full scope, no expiry, logs as you # Pattern: mint a scoped, short-lived, attributable credential per task. # OAuth 2.0 Token Exchange (RFC 8693): subject = the user, actor = the agent. resp = requests.post(TOKEN_ENDPOINT, data={     "grant_type":         "urn:ietf:params:oauth:grant-type:token-exchange",     "subject_token":      user_access_token,     # on whose behalf     "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",     "actor_token":        agent_identity_token,  # who is acting (the agent)     "actor_token_type":   "urn:ietf:params:oauth:token-type:access_token",     "scope":              "invoices:read",        # downscope to the task only     "audience":           "https://api.internal/billing", }) scoped = resp.json()["access_token"]   # short TTL, carries an `act` delegation claim client = VendorAPI(token=scoped)       # least access, expires fast, attributable The exact mechanism will depend on your identity provider, but the three properties are the non-negotiables: scoped, short-lived, attributable. De-provision agents like employees. When an agent is decommissioned, revoke its credentials as part of that process. An orphaned agent secret should be a finding, not a footnote. Audit at the agent grain. Every action should be attributable to both the agent that took it and the human who delegated to it. If your logs cannot tell those two apart, you do not have an audit trail. You have a story you are choosing to believe. Why teams skip all of this Because the shortcut works, and the bill comes later. Agents are often described as shortcut-seekers by design, and the uncomfortable truth is that so are the humans deploying them. The fastest path from idea to working demo is to grab a token you already have and hand it over. Scoping it, giving it a short life, and wiring up real attribution is more work for something that already runs without any of it. The standing-access shortcut is invisible right up until an injected instruction, a bug, or a leaked secret turns it into an incident. The cost was never avoided. It was deferred, and it compounds with every new agent you add, which is a problem when the average is already a dozen and climbing toward twenty. The real maturity test When people ask whether an agentic system is ready for production, they usually mean: is the model good enough? That is the wrong question to lead with. The better test is whether you can answer four things about any agent you run. What can its identity do? For how long? On whose behalf? And how do I revoke it? If you cannot answer those, the problem you have is not really an AI problem. It is an ungoverned-identity problem wearing an AI costume. The good news is that our field already knows how to solve that one. We just have to remember to onboard our agents the way we onboard everyone else. \ Sources Salesforce, 2026 Connectivity Benchmark Report (Feb 2026): https://www.salesforce.com/news/stories/connectivity-report-announcement-2026/ Orchid Security, Identity Gap: 2026 Snapshot (May 2026): https://www.orchid.security/blog/news-two-thirds-of-nonhuman-accounts-are-unseen-and-unmanaged Sysdig Threat Research Team, AI Agent at the Wheel (May 2026): https://www.sysdig.com/blog/ai-agent-at-the-wheel-how-an-attacker-used-llms-to-move-from-a-cve-to-an-internal-database-in-4-pivots \ \