Your over-permissioned users are your over-permissioned agents

Most teams are thinking about AI agent security as a new problem. A lot of it isn’t. When an agent acts on behalf of a person, it borrows that person’s access. So the messy, half-governed pile of human permissions you already have doesn’t go away when you add agents. It gets a runtime and starts making API calls at machine speed.

That’s the part I don’t see discussed enough, so I want to make the case plainly: before you worry about what your agents can do, look at what the people behind them can do.

How an agent gets its reach

There are two ways an agent gets permission to touch a system.

The first is its own identity. The agent is a workload with its own service principal or managed identity, and you grant that identity specific access. This is the clean path, and it’s what you want for anything the agent does as itself.

The second is on-behalf-of (OBO). The user signs in, the agent takes the user’s token, and it calls downstream services as that user. This is incredibly common, because it’s the easy way to make an assistant “just work” with the data the user can already see. The catch is simple: an agent using OBO inherits the user’s entitlements. If the user is a Global Administrator, the agent is now operating with Global Administrator reach the moment someone slips it a malicious instruction.

So the agent’s blast radius isn’t really decided in the agent’s code. It’s decided upstream, in whatever access that human was carrying around.

Which means agent governance starts with people

Here’s the uncomfortable version. You can write perfect guardrails, scope every tool, and sign every token, and still hand an agent far too much power simply because the human it represents was over-permissioned. The sprawl you’ve been meaning to clean up in your directory, standing admin roles nobody uses, accounts that still have access from a project two years ago, privilege people inherited through a group they forgot they were in, all of that is now agent attack surface.

Over-permissioned users were always a risk. Agents just made that risk fast, repeatable, and harder to notice, because the agent won’t hesitate the way a careful human would.

The two halves of the problem

If you want to actually contain agent blast radius, you have to right-size both sides of the identity ledger.

The non-human side is the one people are starting to pay attention to: service accounts, workload identities, the agents themselves, their tokens and secrets. These are machine identities, and the OWASP Non-Human Identities Top 10 is a good map of where they go wrong, with over-privilege sitting right in the middle of it. I built a small open-source tool, nhi-scan, that inventories these and risk-tiers them against that list, including drift detection for when an agent’s reach quietly grows.

The human side is the one that gets skipped, because it feels like old-fashioned IAM hygiene and not “AI security.” But in an agentic world it is AI security, for the OBO reason above. So I built the companion: overreach, which audits a Microsoft Entra directory for over-permissioned human identities. Two tools, because people and machines fail differently, joined at exactly the point where a human’s privilege becomes an agent’s.

A concrete example

Picture an admin, call him Dave. Dave holds Privileged Role Administrator as a standing, always-on assignment, because that was convenient when he set things up. Dave also sponsors a new internal agent that helps the team process refunds, and that agent is wired with OBO so it can act for whoever is using it.

On paper you have a refunds assistant. In practice you have a refunds assistant that can, through Dave, touch role assignments across the tenant. Nobody designed that. It’s an accident of Dave’s leftover privilege meeting an OBO connection. A single successful prompt injection turns a helpful tool into a path to tenant takeover.

Fix Dave first, and the agent’s worst case shrinks before you’ve touched the agent at all. That’s the whole point: human right-sizing is the cheapest, highest-leverage control you have over agent blast radius, and almost nobody treats it that way.

But how do you even know who’s over-permissioned?

This is the hard part, and it’s worth being honest about it, because it’s where most “least privilege” talk falls apart.

“Over-permissioned” means someone holds more than they need. The problem is that “need” has no ground truth. There’s no clean record of what each person’s job actually requires. So you can’t compute over-privilege as a yes or no. You triangulate it from signals, each with a different confidence, and you treat the results as candidates for review with evidence, not as verdicts.

The signals that need no model of need are the ones to lean on first:

• Standing privilege that should be on-demand. A privileged role held as a permanent assignment when it could be eligible-only, activated just-in-time. Someone with Global Admin 24/7 instead of for the twenty minutes a month they use it is over-privileged in time, and that’s deterministic to find.
• Dormant privilege. An account that holds a powerful role but hasn’t signed in for months. Unused access isn’t needed access, and it’s a perfect target.
• Hidden, inherited privilege. Admin rights a person holds only through a nested group, the kind that never shows up in a quick look at direct role assignments.
• Sprawl. More Global Administrators than any tenant should have. Microsoft’s own guidance is to keep it to a handful.

The strongest signal of all is usage-based: compare the permissions someone was granted to the ones they’ve actually used, and the unused delta is your over-privilege. It’s the gold standard, and it’s also the hardest, because it needs real per-action telemetry. Dormancy is the pragmatic proxy until you have that.

If you’re on Azure, some of that usage-based work is already done for you. Microsoft folded the old CloudKnox permissions analysis into Defender CSPM, which flags stale and over-permissioned identities on your cloud resources. It’s worth pulling in — overreach ingests those Defender CSPM recommendations and merges them with its own directory-role findings, so you don’t have to look in two places. Just be clear on what Defender CSPM covers on its own: it looks at resource and RBAC permissions, not your Entra directory roles. So the Global Administrator sitting on a standing assignment, the admin inherited through a nested group, and the privileged user quietly sponsoring an agent are all invisible to it. That’s the point of surrounding it rather than leaning on it: native cloud tooling is a strong input for one plane, but it isn’t the whole picture, and it won’t draw the line from a human’s privilege to the agent that inherits it.

The discipline that matters is this: lean on the signals you can evidence, label the things that merely raise the stakes (a privileged account with no MFA is more dangerous, but that’s not the same as having too much access), and never claim a verdict you can’t back up. That honesty is what separates a real least-privilege program from a dashboard full of noise.

What to actually do

For the humans:

• Move standing privileged roles to eligible-only, activated just-in-time. This one change shrinks the window of exposure more than almost anything else.
• Strip privilege from dormant accounts, and disable the accounts.
• Make inherited admin explicit and reviewable instead of buried in group nesting.
• Keep Global Admins to a tiny, named set with break-glass handling.

For the agents:

• Prefer the agent’s own scoped identity over OBO wherever the agent acts as itself.
• Where OBO is genuinely needed, don’t let the agent wield the user’s full entitlement. Scope it down to the specific operation, use short-lived tokens, and authorize per tool.
• Require just-in-time elevation and a human in the loop for anything high-impact. An agent should not be able to move money or change roles on its own, ever.

And do it continuously. Least privilege isn’t a project you finish. It’s drift you fight. People accumulate access, agents gain tools, and the gap between granted and needed reopens the week after you close it.

One picture, both identities

The reason I built two tools instead of one is that they answer two different questions that only make sense together. overreach asks “which people hold more than they need?” nhi-scan asks “which machines and agents hold more than they need?” And where you have Defender CSPM, overreach folds its resource-permission findings in too, so directory roles, cloud resources, and machine identities all land in one place. Run them and you can trace the sentence that actually matters: this over-privileged admin sponsors these agents that inherit his reach. That combined human-to-machine blast-radius view is the thing I almost never see, and it’s exactly where agentic risk lives.

The headline is simple enough to put on a sticky note. Your agents are only as contained as the identities behind them. If you want to secure what your agents can do, start by right-sizing what your people can do, because in an on-behalf-of world those are the same question.

---

The tools. Both are open source and read-only. overreach audits your people (over-permissioned human identities in Entra); nhi-scan audits your machines and agents against the OWASP Non-Human Identities Top 10. Run both to see the human-to-agent blast radius in one picture.