Your AI agent inherited your permissions. That is the problem.

The fastest way to put an AI agent to work in a company is also the one identity teams have spent twenty years trying to clean up after. You take a person's account, or a copy of it, and hand it to the agent.

It is the default almost everywhere. An agent needs to read email, open tickets, query a database and file an expense. The quickest path is to run it as the employee it works for, or as a service account cloned from that employee's role. The agent is live in an afternoon. Nobody has to design a new permission model, because the agent simply uses the one the human already has.

The trouble is that the human's permission set was never designed either. It accumulated. And the identity industry has a long, well documented record of how badly that accumulation goes.

This article looks at three things: what two decades of access data say about the permissions an agent is about to inherit, why the inheritance makes an old problem worse rather than merely larger, and why a growing number of practitioners argue the fix is not a better copy of the human's access but a separate question asked of every action the agent takes.

Twenty years of getting human permissions wrong

The identity industry has been selling tools to fix human access since the mid 2000s. Provisioning, role mining, access certification, least privilege. The results, measured by the vendors' own telemetry, are not encouraging.

Veza, an access governance vendor, analyzed more than 230 billion permissions across its customer base and reported late last year that the average worker holds about 96,000 permissions across applications, data stores and infrastructure. In the same dataset, 38% of identity provider users were dormant, meaning no activity in 90 days but still able to log in, and about 8% were orphaned, with no owner in any HR system. Roughly 78,000 accounts belonging to former employees still had active credentials. The share of permissions Veza classified as safe and compliant fell from 70% in 2024 to 55% in 2025 (Help Net Security, covering Veza's report).

Sonrai Security, which watches cloud identities, reported in May that 92% of identities holding sensitive cloud permissions had not used them in a 90 day window. Of those idle identities, 87% were machine accounts rather than people (Sonrai Security).

The consequences show up in breach reports. In the Cloud Security Alliance's 2025 State of Cloud and AI Security survey, 31% of organizations that had a cloud breach named excessive permissions as a cause, and 27% named weak identity hygiene, a category that covers unused credentials and orphaned accounts (Cloud Security Alliance).

None of this is news to anyone who has run an identity program. The pattern is familiar: a person joins, gets a role copied from a colleague, changes jobs twice, keeps everything from each job, and sits through quarterly access reviews that managers approve in bulk because the list is 400 lines long and the deadline is Friday. The vendor figures are the aggregate of that story told a few million times.

What is new is who is about to receive those permission sets.

The inheritance problem

When an agent runs under a human's account, or under a copy of that human's entitlements, it does not receive the access the task needs. It receives everything the human has, including the 96,000 permission average, the entitlements left over from two jobs ago, and the shared drive nobody remembers granting.

That is the first half of the problem, and it is simple arithmetic. If the human's permissions are wrong, the agent's are wrong in exactly the same way. There is no cleansing step in the copy.

The second half is where the agent changes the picture. A person with 96,000 permissions uses a small fraction of them, because a person does one thing at a time, gets tired, and has habits. An agent has none of those limits. It can touch every system it is entitled to touch, in parallel, around the clock, and it will go wherever the task leads it, including into systems the human technically had access to but never opened. Standing access that was dormant in human hands becomes active in the agent's.

The copy carries every defect in the human's permission set forward. The agent then exercises access the human left idle, and passes it on.

Two more things compound it. Agents delegate. An agent that spins up a helper agent passes its access along, so one inherited permission set can become several, with no human in the chain after the first. Our delegated authority page covers that chain in more depth. And agents are often short lived, which means the account reviews that were supposed to catch bad access on a quarterly cycle never see them at all.

Bad data in, bad process out

If there is one lesson the identity field has taught and retaught for two decades, it is this one. Every identity program rests on data it did not create: the HR record that says who reports to whom, the role catalog that says what a job needs, the application's own account list. When that data is wrong, the controls built on top of it are wrong, and no amount of workflow fixes it.

Identity veterans will recognize the sequence. A company buys a provisioning system and discovers its HR data has three spellings of every department. It buys an access governance platform and discovers it cannot say what half the entitlements actually do. It launches role based access and discovers the roles were mined from the same bloated permission sets it was trying to fix. Each tool automated the existing mess faster.

Agent inheritance is the same sequence with a new name. The permission data is the input. Twenty years of telemetry say that input is unreliable: dormant, orphaned, over-provisioned and under-reviewed. Build the agent's authority on it, and the agent's behavior inherits every defect, now executed at machine speed with no one watching the individual steps.

The usual response is to clean the data first. Run the access reviews properly this time. Get to least privilege. It is the right instinct, and organizations should keep doing it. But it has been the plan for twenty years, and the Veza and Sonrai figures above are what the plan has produced so far. Waiting for human permissions to be correct before deploying agents means not deploying agents.

Governing the decision, not the credential

A different approach is gaining ground among practitioners who have lived through the access cleanup cycles. It starts by conceding the point: the inherited permission set will be wrong, and may stay wrong for years. So stop treating it as the control.

Instead, add a second layer that asks a different question. Access control asks, can this identity reach this system? Decision governance asks, should this action happen at all, right now, under these conditions? The second question does not depend on the answer to the first. An agent can hold a valid, inherited permission to approve a vendor payment and still be stopped from approving this payment, because the amount is outside what anyone authorized the agent to decide, or because the vendor was added yesterday, or because approving payments was never in the agent's mandate in the first place.

The first layer inherits whatever the human had. The second layer asks whether the action belongs in the agent's mandate, and resolves it without relying on the first.

The layer works on what the agent is trying to do, not on what it is allowed to touch. Each consequential action is checked against a written scope of decisions the agent may make, with limits, and resolves to one of a few outcomes: let it proceed, send it to a person, block it, or let it proceed and flag it for review. The inherited permissions remain as they are. They just stop being the thing that decides. Our human to agent authority and runtime authorization pages describe the mechanics.

This is a position, not a settled standard, and it has honest critics. One objection is that it adds a second policy set to maintain on top of the first. Another is that writing down what an agent may decide is hard, and organizations that could not define roles for people will struggle to define mandates for agents. Both are fair. The counter from its advocates is that a mandate describes a handful of decisions, while an entitlement set describes tens of thousands of permissions, and the smaller object is the one you can actually get right.

There is also a precedent. Financial controls have worked this way for a long time. A clerk may have the system access to move money, and still cannot move more than a set amount without a second signature. Nobody thought the answer to wire fraud was a cleaner permission list. The control sat on the transaction.

What this means for the teams deploying agents now

The practical implications are narrower than the debate suggests.

First, inheriting a human's access is not going away as a deployment pattern. It is too easy, and most agent platforms assume it. Teams should expect it and plan around it rather than pretend a clean service account model will arrive first.

Second, the access hygiene work still matters. Dormant and orphaned accounts are the raw material for inherited access, and shrinking them shrinks the problem. But it should be treated as a long campaign, not a prerequisite.

Third, the question worth asking of any agent going into production is not only what it can reach, but what it has been authorized to decide, by whom, within what limits, and what record would show that limit held. If the only answer is the human's permission list, the organization has outsourced its agent's authority to twenty years of access debt.

The open questions are real. Who owns the mandate for an agent that serves several departments? How does the decision layer learn about actions it has never seen? What does an auditor accept as proof? None of these are settled, and the vendors in this space, including the one this author founded, have positions rather than answers.

What is settled is the arithmetic. Copy a permission set that is 55% compliant into something that runs faster and tries more than any person, and the result will not be more compliant. The identity industry has already run that experiment, with humans, for two decades.

Frequently asked questions

If we move agents to dedicated service accounts, does the inheritance problem go away?

Partly. A dedicated account avoids copying a person's leftovers, but in practice it is usually scoped by copying a role, and the role was mined from the same over-provisioned data. It also does nothing about what the agent decides inside the access it holds. A service account with a narrow, correct permission set can still approve the wrong payment.

Is this just least privilege by another name?

No. Least privilege shrinks what an identity can reach. Decision governance checks whether a specific action should happen, under a written scope with limits and an owner, regardless of what the identity can reach. The two work together, but the second does not depend on the first being finished.

Why not fix the human permissions first and then deploy agents?

Because the data says that fix has been in progress for twenty years and the compliant share of permissions fell last year. Organizations should keep doing the hygiene work. Making it a prerequisite means agents wait indefinitely while the access debt is used anyway.

---

Sources. Help Net Security, Non-human identities push identity security into uncharted territory, December 30, 2025, covering Veza's access report. Sonrai Security, Why 92% of cloud permissions are never used, May 26, 2026. Cloud Security Alliance, Identity security: cloud's weakest link in 2025, September 19, 2025, citing the CSA State of Cloud and AI Security 2025 survey. Vendor telemetry reflects each vendor's own customer base, not a random sample of enterprises. The decision governance framing in this article is a practitioner position, not an industry standard.