RBAC Design for Non-Human Agent Identities
AI agents are rewriting themselves mid-task, and traditional permission systems can't keep up.
Non-human identities now outnumber human ones 144 to 1 in cloud-native environments, up from 92 to 1 a year ago. Most of that growth is AI agents: things that act, decide, and spawn other agents without a person signing off on each step, rather than service accounts doing one predictable job. Traditional RBAC was built for humans with job titles, and agents don't have job titles. That mismatch is where the risk actually lives.
What agents actually do that static service accounts never did
A classic non-human identity is boring, in the best possible way. An API key connects one system to another, does one thing, and its permissions get set at creation and mostly sit there until someone remembers to clean them up. Predictable is the whole point. Predictable is the whole point, and predictable is what makes them manageable.
Agents don't sit still like that. An agent runs through a sequence of steps, and the context can flip entirely between step one and step ten. It calls external APIs, writes code, runs that code, spins up child agents mid-workflow, at runtime, with nobody approving the spawn.
If an agent already has enough access, it can call the cloud platform's own RBAC APIs (Azure RBAC, for instance) and grant itself more privilege. No approval flow, no human in the loop. Cloud platforms will also let agents mint short-lived credentials or managed identities on demand, often without so much as an inventory entry. New integrations get bolted on mid-workflow, and no review cycle catches it.
So the job itself changes shape. Assigning permissions to a fixed thing gives way to governing a process that rewrites its own footprint while it's running. Gartner puts it at 33% of enterprise applications carrying agentic AI by 2028, up from under 1% in 2024. That's not a lot of runway to fix a design flaw before it hits real scale.
The current state of NHI governance, and why it is not close to adequate
Start with the number that should stop you cold. Entro Security's 2025 State of NHI report found 97% of non-human identities carry excessive privileges. That figure is worth pausing on. Ninety-seven percent.
Everything else in that report reads like a system failing on several fronts at once. Sixty percent of NHIs get reused across more than one application, which wrecks any clean idea of accountability before you've even started. Seventy-one percent go unrotated past their recommended window. Forty-four percent of tokens turn up exposed somewhere like Jira, Confluence, Teams, or sitting in a code commit where anyone with repo access can grab them.
Visibility is maybe the worse problem. Only 5.7% of organizations can accurately inventory every NHI they run, and 40% of cloud NHIs have no owner attached at all. You can't govern what you can't name, and right now most companies can't name most of their own identities.
Confidence tracks with that mess. A CSA survey found only 15% of IT and security professionals felt highly confident they could prevent an NHI attack, while 69% said they were worried about it happening to them. Narrow the question to agents specifically and it gets worse: a separate survey found only 23% have a formal agent identity strategy, and just 18% are confident their IAM can manage agent identities at all.
Agents are dropping into an environment that was already failing at static identities. Now the identities move faster, multiply on their own, and don't wait for anyone's review cycle.
Where traditional RBAC's three core pillars break under agent conditions
RBAC rests on three ideas: assign a role based on job function, grant that role the least privilege it needs, and separate duties so no single actor controls a whole sensitive process. Each idea assumes something about the identity being governed, and agents fail every one of those assumptions.
Role assignment assumes a stable job function. A human's role maps to a spot on an org chart that rarely changes. An agent has no such anchor; it might get deployed today to pull customer data and get re-invoked tomorrow to execute code, same identity, completely different access needs. A role fixed at deployment can't capture that kind of task-scoped, short-lived need, so teams over-provision instead, because that's the path of least resistance. Straight line back to that 97% figure from Entro.
Least privilege assumes you can define a stable minimum. For a human employee, that minimum is whatever the job requires, a bounded list reviewed once a year and mostly trusted. For an agent working through a multi-step task, the minimum shifts every step; what it needed at step three, it didn't need at step one. Set the grant too tight and the agent breaks mid-task. Set it wide enough to cover the worst case and you've defeated the entire point of least privilege. Just-in-time scoping is the fix, but most IAM tooling running in production today was never built to make permission calls at that speed.
Separation of duties assumes you can tell actors apart. That's the whole premise: distinct, accountable parties. When one agent orchestrates several sub-agents, hands them tasks, reads their output back, the line between "one actor" and "several actors" blurs fast. OWASP's NHI Top 10 names the mirror image of this directly: NHI10, Human Use of NHI, where a developer borrows an agent's credentials for some manual task. Once that happens, agent actions and human actions look identical in the log, and separation of duties has nothing left to check.
The three pillars share the same weakness rather than three separate ones. They break because all three assume the identity being governed is bounded, passive, stable, and an agent is none of those things.
The OWASP NHI Top 10 risks that directly shape RBAC design choices for agents
OWASP released the NHI Top 10 for 2025, and it's the first framework I've seen that classifies non-human identity risk with any real rigor. Four entries map straight onto RBAC decisions.
NHI5, Overprivileged NHI, is the most direct hit. Developers grant more privilege than a task needs during the build, and no review cycle ever comes back to trim it down. With an agent, the fallout from an over-privileged identity lands faster and spreads wider, because the agent acts on its own, at speed, well before anyone notices something's off.
NHI7, Long-Lived Secrets, points straight at short-lived credentials as the fix: AWS Roles, Azure Managed Identities, SPIFFE SVIDs. The principle underneath is simple. A credential should expire when the task it was issued for ends. For agent RBAC, that means role bindings tied to the task or session, never persistent by default.
NHI1, Improper Offboarding, catches the lifecycle gap agents fall straight into. An agent wraps a project, or gets swapped for a newer version, and nothing about that triggers deprovisioning. Old credentials from retired agent versions just sit there as exploitable blind spots. Research found tens of millions of leaked NHI credentials on GitHub in 2025, and a large majority of the leaked credentials from 2022 remained valid years later.
NHI10, Human Use of NHI, quietly wrecks your audit trail. A developer uses an agent's credentials to debug something by hand, and now the log can't tell you whether a human or the agent took that action. RBAC design has to enforce credential separation here and flag, or outright block, interactive human sessions running on agent identities.
The value of a framework like this isn't abstract. It gives everyone building agent RBAC a shared vocabulary for what goes wrong, and every design choice from here traces back to one of these failure modes.
Adapting role assignment: task-scoped identities and purpose-bound credentials
Fixing this starts with rethinking what a "role" even means. A broad role like "data-processing-agent" carrying a wide permission set gives way to roles defined at the task level: "invoice-extraction-task" gets access to exactly what that task touches, nothing more. Role assignment stops being about what the agent might need over its entire lifetime and becomes about what it's doing right now, in this moment, for this call.
Purpose-bound credentials make that real. Each invocation, each workflow session, gets credentials scoped to that specific declared purpose. The tooling already exists to support this: AWS IAM Roles for service accounts, Azure Managed Identities, SPIFFE and SPIRE SVIDs all support it. What's missing is organizational will and the grunt work of wiring it into pipelines that were never built for it.
None of this works without a registry, though. An agent that isn't registered can't get a task-scoped role in the first place, so registration has to happen before the agent operates, not as an afterthought someone checks off during an audit months later. Entro's 2025 report found 92% of organizations already expose NHIs to third parties. Unregistered agents only widen that gap.
Sub-agents add their own wrinkle. When a parent agent spawns children, each child needs its own task-scoped identity, and that identity's permissions should be explicit and narrower than the parent's, never a straight copy-paste. Underneath it all sits one design principle: an agent's role should expire when its task does. Inactive is the default state. Permissive should never be.
Adapting least privilege: from static minimum to just-in-time, step-scoped access
Static least privilege fails for the same reason static role assignment does. The minimum access an agent needs at step one isn't the minimum it needs at step five, so a fixed grant either blocks the agent partway through or over-provisions it up front to cover every possible step. Neither outcome works, and pretending otherwise is how you end up back at 97%.
Just-in-time access actually fits the shape of the problem. Permissions don't get pre-granted at deploy time; they get requested and evaluated the moment they're needed, scoped to that one action's duration. The authorization layer has to answer a much longer question than any static role lookup ever asked, something like: which agent, acting on whose behalf, requesting what action, on which resource, in which tenant, under what conditions, evaluated per invocation. That's heavier computationally than checking a role table, and any honest design has to budget for the added latency in workflows running in real time.
Short-lived credentials are what turn JIT from an aspiration into something enforceable. Token lifetime should match the task's duration, not the session's; a credential that outlives its task breaks least privilege even if the scope was correct the moment it got issued. Automatic expiry also solves NHI7 without leaning on manual rotation, which is exactly the process 71% of organizations are already failing to keep on schedule.
Condition-based controls stack on top of the JIT grant itself. Restrict access to business hours, or to records within one tenant, or to cases where the workflow hasn't already touched a conflicting resource in that same session. This is where attribute-based access control meets the JIT model, filtering when a role's permissions are actually live rather than just what they cover.
JIT access without a gateway logging every grant and every denial in real time gives you no audit trail at all. Designing least privilege and designing observability for agents turn out to be the same project.
Adapting separation of duties: distinguishing agent identities in multi-agent pipelines
The core problem with SoD in agent pipelines is identity, not process. SoD depends on multiple distinct, accountable actors touching a sensitive operation. An orchestrator agent that spawns sub-agents and then reads their output back can make that distinction vanish entirely; it's arguably one actor wearing several hats at once.
Fixing it starts with unique, non-shareable identity for every agent in the pipeline. Credential reuse, which OWASP catalogs as NHI9, makes SoD unenforceable in practice. If two "copies" of the same identity can both take an action, there's no way to say which one actually did it.
Delegation needs its own rules, too. When a parent agent hands work to a child, the child's permission scope has to be defined explicitly and kept narrower than the parent's; delegation should never just copy the parent's access wholesale. And the full chain, user to orchestrator to sub-agent to tool, needs logging end to end. A sub-agent's action has to trace back through that whole chain, not just get tagged with the sub-agent's own identity in isolation.
Privilege escalation inside the pipeline is the other failure mode worth designing against directly. A sub-agent should never acquire permissions the orchestrating agent itself doesn't hold; there's no legitimate reason for upward inheritance, ever. Runtime checks need to verify a delegation request doesn't open a permission path that would've been rejected outright had the sub-agent asked for it directly.
NHI10 shows up here again, in a slightly different shape. If a developer can borrow an agent's credentials for manual debugging mid-pipeline, the audit log loses the ability to tell human action from automated action. At that point separation of duties weakens to the point of disappearing, because the record you'd need to prove it ever existed can't be trusted either.
