RSA 2026 exposed the gap between AI agents and IAM controls

At a glance

What this is: RSA 2026 revealed that practitioners are no longer shopping for AI agent ideas, but for controls that can govern runtime behaviour, identity, and ownership across already-deployed systems.

Why it matters: This matters because IAM, NHI, and PAM programmes must now account for agents that act mid-session, inherit tools, and outgrow build-time permissions before governance teams can review them.

By the numbers:

• Over 600 vendors filled the RSA 2026 expo floor, and roughly 37% used AI in their primary messaging.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Zenity's RSA 2026 analysis of AI agent security market signals

Context

RSA 2026 was not just another AI-heavy conference. It exposed a wider identity governance problem: enterprises are deploying AI agents that can act, call tools, and change context while their control models still assume static, user-shaped access patterns. That mismatch is now visible in daily practitioner conversations.

The primary issue is not whether AI agents exist, but whether governance can keep pace with runtime behaviour, ownership ambiguity, and expanding tool use. For identity teams, this shifts the discussion from build-time configuration to lifecycle control, runtime enforcement, and accountability across NHI and agentic AI programmes.

Key questions

Q: How should security teams govern AI agents that act at runtime?

A: Security teams should govern AI agents as non-human identities with dynamic runtime behaviour, not as static accounts. That means ownership, policy enforcement, and lifecycle controls must follow the agent through session changes, tool calls, and delegated access. If a control only works at provisioning time, it is not enough for agentic environments.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: AI agents complicate IAM and NHI controls because they can change effective scope during a session, inherit permissions through tools, and act in ways that were not known at provisioning time. Traditional reviews assume access is stable long enough to be certified. With agents, the control window often arrives after the meaningful decision has already happened.

Q: What breaks when teams rely on visibility without enforcement for AI agents?

A: Visibility without enforcement breaks the governance model because it creates knowledge without control. Teams may know an agent exists, which systems it touched, or which policy it violated, but still be unable to stop the next action or narrow the agent’s permissions in time. That leaves the organisation with better evidence and the same exposure.

Q: How can organisations tell whether their agent governance is working?

A: Organisations can tell agent governance is working when policy changes the agent’s available actions in session, not just when it produces alerts or reports. A useful test is whether the control can reduce scope after a risky tool call, inherited permission, or unexpected context shift. If behaviour does not change, governance is only observational.

Technical breakdown

Why static identity models fail for AI agents

Static identity models were built for people and predictable machine accounts. An AI agent can start a session with one purpose, pick up new instructions, call tools dynamically, and end the session with a different effective scope than the one granted at the start. That makes provisioning-only thinking insufficient. The core architecture problem is that identity, intent, and action are no longer aligned at a single point in time, so log review and entitlement review lag behind the behaviour they are meant to govern.

Practical implication: move from point-in-time entitlement thinking to runtime visibility that can track what the agent is doing after access is granted.

Action-level enforcement versus input-level filtering

A prompt filter or gateway can inspect inputs, but it cannot always understand whether a chain of allowed actions adds up to an unsafe outcome. Action-level enforcement sits closer to the thing that matters: what the agent actually does in session, across tools and contexts. That distinction is why many governance products look strong in demos but weak in production. The technical gap is not visibility alone, but whether policy can follow the agent across changing context and execution decisions.

Practical implication: evaluate controls by their ability to constrain actions mid-session, not by their ability to block obvious inputs.

Agent identity must include inherited and implicit access

Agent identity is not limited to a single credential. In real deployments, it can include static secrets, delegated tool access, identities inherited through integrations, and implicit trust created by agent-to-agent communication. Each layer can expand the blast radius if it is not governed as part of one identity chain. This is why runtime context matters so much: the agent is often operating through multiple permission sources at once, and the risk accumulates across that chain rather than staying inside one account.

Practical implication: inventory every identity source an agent can touch, including inherited tool permissions and delegated access paths.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent governance is now an identity problem, not just a security tooling problem. The conference signal was not more interest in AI, but more urgency around who owns agent behaviour once it is deployed. That shifts the category from point products to governance architecture, because the same session can involve identity, data, tools, and policy decisions at runtime. The practitioner conclusion is straightforward: agent security now sits inside IAM, NHI, and PAM operating models, not beside them.

Runtime context is becoming the real control plane for agentic AI. Build-time hardening still matters, but it does not finish the job when the environment, inputs, and toolset keep changing after deployment. The result is a control gap between what was approved and what the agent actually does. The practitioner conclusion is that teams must judge controls by their behaviour under session drift, not by their comfort at deployment time.

Identity governance for agents is collapsing into lifecycle governance for non-human identities. Agents are not static resources that can be provisioned once and forgotten. They accumulate permissions, inherit access paths, and require ownership that survives change, escalation, and retirement. The practitioner conclusion is that joiner-mover-leaver logic, access review, and offboarding now need an agent-specific runtime interpretation.

Agent security will expose which organisations still confuse visibility with control. Many products can show that an agent exists, what it touched, or which policy was violated. Fewer can actually constrain the next action or revoke the dangerous path before impact. The practitioner conclusion is that governance maturity will increasingly be measured by whether policy changes behaviour, not whether dashboards generate alerts.

Runtime identity drift: agents can begin a session under one entitlement set and end it under another effective scope after tool calls, delegated instructions, or changed context. That is not a visibility issue alone, it is a governance boundary problem, and the practitioner conclusion is that static review cycles no longer describe the actor accurately.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure.
• The gap is widening fast, so read OWASP NHI Top 10 for the control patterns teams are using to close agentic runtime risk.

What this signals

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, governance programmes need to move from pilot-era visibility to operational control. The issue is no longer whether agents will appear in production. It is whether IAM, PAM, and change-management processes can keep pace with systems that will act before a human review cycle completes.

Context drift: agent behaviour changes after deployment as inputs, tools, and permissions change, so the control problem is not just entitlement scope but session trajectory. Teams that still rely on deployment-time approval models should reassess whether their enforcement layer can react after a tool call rather than only before access is granted.

The strongest signal from RSA is that agent security is converging with NHI governance. That means practitioners should expect broader use of lifecycle controls, runtime policy, and ownership tracking across AI systems, service accounts, and human-administered integrations rather than treating agent security as a separate island.

For practitioners

• Map agent runtime ownership Assign one accountable owner for each deployed agent, including the security, infrastructure, and product teams that influence its permissions and tool use. Require a named decision owner for changes that alter scope, integrations, or autonomous actions.
• Evaluate controls at the action layer Test whether a control can stop an unsafe action after an agent has already received legitimate access and accumulated context. Use scenarios that involve tool chaining, inherited permissions, and session drift rather than simple blocked prompts.
• Review non-human access as a lifecycle, not a deployment event Extend recertification and offboarding logic to agents whose access changes over time. Include inherited privileges, delegated tool access, and any identity that can persist beyond the original use case.
• Separate visibility from enforcement in vendor evaluation Ask vendors to demonstrate how policy changes agent behaviour in a live session, not just how it reports activity. A product that can observe agent actions but cannot constrain them should be treated as a monitoring layer, not a governance control.

Key takeaways

• RSA 2026 showed that AI agent security has become an operating-model problem, because static identity assumptions do not hold once agents make runtime decisions.
• The evidence is already in the market and the field, with most organisations still lacking agent policies even as many expect autonomous infrastructure execution within three years.
• Teams should focus on runtime enforcement, accountable ownership, and lifecycle governance because visibility alone does not constrain agent behaviour.

Key terms

• Agent Identity: Agent identity is the set of credentials, permissions, and trust relationships used by an AI system when it acts on its own behalf. It differs from a human login because the identity can be inherited through tools, contexts, and delegated access during a session.
• Runtime Enforcement: Runtime enforcement is the ability to change or restrict what an identity can do while it is actively operating. For AI agents, this matters because risk often appears after deployment, when context shifts and the initial approval no longer matches the agent’s behaviour.
• Context Drift: Context drift is the gap between what an identity was authorised to do at the start of a session and what it ends up doing after inputs, tools, or instructions change. In agentic systems, it is a core governance problem because behaviour can move outside the original approval boundary.
• Non-Human Identity Lifecycle: Non-human identity lifecycle is the end-to-end management of machine credentials, from creation through review, rotation, change, and retirement. For agents, the lifecycle must account for runtime behaviour as well as entitlement changes, because access can evolve during a single operational session.

Deepen your knowledge

AI agent governance and runtime enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is still treating agents like static service accounts, this course is a practical next step.

This post draws on content published by Zenity: The Floor Was Selling AI. The Hallways Were Asking for Help. Read the original.