AI agent governance now depends on action-level control

At a glance

What this is: This is an analysis of why AI agent governance must focus on actions, tool calls, and runtime policy enforcement rather than prompts alone.

Why it matters: It matters because agentic systems can access data, invoke tools, and take irreversible actions under identities that existing IAM, PAM, and security monitoring were not built to govern.

By the numbers:

• Gartner expects AI agents to outnumber human users 10 to 1 in large enterprises within a few years.

👉 Read Island's analysis of governing AI agent actions at runtime

Context

AI agent governance is the discipline of controlling what an agent can do at runtime, not just what it is instructed to do. That shift matters because the security problem is no longer limited to prompt leakage or chat-based data exposure; it now includes tool use, file access, network egress, and destructive system actions performed by software identities that behave independently within a session.

Island's article is built around that gap: the enterprise often sees prompts, logs, or single control points, but not the full action chain across endpoint, browser, network, and MCP surfaces. For identity teams, that puts agentic behaviour in the same governance conversation as NHI, PAM, and access policy, with different controls required when the actor is a software entity rather than a person.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents break traditional IAM assumptions?

A: AI agents break IAM assumptions because they do not behave like predictable users. They can authenticate to multiple systems, select tools dynamically, and execute tasks at machine speed without a human approval gate between actions. That removes the stable login session that traditional IAM uses as its trust anchor.

Q: What do security teams get wrong about agent visibility?

A: They often treat prompts or logs as sufficient proof of control. In reality, governance fails when teams cannot connect the instruction, the tool call, the data touched, and the final outcome into one sequence. Without that linkage, a destructive action can appear as a normal success event.

Q: Who is accountable when an AI agent makes a destructive tool call?

A: Accountability sits with the organisation that allowed the runtime, connector, and policy model to exist together without sufficient control. In practice, that means security, platform, and application owners all share responsibility for the guardrails that should have stopped the action at the tool boundary.

Technical breakdown

Action-level agent governance and runtime policy enforcement

Agent governance fails when teams only inspect prompts or summary telemetry. The relevant unit of control is the full interaction chain: prompt, model output, tool call, file access, sub-agent invocation, and response. A runtime policy engine can classify risky behaviour as it happens and decide whether to allow, prompt, or block. That is materially different from post-event logging because the action has not yet completed, which is why session context matters more than isolated events. In practice, this is closer to transaction monitoring than traditional alerting, but applied to software identities that can independently choose tools and sequence work.

Practical implication: build policy enforcement around the full session chain, not around prompt logs or endpoint events in isolation.

Why single control points miss agentic abuse

Agentic activity often crosses browser, endpoint, network, identity, and MCP surfaces in a single task. Each layer may see a valid individual action, such as a file being touched or data being sent out, without understanding that the steps belong to one coordinated sequence. That creates blind spots for correlation-based controls that were designed for human workflows or conventional automation. If the same agent can move from a chat instruction to a script execution and then to external data egress, the security model has to reconstruct intent from linked events, not from one telemetry source. The architecture problem is fragmentation, not just visibility volume.

Practical implication: correlate identity, device, and network telemetry around a shared agent session before treating any one event as low risk.

MCP, skills, and tool permissions create new access surfaces

Agentic systems expand the access problem because the decision boundary is no longer just who the user is, but which tools, MCP servers, skills, and sub-agents the software identity can invoke. That means entitlement design must account for scenario-specific access, device posture, and user context, not only static role assignment. Once an agent can select a tool and execute it on its own, tool permissions become part of identity control, not merely application configuration. The architectural lesson is that least privilege now has to be expressed across human initiation, software execution, and delegated tool reach.

Practical implication: treat tool and MCP permissions as identity entitlements and review them with the same rigor as privileged access.

Threat narrative

Attacker objective: The attacker aims to get a software agent to complete harmful work while every individual step appears authorised, successful, and operationally ordinary.

1. Entry occurs when a hidden instruction or malicious prompt causes the agent to request a tool or script it should not have used.
2. Escalation occurs when the agent follows that instruction into a higher-risk action, such as running a command, touching a sensitive file, or transferring data out of bounds.
3. Impact occurs when the sequence completes as a legitimate-looking success, even though the agent has exfiltrated data or triggered destructive change without effective human intervention.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Action governance is now the core identity problem for AI agents: The article captures a shift from prompt-centric thinking to runtime control of what an agent actually does. That shift matters because the security boundary is no longer the instruction, but the tool call, file touch, network action, and irreversible change that follows. Practitioners should treat agent action as an identity event, not an application event.

Least privilege for agents is not a static provisioning question: An agent can move from harmless to harmful within a single session, which means static access assumptions age out faster than traditional review cycles can observe them. The implication is that agent permissions must be evaluated in context, with scenario, device, and task scope all shaping the effective privilege envelope.

Prompt logging does not equal governance: The article is right to distinguish between seeing that a call happened and understanding why it happened. A logged success can still be a destructive incident if the underlying intent was malicious or the model was manipulated. Security teams should stop treating auditability as control completeness.

Identity blast radius is the right named concept for this problem: Once an agent can chain prompts, tools, and sub-agents, the question is not just whether access exists, but how far one successful instruction can propagate. That blast radius spans data exposure, command execution, and downstream delegation. Practitioners should govern the maximum harm a single agent session can create, not only whether the session is authenticated.

Autonomous behaviour collapses the assumption that access remains stable long enough to review: Access review cadences were designed for identities whose privileges persist between checkpoints. That assumption fails when an agent can acquire, use, and discard access inside one task flow. The implication is that governance models built around periodic certification cannot fully describe agentic risk.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• That pattern makes Top 10 NHI Issues a useful next step for teams mapping agentic access to broader non-human identity governance.

What this signals

Identity blast radius: as agentic systems spread across browsers, endpoints, and MCP-style tool surfaces, the controlling question becomes how far one session can propagate before anyone intervenes. With 72% of organisations already reporting or suspecting NHI breaches, the governance gap is not theoretical. Teams should expect session-level controls to become a baseline expectation for agentic access.

Runtime enforcement will increasingly sit alongside lifecycle governance, not replace it. The practical challenge is that access reviews and recertification cycles were built for identities that persist long enough to be evaluated, while agent sessions may complete before the next review window opens. That is why control-plane visibility and policy-based blocking now need to be designed as part of the identity programme, not as an overlay.

Practitioners should watch for agentic sprawl into areas already governed by NIST Cybersecurity Framework 2.0 and OWASP Top 10 for Agentic Applications 2026 controls. The early signal is not model sophistication, but the number of places where software identities can act without a human approval gate.

For practitioners

• Map every agent action to an identity control point Identify where prompts, tool calls, file access, browser actions, network egress, and sub-agent invocation are observable, then decide which control point is authoritative for each event. Use that mapping to avoid relying on any single telemetry source as the whole truth.
• Classify agent permissions as session-scoped entitlements Review which tools, MCP servers, and skills an agent can invoke in each scenario, and tie those permissions to user context, device posture, and task scope. The goal is to define what the agent can do during a session, not only what the account can reach at rest.
• Add runtime blocks for destructive and exfiltration actions Write policy conditions that stop database deletion, external file transfer, shell execution, and other irreversible actions before the session completes. Pair blocking with a reason code the agent can use to re-plan within permitted boundaries.
• Correlate agent sessions across endpoint, network, and browser telemetry Reconstruct one agent task across all surfaces so that a suspicious sequence cannot hide as a series of low-severity events. If the chain links a hidden instruction to a script and then to egress, the correlation layer should elevate the entire sequence.

Key takeaways

• AI agent risk is an identity governance problem because the harmful event is the action, not the prompt.
• Session-level control matters because agents can combine tool use, data access, and destructive behaviour faster than review cycles can react.
• Practitioners should govern agent permissions, telemetry correlation, and runtime blocking as one control model rather than separate security tasks.

Key terms

• Agentic Control-Plane Drift: The gradual expansion of an AI workflow from a narrow task into broader infrastructure authority. The risk is not simply that the agent acts quickly, but that the control plane starts absorbing tenant creation, secrets, integrations, and source control into one trust boundary.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

What's in the full article

Island's full post covers the operational detail this analysis intentionally leaves for the source:

• How AI Protect evaluates prompt, tool-call, and response content inline across a session
• How the control plane distinguishes allow, prompt, and block responses for risky agent actions
• How Agentic Endpoint Posture and Agentic Identity feed the AI Protect policy decision
• How Island ties agent behaviour to browser, endpoint, network, MCP gateway, and telemetry controls

👉 Island's full post covers the session chain, detection logic, and control-plane detail behind AI Protect

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 identity security programme, it is worth exploring.