Agentic AI governance is lagging as RSA conversations mature

At a glance

What this is: RSA 2026 surfaced a clear shift from basic AI agent awareness to technical questions about securing and governing agentic AI in production.

Why it matters: That shift matters because IAM, NHI, and AI governance programmes now have to handle runtime behaviour, not just static access models or policy definitions.

👉 Read Zenity’s RSA 2026 blog on agentic AI security and governance

Context

Agentic AI is moving from concept to operational reality, which changes the identity problem from understanding the technology to governing how it acts at runtime. The article's central claim is that conference conversations have matured faster than the standards meant to cover them, leaving a governance gap between adoption and control.

For IAM, PAM, and NHI teams, that gap is not abstract. Once agents begin operating in production, identity controls must account for delegated action, runtime context, and lifecycle oversight across both machine and human governance models. Zenity's RSA observations reflect a wider industry shift from education to implementation.

Key questions

Q: How should security teams govern AI agents that are already in production?

A: Security teams should treat production agents as governed identities with explicit ownership, scoped permissions, monitoring, and lifecycle review. The key is to tie each agent to a human accountable party, then verify what tools, data, and actions it can reach during live execution. Without that, policy exists on paper while operational risk keeps growing.

Q: Why do AI agents change the way IAM and governance teams think about access?

A: AI agents change access governance because the relevant privilege is not just the account they hold, but the task, context, and tool chain active during execution. That means static provisioning is not enough. Teams need to understand runtime behaviour, not only entitlement state, because an agent can act differently across sessions and use cases.

Q: What do security teams get wrong about AI governance?

A: A common mistake is treating AI governance as a model-policy exercise instead of an operational control problem. That approach leaves deployment, monitoring, review, and offboarding underdefined. The result is a gap between what policy says should happen and what the agent can actually do in production.

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

A: A useful signal is whether every agent has a clear owner, a defined use case, a live access boundary, and a documented retirement path. If any of those are missing, governance is incomplete. The strongest programmes can show that permissions, monitoring, and review all change when the agent changes role.

Technical breakdown

Why agentic AI governance trails production deployment

Agentic AI governance lags when policy, standards, and review processes are built for understanding models rather than controlling actors that execute tasks. An AI agent can decide what to do at runtime, select tools, and act without waiting for a human to approve each step. That makes traditional pre-authorised control assumptions too slow and too static for production use. The technical issue is not just model exposure, but the identity and authorisation boundary around autonomous behaviour. Security teams need to separate model risk from actor governance so they can measure what the agent is allowed to do, when it can do it, and under what context.

Practical implication: treat agents as governed identities with runtime limits, not as a model-security side project.

Runtime context is now part of identity security

Runtime context means the agent's current task, available tools, data scope, and decision point all shape its effective privilege. In agentic systems, identity alone is not enough because the same agent may behave differently depending on the conversation, tool chain, or orchestration path. This is why agent security discussions increasingly move beyond static credentials toward continuous context evaluation. The architecture challenge is to govern what the agent can reach in the moment, not just what account it holds on paper. That shifts the centre of gravity from provisioning to session-level control and observability.

Practical implication: map agent privileges to live task context and enforce boundaries at execution time.

AI governance needs lifecycle controls, not just model policies

AI governance fails when it stops at policy statements and does not cover the full lifecycle of agent creation, approval, deployment, review, and retirement. The article reflects a common industry pattern: governance teams focus on model assurance, while operational teams are already deploying agents into business workflows. That creates a mismatch between policy cadence and deployment cadence. Lifecycle control matters because the risk is not only what the agent can do today, but whether it stays in service, stays constrained, and stays visible as its use expands. Governance has to follow the actor through time, not just classify it at intake.

Practical implication: extend governance to approval, review, and offboarding for every deployed agent.

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

Agentic AI governance is arriving after deployment, not before it. The article describes a market where practitioners are already asking how to secure agents in production, while governance frameworks are still catching up. That pattern means security programmes are being asked to retro-fit oversight onto working systems instead of shaping adoption from the start. The implication is that agentic AI is now an operational identity problem, not a future policy exercise.

Runtime context is the named concept that now defines effective AI agent control. Identity alone no longer explains what an agent can do, because the task, data, and tool context change the real access boundary. This is not just a missing control, it is a governance shift from static account thinking to live execution thinking. Practitioners should recognise runtime context as the decisive unit of control for agentic systems.

AI governance that stays inside model-security silos will miss the actual risk surface. The article shows practitioners already probing how agent security works, not whether agents exist. That means the governance conversation has moved from conceptual acceptance to operational accountability. NIST AI Risk Management Framework thinking becomes relevant here because the risk is distributed across design, deployment, and ongoing use.

The industry is normalising agentic AI faster than its control models can absorb. The RSA conversations described here show demand moving ahead of mature safeguards. That creates pressure on IAM, PAM, and NHI teams to decide which parts of existing governance can extend to agents and which parts need redefinition. The practical conclusion is that identity programmes must stop treating agents as edge cases.

Community momentum is now a governance signal. The repeated questions about how agentic security works indicate that the field has crossed from novelty into implementation pressure. For security leaders, that means buying time with broad strategic statements is no longer enough. The programme question is how fast controls can be made specific enough to govern real agent behaviour.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why teams should also review OWASP NHI Top 10 when mapping agentic access risk and control coverage.

What this signals

Runtime context is now the control plane for agentic AI. Teams that continue to govern agents only through static permissions will miss the real boundary, which changes with task, tool, and session context. The practical test is whether your programme can explain, in one review cycle, what the agent was allowed to do at the moment it acted.

The governance debt described in the article will show up first as confusion over ownership, then as inconsistent review evidence, then as offboarding gaps when agents are retired or replaced. Security leaders should expect the same lifecycle pressure they already see in NHI management, but with faster change rates and more brittle context dependencies.

Agentic AI now belongs in the same conversation as the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework because the risk is not only misuse of a model, but misuse of delegated action. Runtime context drift is the failure mode to watch, because it turns a policy decision into an execution-time exposure.

For practitioners

• Define agents as governed identities Assign ownership, approval, and review paths to every deployed agent so the security team knows who is accountable for its actions across its lifecycle.
• Measure runtime context, not just access grants Track which tools, datasets, and execution contexts each agent can reach during a live session, then compare that to the intended policy boundary.
• Extend lifecycle governance to agent retirement Require offboarding steps for agents just as you would for privileged human users or service accounts, including revocation of access, tokens, and integrations.
• Align AI governance with operational deployment Move governance review earlier in the rollout process so policy, security testing, and monitoring are in place before agents are embedded in production workflows.

Key takeaways

• Agentic AI has moved into production faster than governance frameworks have adapted, creating a control gap across identity, review, and accountability.
• The operational risk is no longer theoretical, because runtime context now determines what an agent can actually do.
• Security teams need lifecycle-based governance for agents, including ownership, monitoring, and offboarding, before deployment becomes normalised.

Key terms

• Agentic AI governance: The set of identity, access, monitoring, and lifecycle controls used to oversee AI systems that can choose actions at runtime. It goes beyond model safety to cover who owns the agent, what it can do, when it can do it, and how it is retired or constrained.
• Runtime context: The live task, tool, data, and session conditions that shape what an AI agent can actually do at a given moment. In practice, runtime context is the difference between a policy that looks safe on paper and an execution path that creates real exposure.
• Agent lifecycle governance: The processes used to approve, deploy, review, and offboard AI agents throughout their operational life. For autonomous or semi-autonomous systems, lifecycle governance must track role changes, permission drift, monitoring evidence, and removal of access when the agent is no longer needed.

Deepen your knowledge

Agentic AI governance and runtime context are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for deployed agents and need to align identity, oversight, and lifecycle thinking, it is worth exploring.

This post draws on content published by Zenity: My First RSA: Agents, Challenges, and Community. Read the original.