SECURITY · July 1, 2026
Your agents have logins nobody owns
Enterprises spun up millions of AI agents this year, and every one of them needs credentials to actually do anything — read the database, send the email, hit the API. The governance layer for those credentials doesn't exist yet. The result: 68% of organizations can't reliably tell an agent's activity apart from a human's, and live credentials are writing to production with no person accountable. The agentic enterprise's real security problem isn't prompt injection. It's identity.
Every security conversation about agents fixates on the exciting attacks — prompt injection, tool poisoning, a fake bug report that hijacks your coding agent. Those are real. But the quiet, boring, much bigger problem is this: your agents log in, and nobody owns those logins.
The population exploded; the governance didn't
To do anything useful, an agent needs credentials — a key to read the database, a token to send the email, an API scope to book the appointment. This year organizations minted those by the million. Microsoft Copilot Studio users alone created over a million agents; Salesforce reported around $440M in agentic revenue. Each of those agents is, in security terms, a new user with a password — except no one onboarded it, no one owns it, and it never leaves.
And the systems to govern that population don't exist yet. Okta found that 68% of organizations cannot reliably distinguish AI agent activity from human activity. The Cloud Security Alliance named it outright: the "Non-Human Identity Governance Vacuum." It's why identity for agentic AI dominated both RSAC and Identiverse this year.
An agent you can't tell apart from a person is an agent you can't audit, can't revoke, and can't hold to a policy. That's not an AI problem. That's an unmanaged account.
Why this is worse than a clever attack
A prompt-injection exploit needs an attacker to craft something. This risk needs no one. It's just sitting there: a credential with broad access, used by software that acts on its own, logging as if it were a human — so when something goes wrong at 3am, you can't answer the only questions that matter. Which agent did this? Who deployed it? What was it allowed to touch? Who do we turn it off? If the agent shares a service account or a human's token, the honest answer to all four is "we don't know."
Treat an agent like an employee, not a shared key
The fix isn't a product you buy; it's a discipline you already know from managing people:
- Its own identity. Every agent gets a distinct, first-class identity — never a shared service account, never a human's borrowed token. If you can't name the agent behind an action, you can't govern it.
- Least privilege, scoped to the task. The booking agent can touch bookings. Not the payroll table, not the admin API. Most breaches are just over-broad credentials waiting for a bad day.
- An owner and an expiry. Every agent identity has a human owner and a lifetime. Agents that outlive their purpose are the unmanaged accounts of the next audit.
- Auditable and revocable. You can see exactly what each agent did, and you can kill its access in one move — without taking down a person's account with it.
This is the same principle I keep coming back to for agent safety: least privilege and a hard boundary beat any prompt-level promise. Identity is just least privilege for the actor instead of the action.
The bottom line
You didn't deploy a feature this year. You hired a thousand employees, gave them keys, and never made badges. The agentic enterprise's biggest exposure isn't a clever exploit — it's the ordinary, ungoverned account, multiplied by a million.
Give every agent its own scoped identity, an owner, and an off switch — before you can't tell which one just wrote to production.
Comments
No comments yet
Sign in to join the conversation.
Be the first to share a thought.