AI agent governance moved from visibility to real-time control

At a glance

What this is: Zenity’s year-in-review argues that AI agent governance has moved from seeing agent activity to blocking unsafe actions as they happen.

Why it matters: For IAM, IGA, PAM and security teams, that shift means agent governance can no longer stop at inventory and review cycles, because runtime decisions now drive access, data movement and downstream system impact.

Context

AI agent governance now sits in the gap between identity, workload, API and endpoint control. In Zenity’s account, the problem is not prompts alone but what agents do after they are triggered, when permissions, tools and data flows combine at runtime.

That makes the central governance question different from conventional IAM: the programme must understand where agents execute, what they can invoke, and when policy needs to intervene before an action reaches a critical system. Visibility helps, but it is no longer the end state.

Key questions

Q: What breaks when AI governance does not include interaction-level visibility?

A: Teams lose the ability to prove which account was used, what was prompted, and what action followed. Without that context, policy enforcement becomes retrospective guesswork instead of runtime control. The result is a blind spot that hides personal-account use, prompt injection, and unsanctioned data movement.

Q: What happens when AI agents are connected to enterprise systems without strong non-human identity governance?

A: When AI agents connect to enterprise systems without strong governance, they can inherit excessive access, move through sensitive data paths, and amplify mistakes at machine speed. That turns a local configuration issue into a broad security and compliance problem. The practical result is greater exposure, weaker auditability, and a larger blast radius if an agent or its credentials are compromised.

Q: How can security teams know if agent skill controls are actually working?

A: Look for evidence that skills are inventoried, risk rated, scanned before execution, and tied to a policy manifest or approval record. If teams cannot show which skills are live, who owns them, and what actions they can trigger, the programme is still operating on trust rather than control.

Q: What is the difference between runtime policy enforcement and post-event detection for AI agents?

A: Runtime enforcement stops or constrains the agent before the action lands in a downstream system. Post-event detection only explains what happened after the risk has already materialised, which is useful for investigation but too late for containment in fast-moving agent workflows.

Technical breakdown

Runtime agent behaviour and inherited permissions

AI agents inherit access from the platforms and sessions they operate within, then use that access dynamically as they execute. The risk surface is created by the combination of inherited permissions, tool invocation and data movement, not by the prompt itself. Once an agent is connected to SaaS, cloud or endpoint systems, traditional identity logs can show that access existed, but they often fail to show the decision path that led to an action. That is why runtime context matters: the security problem is not just who authenticated, but what the agent was authorised to do at the moment it acted.

Practical implication: Map agent permissions to the downstream systems they can touch, then treat runtime behaviour as a first-class control point.

Tool invocation and MCP governance

Agents become materially riskier when tool frameworks such as MCP connect them to databases, APIs and internal services. Tool access is the plumbing layer that turns an agent from a conversational interface into an operational actor. If the tool layer is broad, poorly inventoried or loosely governed, the agent can reach sensitive systems faster than human review cycles can intervene. This is why agent security is not just about model safety or prompt filtering. It is about controlling which tools are available, how they are configured, and whether execution-time policy can stop an unsafe call before it propagates into the environment.

Practical implication: Inventory every agent-to-tool connection and restrict tool use at execution time, not just at provisioning time.

Inline prevention versus post-event detection

Visibility and alerting explain what happened, but they do not stop an unsafe action from completing. Zenity’s shift from broad visibility into active defense reflects a broader reality for agent governance: once agents can send data, call tools or move between systems at machine speed, post-event review is too late for containment. Inline prevention is the control pattern that matters when the harm is immediate, because it enforces organisational policy at the moment of attempted action. That changes the architecture of governance from observing behaviour to constraining it in-line.

Practical implication: Use execution-time policy controls for high-risk agent actions instead of relying on detection and manual cleanup.

Threat narrative

Attacker objective: The objective is to turn legitimate agent execution into unauthorised data movement, unsafe tool use, or downstream system action that bypasses normal oversight.

1. Entry occurs when an agent is triggered through email, user action, or a system event and receives inherited access to connected resources.
2. Escalation happens when the agent invokes tools, reuses authenticated sessions, or reaches internal APIs with broader reach than the triggering user expected.
3. Impact follows when the agent moves data or performs actions across SaaS, cloud or endpoint systems faster than human review can intervene.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime control is now the governance boundary for AI agents. Visibility into where agents exist is necessary, but it no longer answers the core security question: whether an action should be allowed to complete. Once agents can invoke tools, move data and act on events without a human in the loop, governance has to shift to execution-time enforcement. The practitioner conclusion is straightforward: if policy cannot intervene at runtime, it is not yet governing the agent.

Tool access is the real attack surface, not the prompt layer. Zenity’s article reflects a pattern NHIMG sees repeatedly: real incidents emerge when agent toolchains can reach internal systems, not when a model merely generates unsafe text. That means the security conversation has to move from conversation safety to delegated capability control. Practitioners should treat every connected tool as an extension of agent privilege.

Autonomy and intent create assumption collapse for traditional IAM. Least privilege was designed for access that can be bounded and reviewed around a stable actor and a stable task. That assumption fails when an agent decides and executes within the same session because the access path, the decision point and the action can collapse into one runtime event. The implication is that governance must be rethought around issuance, tool scope and execution boundaries, not just certification.

Agent governance is becoming a cross-domain identity problem. These systems blur identity, workload, API and endpoint boundaries, which is why isolated control points keep missing the full picture. A team that governs only human IAM, only workloads, or only endpoint activity will still miss the agent’s actual operating context. The practitioner conclusion is to govern the agent as a connected identity surface, not a single product category.

Inline enforcement will define the next phase of agent security. The article’s shift from visibility to active defense matches where the market is heading: security programmes will increasingly be judged on whether they can block an unsafe agent action before it reaches downstream systems. For practitioners, the question is no longer whether agents can be observed, but whether their high-risk actions can be constrained without slowing the business.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

AI agent governance is converging on execution-time control. Programmes that still rely on inventory, review and alerting will keep missing the moment that matters, because the agent’s risk is expressed when it acts, not when it is catalogued. Security leaders should expect policy enforcement to move closer to the tool call and away from the quarterly review cycle.

Agent behaviour is now a delegated identity problem. Once an agent can reuse sessions, invoke tools and interact with internal APIs, the governance issue is no longer model output quality alone. The hard question is whether the organisation can bound delegated capability tightly enough to stop one runtime decision from becoming a multi-system event.

For practitioners

• Establish agent runtime guardrails Define which agent actions are allowed at execution time, including data egress, tool use and cross-system operations. Put policy at the moment of action, not only at onboarding or review.
• Inventory every agent-to-tool path Map which agents can reach which tools, APIs, internal services and endpoint sessions, then remove unnecessary connections that expand agent privilege beyond the task.
• Separate visibility from enforcement Use monitoring to explain agent behaviour, but rely on inline controls to stop risky actions before they affect downstream systems.
• Rework access reviews for runtime actors Treat agents as actors whose privilege is consumed during execution, so recertification and approval models account for ephemeral decisions instead of static account ownership.
• Define escalation criteria for autonomous workflows Set clear thresholds for when an agent’s tool use, data access or event-triggered behaviour requires stricter policy or containment before the action chain continues.

Key takeaways

• AI agents create a governance problem that traditional identity models do not fully cover because permissions, tools and data movement converge at runtime.
• The article’s central shift is from visibility into where agents exist to control over what agents are allowed to do in the moment of execution.
• Practitioners need controls that constrain agent tool use and data movement before the action reaches downstream systems.

Key terms

• Runtime agent: A runtime agent is a control that observes application behaviour while software is executing. It can surface live data flow and exploit context that static tools may not see, but it must be paired with pre-deployment controls to cover secrets, code, and delivery pipeline exposure.
• Inline prevention: Inline prevention is a blocking control that intervenes before an unsafe action completes. For AI agents, it matters because the goal is not just to detect misuse later, but to stop secret exposure, unauthorised tool use, or data leakage while the session is still active.
• Agent-to-tool path: The agent-to-tool path is the full chain an AI agent follows from decision to tool invocation to resulting action. For governance teams, it is the unit that must be authorised, logged, and reviewed because the risk sits in the live path, not just the endpoint inventory.
• Delegated Capability: The specific set of actions a non-human or AI identity is allowed to perform on behalf of a user or system. It matters because governance must cover not only who owns the identity, but also what it can initiate, alter, or trigger inside connected platforms.

Deepen your knowledge

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