Shadow AI Does Not Read Your Org Chart: Rethinking Identity Governance for Autonomous Agents

RBAC is solving yesterday's identity problem while autonomous systems are making decisions with access they already have.

At RSA Conference 2026, Adi Shamir, the "S" in RSA, warned the security professionals that he is "totally terrified" of AI agents, because they need access to everything to be useful, and he does not extend that kind of access even to his own wife [1]. Most CISOs are living a quieter version of that fear. Enterprise AI agent deployments are growing tenfold in months rather than years. Yet a 2026 industry survey found that while 90% of organizations claimed visibility into their AI footprint, 59% admitted shadow AI was operating outside governance [2].  Both numbers cannot be true together, and the gap between them is exactly where role-based access control quietly stops working.

RBAC is not dead. It is just answering the wrong question. We do not have an authorization problem because RBAC failed. We have one because autonomous software now makes thousands of decisions after authentication succeeds. A role tells you what a person is allowed to do. It has nothing to say about what an autonomous agent decides to do with that access, in real time, without anyone in the loop to approve it.

RBAC made sense when enterprises were static.  People had jobs mapped to roles, and roles mapped to permissions. Auditors could trace any permission back to a job function. That model breaks down the moment access is granted to something that is not a person. Most agent deployments today still authenticate with a shared service-account key or a long-lived API token baked into a config file. The same credential gets reused across every instance, every task, every session. It is a classic confused deputy problem. RBAC can tell you the service account is allowed to touch the resource. It cannot tell you which agent instance made the call, on whose behalf, or what the role was meant to authorize.

Consider two scenarios that are already becoming common inside enterprises. A "security operations agent” granted read access to incident data for triage can, under standard RBAC, inherit adjacent permissions that trigger remediation actions no analyst approved. A "procurement agent” authorized to process vendor invoices does not stop being "authorized" at 7:49 p.m. or after the fifth transaction. RBAC has no concept of time, volume, or behavioral drift. In both cases, the role was correctly assigned, and the access was still wrong.

That is the central failure. RBAC governs identity at login, with credentials that stay valid until someone remembers to revoke them. Agentic systems make decisions continuously, long after login, and most identity providers have no way to reach into an active session and pull the plug mid-task. The OpenID Foundation’s Continuous Access Evaluation Profile (CAEP) exists to close that gap [3]. It pushes a real-time "session revoked" signal to every system relying on that session, instead of waiting for a token to expire on its own.

Effective runtime authorization separates policy decisions from policy enforcement. Every action is evaluated against current context before it reaches the API gateway or tool the agent is trying to use. Two existing standards do most of the heavy lifting. SPIFFE and its SPIRE implementation [4] issue every agent instance its own short-lived, cryptographically verifiable identity (an SVID) instead of a shared static key, so "which agent did this" stops being a logging question and becomes a provable one. OAuth 2.0 Token Exchange (RFC 8693) [5] handles delegation itself. When an agent acts on behalf of a user or another agent, it receives a narrowly scoped, short-lived token reflecting only that specific task, carrying an explicit actor claim, rather than inheriting the full permission set of whoever it is "acting for."

None of this makes RBAC obsolete. It remains the correct baseline for what an identity is generally entitled to. But baseline entitlement and runtime authorization are different problems, and in most 2026 stacks, SPIFFE, token exchange, and CAEP still sit in separate corners instead of wired together around agent identity.

Security leaders do not need another framework diagram. They need to know one operational metric: how quickly can they stop an autonomous agent once it starts behaving unexpectedly? The question is not whether AI agents deserve identities. They already have them. The question is whether we can govern what they decide after authentication succeeds.

References

[1] RSA Conference 2026, Adi Shamir keynote/panel remarks on AI agents, RSA Conference 2026, March 2026.

[2] ISACA, "RSA 2026: The Agent Revolution Is Already Here" (ArmorCode research on AI visibility vs. shadow AI), https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2026/rsa-2026-the-agent-revolution-is-already-here

[3] OpenID Foundation, Continuous Access Evaluation Profile (CAEP) 1.0, Shared Signals Framework, https://openid.net/specs/openid-caep-1_0-ID2.html

[4] SPIFFE.io, "SPIFFE Concepts" and "SPIRE Concepts" (CNCF-graduated workload identity specification and reference implementation), https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/

[5] IETF, RFC 8693, "OAuth 2.0 Token Exchange," https://datatracker.ietf.org/doc/html/rfc8693