An AI agent is a service account that learned to think. It holds credentials, carries permissions, calls systems, and acts on its own, the only new part is that it now decides what to do next. That should sound familiar to anyone who has run enterprise infrastructure, because we already built millions of non-human identities that act without a person watching, and we already know how badly we govern them. Veza's 2026 State of Identity & Access report found machine identities outnumber humans 17 to 1, and that just 0.01% of those non-human identities hold 80% of all cloud permissions. Agents are about to add a population that grows on its own.
I have spent seventeen years in enterprise network security, and most of that time was not spent stopping clever attackers. It was spent cleaning up access nobody owned: firewall rules whose requester left years ago, service accounts with passwords in a script and admin rights nobody could justify, tokens that outlived the project that needed them. The AI-agent wave is that same problem with an engine bolted on, and I want to explain why the people who cleaned up the last mess are the ones who can see this one coming.
The access nobody owns
Every estate I have audited has the same archaeology. A permit rule added at 4pm on a Friday to ship a release, still in the rulebase a decade later. A service account created for a one-off migration, never deleted, now holding domain admin. An integration token pasted into a config file by someone who has since changed companies twice. Nobody is malicious. Everybody was busy. Access was granted under pressure and never revisited, because revisiting access is unglamorous work that no deadline ever rewards.
The numbers say nothing changed except the scale. Veza found dormant accounts already make up 38% of all accounts, and counted 824,000 orphaned identities with live entitlements and no human owner in the HR system. That is not an AI statistic. That is the ordinary state of enterprise identity in 2026, before agents arrive. We never solved the access-nobody-owns problem for service accounts. We are about to inherit it again, multiplied, for things that act on their own initiative.
Why agents make it worse, not just bigger
A neglected firewall rule is at least static. It does what it did yesterday until a human changes it. An AI agent is not static: it requests tools at runtime, spawns sub-agents, and chains actions across systems that were never designed to trust each other. The access graph now grows between your reviews, on its own, which is a property no service account ever had.
And the credential hygiene around them is already poor and getting worse. GitGuardian's State of Secrets Sprawl 2026 found AI-service secrets leaked to public GitHub reached 1.27 million, up 81% in a year, and that commits written with the help of a coding agent leaked secrets at 3.2%, against a 1.5% baseline, the tool you adopt to move faster leaks keys at twice the rate. The same report counted 24,008 secrets in Model Context Protocol config files alone, with 2,117 still valid. The plumbing that connects agents to tools is the new place keys go to die in plain sight. I put the measurement side of this on a risk register in moving from CVSS to attack-success rate for AI.
An agent fails the way a service account fails
When a service account gets abused, there is rarely a clever exploit. The attacker phishes a credential or finds a key in a repo, then uses the standing access the account already had. No privilege escalation needed, because the privilege was sitting there. An AI agent fails the same way. It does not need to break out of the model; a hijacked agent simply uses the authority you already handed it. That is the confused-deputy pattern I have written about for the model layer in prompt injection as a confused-deputy problem, and it is why the load-bearing control is the identity, not the prompt. You cannot reliably stop the agent being fooled. You can decide how little it holds when it is.
Only 15% of organisations feel confident they can prevent a non-human-identity attack, per the Cloud Security Alliance's 2026 survey, and more than 16% do not even track the creation of AI-related identities. That gap is not an AI-skills gap. It is the same identity-governance gap that has been open since the service-account era, now exposed to actors that can act faster than your quarterly access review.
The discipline transfers exactly
Here is the good news, and the reason I came at AI security from network security rather than the other way around. The fix is not new. The trade learned it the expensive way and wrote it into every framework we answer to. An AI agent is an identity, so govern it like one.
| The lesson I learned on the network | How it applies to an AI agent |
|---|---|
| Every rule has a named owner | Every agent has a named human owner, recorded at creation, or it is a future orphan |
| Recertify rules on a cycle | Review each agent identity: still needed, still scoped right, or revoke it |
| Decommission what the project no longer needs | Kill the agent and its credentials when the work ends, do not let it join the dormant 38% |
| Least privilege on source, destination, service | Scope the agent to the task, short-lived credentials, default-deny on the tools it can call |
| No change without reviewable evidence | Log which agent did what, under whose authority, on what input |
None of that is exotic. It is the discipline behind enterprise firewall automation, redrawn for a surface that did not exist when the controls were written. The frameworks already cover it. ISO 27001 Annex A asks for identity lifecycle and privileged-access management with no exemption for non-human identities. NIS2 and DORA both demand access control and asset management over every component that can affect operations, and an autonomous agent is squarely a component. I make the broader European case in AI security consulting for European enterprises.
What to do before your agent count gets away from you
The window to do this cheaply is now, while you have a handful of agents and not a population. Every one of these has a firewall ancestor, which is exactly why it works.
- Inventory the non-human identities you already have. Service accounts, tokens, OAuth apps, and every agent. You cannot govern what you never registered, and the registration is finding number one in any audit.
- Give every agent an owner and an expiry. An agent with no human accountable for it is the 824,000-orphan problem in the making. Record the owner at creation or do not ship it.
- Scope to the task, expire the credential. A document-summarising agent has no business holding production database access. Short-lived, narrowly scoped credentials make a leaked token worthless within minutes.
- Put agents in your access-review cycle. If you recertify human access annually and never review machine identities, you are auditing the wrong half of your estate.
- Log against the identity. "Which agent, on whose behalf, with what permission" is the first question after any incident, and the hardest to answer retroactively.
Why this lens is worth borrowing
I did not arrive at AI security from research. I came from PAN-OS, Check Point, Cisco and Fortinet, from OT segmentation and ISO 27001 audits, into AI. That order is the whole point. The agent failures landing in 2026 are not novel AI problems; they are identity-governance problems wearing a model on top, and the people best placed to see them are the ones who already spent a career cleaning up access nobody owned. I argued the same convergence from the incident side in why a firewall CVE and an AI-agent breach are the same mistake, and I have shipped production AI under this discipline, written up in the lessons from building RogueAI.
You do not have to relearn identity governance the way the network world did, one breach at a time. The answer is already written down. Treat every agent as an identity you own, scope, review, and can switch off, and the agentic wave becomes a known problem with a known cure rather than the next decade of orphaned access waiting for an auditor to find it.
Deploying AI agents and not sure who owns the access they hold? That gap is reviewable now rather than after an incident. I run engagements that bring enterprise identity and network-security discipline to AI workloads: ownership, least privilege, lifecycle, and change control built to survive a real audit. Request a review. See also FwChange.com for firewall change automation and RogueAI for the production AI portfolio.