AI agent governance moved from visibility to real-time control

At a glance

What this is: This year-in-review argues that enterprise AI agent risk is now defined by runtime behaviour, not prompts alone, and that governance must extend across visibility, correlation, and real-time enforcement.

Why it matters: It matters because IAM, PAM, and security teams need one control model for agents that blur identity, workload, API, and endpoint boundaries, or they will miss how access is actually used.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.

👉 Read Zenity's year-in-review on building AI security for the enterprise

Context

AI agent governance is no longer a future planning exercise. In practice, agents have already become operational identities that inherit permissions, invoke tools, and move data across SaaS, cloud, and endpoint environments, which means the control problem sits inside identity and access management as much as inside security operations.

Zenity's review shows why the old split between posture, logs, and manual review is breaking down. Security teams need to understand what an agent can do at runtime, not just what it was configured to do, because that is where the real exposure appears.

The article is best read as a field report on enterprise agent governance maturity. It describes a starting position that is increasingly common: organisations can see the agent surface in fragments, but they still lack a consistent model for governing behaviour across the full execution path.

Key questions

Q: How should security teams govern AI agents that inherit enterprise permissions?

A: Treat the agent as a non-human identity with runtime behaviour, not just as a model wrapper. Governance should cover the connected account, the tools it can invoke, the data it can move, and the actions it can complete during execution. If those pieces are reviewed separately, the real blast radius stays hidden.

Q: Why do AI agents complicate traditional IAM and PAM controls?

A: Because traditional IAM and PAM assume access is relatively stable and reviewed over time. AI agents can use inherited permissions, chain tools, and complete work much faster than periodic review cycles. That means the control problem shifts from who has access to how access is exercised in real time.

Q: What breaks when agent visibility is not paired with runtime enforcement?

A: Teams can see that an agent exists and still fail to stop unsafe behaviour. Without enforcement, visibility becomes a reporting layer instead of a control. The result is more context for investigators but little protection when an agent tries to move data, call a risky tool, or act outside policy.

Q: How can organisations reduce risk from AI agents without slowing delivery?

A: Use policy that is specific to the action, not to the whole environment. That means defining which destinations, tools, and data classes are allowed, then blocking unsafe actions at execution time. Done well, this preserves speed while making the agent's boundaries explicit enough for governance.

Technical breakdown

Agent surface mapping across SaaS, cloud, and endpoint

AI agents behave like distributed identities because they operate across managed SaaS apps, cloud runtimes, and local devices. In the article's model, the same agent may be triggered in one system, use authenticated sessions in another, and complete action steps somewhere else entirely. That makes isolated logging insufficient. A usable governance model has to correlate configuration, data access, and execution context across environments so the security team can reconstruct what the agent actually did, not just where a signal appeared.

Practical implication: build one inventory of agent identities, tool connections, and execution environments before you try to write policy.

Runtime autonomy and tool invocation

The key technical shift is that risk now emerges during execution. Agents do not just receive prompts, they make decisions about which tool to call, what data to touch, and how to proceed when conditions change. That is why tool invocation is a governance boundary, not a plumbing detail. Once an agent can act without a human pause between intent and execution, traditional approval workflows and event review models stop describing the real control surface.

Practical implication: place policy checks at execution time, not only at provisioning or configuration time.

Correlating posture, identity, and anomaly signals

The article's 'Issues' model reflects a wider technical need: security teams must connect entitlement structure, data flow, and runtime behaviour into a single incident story. Posture alone says an agent exists. Identity relationships show what it can reach. Runtime anomalies show whether that access was used safely. Without correlation, teams get noise instead of evidence, and response becomes a manual stitching exercise across tools.

Practical implication: design investigation workflows that merge entitlement, data, and runtime telemetry into one case view.

Threat narrative

Attacker objective: The objective is to make an agent execute legitimate-looking actions that move data or change state across enterprise systems faster than normal oversight can intervene.

1. Entry occurs when an enterprise agent is triggered by user action, email, data change, or an internal workflow and inherits the permissions attached to the connected application or session.
2. Escalation happens when the agent invokes approved tools, reuses authenticated sessions, or follows internal logic to reach sensitive data and downstream systems beyond the moment of initial trigger.
3. Impact follows when the agent sends data to an unapproved destination, performs an unsafe action at speed, or amplifies a mistaken instruction into a multi-system security event.

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

Agent governance is now an identity problem, not just an AI problem. Zenity's review shows that the operational risk comes from permissions, tool use, and data movement after an agent is connected to business systems. That places AI agents inside the same governance domain as service accounts, workload identities, and privileged automation. The implication is that IAM teams cannot treat agent security as a separate control tower; it belongs inside identity governance, entitlement review, and privileged access policy.

Visibility without execution control is no longer enough. The article is clear that teams first need a full picture of where agents live and how they behave, but visibility does not stop unsafe actions from happening. This is the same control gap that appears in many NHI programmes: discovery improves awareness, while enforcement determines whether behaviour is contained. Practitioners should read this as a sign that posture management alone cannot govern runtime identities.

Autonomy changes the unit of review from the identity to the action. Access review processes were designed for identities that hold permissions long enough to be inspected on a cycle. That assumption fails when an agent can trigger, combine, and complete actions within a single run. The implication is that governance must move from periodic certification to continuous behavioural control, because the review artefact may no longer exist by the time humans look for it.

Tool frameworks such as MCP create an identity blast radius that extends beyond the agent itself. When an agent can invoke databases, APIs, and internal systems through a shared tool layer, the effective access model becomes relational rather than isolated. That changes how privilege should be understood in both NHI and agentic AI programmes. Practitioners need to treat tool connectivity as part of the identity boundary, not as a separate integration concern.

Agent security is converging on continuous enforcement as the default operating model. Zenity's emphasis on inline prevention, issue correlation, and auditability reflects where the market is heading. The field is moving away from static allowlists and toward policy that can interrupt unsafe behaviour in real time. For security leaders, that means reevaluating whether current identity controls can govern systems that act faster than the review cycle.

From our research:

• 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, according to The State of Non-Human Identity Security.
• The 2024 ESG report found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% that confirmed one and 26% that suspected one.
• That confidence gap is why practitioners should pair visibility work with lifecycle governance, as explained in Ultimate Guide to NHIs - Key Challenges and Risks.

What this signals

Autonomous behaviour raises the bar from access knowledge to action control. When agents can make and carry out decisions during execution, periodic access certification stops being the primary control and becomes only a retrospective record. Security teams should expect governance to move toward event-level policy enforcement, because the review cycle is now slower than the actor.

Identity blast radius is the practical measure that matters. In agent environments, the key question is not whether an account exists but how far its connected tools, sessions, and data paths can reach once the agent starts acting. That is the programme-level signal to watch as AI adoption spreads across SaaS and cloud estates.

For teams already working from the NHI baseline, the next step is operational discipline. Tie the agent inventory to OWASP Agentic Applications Top 10 and use it to prioritise policy points where tool misuse or data exfiltration could cross business boundaries. The organisations that can enforce boundaries at runtime will absorb AI faster than those still treating agent access as a static entitlement problem.

For practitioners

• Inventory every agent identity and tool path Map where agents operate across SaaS, cloud, and endpoint environments, then record which authenticated sessions, APIs, and tools each one can reach. Use that inventory as the baseline for policy and for recertification of connected access.
• Move control points to execution time Require policy checks when the agent attempts an action, especially where data could be sent to an unapproved domain or a tool could change state in a critical system. Do not rely on configuration review alone.
• Correlate posture with runtime evidence Join entitlement data, data-flow context, and runtime anomalies into one investigation workflow so analysts can see how an issue unfolded. This avoids splitting ownership across IAM, SecOps, and platform teams.
• Treat tool frameworks as privileged connections Review MCP server and tool relationships the same way you would review high-risk service-account connections. Remove unnecessary tools, tighten destinations, and log every invocation that can reach internal systems.
• Align review cadence to behavioural speed If an agent can complete meaningful work within a single session, periodic access review will miss the event. Replace assumptions about stable access with continuous behavioural monitoring and intervention paths that can act before completion.

Key takeaways

• AI agent governance fails when teams treat runtime behaviour as a secondary concern rather than the main security event.
• The evidence in this review points to a control gap between visibility and enforcement, which is where most agent risk now concentrates.
• Security teams should manage agents as non-human identities with action-level policy, not as ordinary application extensions.

Key terms

• Agent Surface: The full set of places where an AI agent can be configured, triggered, and allowed to act. In practice this includes SaaS platforms, cloud runtimes, and endpoints. The term matters because governance fails when teams only see one part of the path and miss how the agent behaves across the rest.
• Runtime Enforcement: Policy enforcement that happens while an agent is acting, not after the fact. It is the control model that can stop unsafe tool use, risky data movement, or unapproved destinations at the moment they are attempted. For agents, this is often more important than post-event review.
• Identity Blast Radius: The maximum scope of systems, sessions, tools, and data that a non-human identity can reach if it acts as designed or is misused. It is a practical way to measure how far access can spread once an agent starts operating, and it helps teams prioritise where containment matters most.
• Tool Layer: The layer of APIs, connectors, and protocols an agent uses to interact with other systems. It is not a neutral plumbing detail, because every connected tool expands the effective access boundary of the identity. Security teams should govern it as privileged access, not merely as integration logic.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Zenity: Zenity 2025 Year in Review, Building AI Security for the Enterprise. Read the original.