- The most likely AI-agent security failure is not a jailbreak or hallucination but an agent correctly using an over-privileged credential to do unintended damage.
- Non-human identities already outnumber humans by about 100:1 in enterprises, and 97% of them have more access than they actually use, creating a large blast radius for agents.
- Because agent actions authenticate and authorize normally, a serious breach can look like routine system behavior rather than an obvious attack.
- Agent rollouts tend to multiply unmanaged credentials, especially when broad access is granted during pilots and never tightened or rotated.
- The real risk comes from weak identity governance: many organizations don’t apply human-grade controls to agents even while leaders remain confident in their IAM posture.
The agent failure worth preparing for is not the jailbreak or the hallucination, it is the agent doing exactly what it was told with a credential nobody scoped down.
Non-human identities now outnumber humans by 100 to 1 in most enterprises, and 97 percent of them carry more access than they use.
Treat agent credentials as disposable and task-scoped, because the cleanup, not the build, is where deployments quietly rot.
One Identity made a prediction earlier this year that I have not been able to shake. Sometime in 2026, they said, a major company will trace a serious breach back to a single over-privileged AI agent. The unsettling part was the second sentence. It will not look like an attack. It will look exactly like the system doing what it was designed to do.
That line is the whole problem in miniature. Everyone preparing for agent security is preparing for the wrong failure. They are building prompt-injection filters and jailbreak detectors and red-team harnesses, all aimed at the moment an agent gets tricked into doing something it should not. Those defenses matter. But the failure that actually shows up in the postmortem is duller and harder to catch. An agent that was handed a service account key on day one, never had that key narrowed, and then one afternoon used it for something nobody anticipated. No exploit. No anomaly. Just standing access meeting an unexpected instruction.
The numbers nobody is acting on
I have started asking teams a simple question when they tell me their agent rollout is going well. How many credentials does your agent hold, and who can revoke them. The pause that follows is usually the answer.
The data backs up the pause. Non-human identities, the service accounts, API keys, and tokens that machines use to authenticate, already outnumber human users by roughly 100 to 1 in most enterprises, and some organizations report ratios closer to 500 to 1. Of those identities, 97 percent carry excessive privilege, meaning they can reach far more than their job requires. Seventy-one percent of machine identities are not rotated within recommended timeframes. And in a finding that should stop any security lead cold, just 0.01 percent of machine identities control 80 percent of cloud resources.
Agents do not improve those numbers. They multiply them. Every agent you deploy is a new non-human identity, often spun up fast, often handed a broad key because scoping it tightly was friction nobody had time for during the pilot. Okta's 2026 survey of nearly 800 executives and knowledge workers found that only 34 percent of organizations apply the same security controls to AI agents that they apply to human employees. In the same survey, 96 percent of executives said they were confident in their identity and access management for non-human identities. Both numbers are true at once, which tells you the confidence is not coming from the controls.
Why this failure hides
A human employee who leaves the company gets deprovisioned. Their badge stops working, their accounts get disabled, someone owns that offboarding. An agent has no such moment. It does not quit. It does not change teams. It just keeps holding whatever you gave it, indefinitely, and the broad key you issued during the demo becomes the broad key it carries in production six months later.
This is why the breach looks like the system working. The agent authenticates correctly, because its credential is valid. It accesses the resource, because its credential is authorized. It performs the action, because that is what the instruction asked for. Every individual step passes every check. The failure is not in any single step. It is in the gap between what the agent was allowed to do and what it ever actually needed to do, a gap that 97 percent figure says is the default state, not the exception.
The teams that get burned are not careless. They are the ones who treated the agent like a feature to ship rather than an identity to govern. They set the bar for what the agent should accomplish and never set the bar for what it should be permitted to touch.
What scoping down actually looks like
The fix is not exotic, and it does not require waiting for a new category of product. It requires deciding that agent access is temporary by default.
Start with the worst offenders. You do not need to right-size every machine identity this quarter. Find the top 10 percent by permission scope, the agents and service accounts that can reach production infrastructure, financial systems, or customer data, and fix those first. That is where a single over-privileged identity turns a bad afternoon into a disclosure filing.
Stop issuing permanent keys for anything new. A no-permanent-credentials policy for new agent deployments costs you almost nothing on day one and saves you the cleanup you would otherwise never get to. The credential an agent receives should expire, ideally tied to the completion of the task it was issued for rather than to a calendar date someone will forget to enforce.
Scope to the task, not the role. A human gets a role because they do many things over years. An agent usually does one kind of thing, over and over, and that narrowness is a gift. An agent that summarizes support tickets does not need write access to the ticketing system, and certainly does not need the database credential someone handed it because it was the key already lying around. Issue the minimum, scoped to the specific action, with an expiry attached.
Log the delegation chain. When an agent acts, you want to be able to trace the authorization back to the human who initiated it, especially in multi-agent setups where one agent hands work to another. If you cannot answer "on whose authority did this agent do this," you cannot investigate the incident when it comes, and you cannot prove it did not happen when someone asks.
The discipline is the offboarding
I keep coming back to the framing that the most useful agent governance is not about what you let an agent do. It is about how cleanly you can take it back. Building the agent is the easy half. Anyone can wire a model to a tool and a key and watch it work in a demo. The half that separates a real deployment from a liability is the part nobody films: the scoping, the expiry, the revocation path, the inventory that tells you which keys are out and who holds them.
One Identity's prediction will probably come true this year, and when it does, the company at the center of it will not have been hacked in any way that feels like being hacked. They will have built something that worked, and kept working, right up until it worked against them. The agents are not the risk. The keys you forgot to take back are.
Sources: Okta, "AI Agents at Work 2026"; Cybersecurity Tribe, "The Non-Human Identity Risk Behind AI Agents"; KPMG 2026 Cybersecurity Report; One Identity 2026 predictions.
Treat every agent as an identity that must be governed, not just a feature to ship. Inventory what credentials each agent holds, ensure someone can revoke them quickly, and scope access to the smallest set needed for each task with short-lived, rotated secrets. Assume pilot-era permissions will linger unless you build cleanup and periodic reviews into the deployment process, and watch for “normal” authorized actions that are simply broader than the agent ever needed.