AI agent governance needs an execution plane, not just inventory

At a glance

What this is: This is an analysis of why AI agent discovery and lifecycle tools are necessary but insufficient, and why runtime execution controls are the missing layer.

Why it matters: It matters because IAM, NHI, and security teams need governance that can both track agent identity and stop unsafe actions at the moment they occur.

👉 Read 1Kosmos's analysis of control plane and execution plane governance for AI agents

Context

AI agent governance needs to distinguish between knowing an agent exists and knowing whether it should be allowed to act right now. Control plane tools solve the first problem by registering agents, assigning owners, and tracking lifecycle events, but they do not answer the execution question that matters when an agent can call tools, access data, or provision infrastructure at runtime.

That gap sits squarely in identity governance. Human-centric IAM and traditional machine identity patterns assume the action path is relatively stable and reviewable, while autonomous agents can change behaviour between registration and execution. For teams building AI agent programmes, the issue is no longer only visibility. It is whether governance can intervene before a tool call becomes a consequential action.

Key questions

Q: How should security teams govern AI agents that can call tools autonomously?

A: Security teams should govern autonomous agents at two layers. The control plane should register the agent, assign ownership, and manage lifecycle events. The execution plane should enforce policy at runtime so a tool call is checked before it executes. If an organisation cannot stop an action before the tool is reached, it has visibility but not real control.

Q: Why do control plane tools fail to prevent risky AI agent behaviour?

A: Control plane tools fail because they operate at identity registration, not at the moment of action. They can show which agents exist and who owns them, but they cannot decide whether a specific tool call is safe under current conditions. For autonomous agents, that distinction matters because the risk appears when the action happens, not when the agent is created.

Q: What breaks when AI agents rely on static API keys?

A: Static API keys create a long-lived trust window that outlives the decision that issued the key. For autonomous agents, that means a valid credential can still authorise a dangerous action even if the context has changed. The result is excessive standing trust, weak accountability, and poor containment when the agent acts beyond its intended scope.

Q: Who should be accountable when an AI agent takes a harmful action?

A: Accountability should rest with the human authoriser linked to the specific execution event, not just the person who created the agent months earlier. Runtime approval records need to show who allowed the action, under what scope, and with what validity window. That is the only reliable way to connect ownership to consequence.

Technical breakdown

Why control plane discovery does not stop runtime agent actions

Control plane systems work at registration time. They record which agent exists, who created it, and when it was onboarded or decommissioned. That is useful for inventory and accountability, but it does not evaluate a specific action at the moment the agent decides to take it. In practice, this means the system can tell you an agent is owned without being able to tell you whether a database delete, API call, or infrastructure change is authorised now. The limitation is structural, not operational. Identity is known, but action intent is not assessed at execution time.

Practical implication: Use control plane tooling for inventory and ownership, but do not treat it as runtime authorisation.

How the execution plane changes MCP governance

The execution plane sits where the agent actually calls a tool, typically through Model Context Protocol. MCP standardises tool access, but by itself it does not decide whether a particular action should proceed. An execution plane inserts policy checks between the agent and the tool, validating identity, scope, context, and approval requirements before the request reaches the target system. That is why this layer matters for AI agents in ways it does not for simple scripts. The decisive question is no longer who owns the agent, but whether the action is safe under current conditions.

Practical implication: Intercept MCP calls with policy enforcement before a tool can execute a high-risk request.

Why verifiable credentials matter more than static API keys

Static API keys assume trust persists until manual revocation. That model is weak for autonomous agents because the credential outlives the decision that created it. Verifiable credentials are different: they bind the credential to a specific agent, a defined issuer, a limited validity window, and a permitted scope. That lets security teams narrow the window in which an agent can act and tie every consequential request back to a real authoriser. The mechanism is not just stronger authentication. It is time-bound, context-bound authorisation at the point of consequence.

Practical implication: Replace persistent secrets with short-lived, scoped credentials that can be verified at execution time.

Threat narrative

Attacker objective: The objective is to get an AI agent to carry out a consequential action beyond its intended scope before governance can intervene.

1. Entry occurs when an agent receives valid credentials or a tool path that lets it reach MCP-backed resources without meaningful runtime policy checks.
2. Escalation happens when the agent selects a higher-risk tool or action than the original task implied, such as accessing sensitive data or provisioning infrastructure.
3. Impact follows when the action executes successfully before any human review, creating data loss, overreach, or production disruption.

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

Control plane governance solves identity sprawl, not action authority. The first layer can tell you which AI agents exist, who owns them, and when they were created. That is valuable, but it is not the same as determining whether a specific action is authorised under current business conditions. The field should stop treating lifecycle visibility as a substitute for runtime control. Practitioners need both identity registration and enforcement at the point of execution.

Autonomous agent governance exposes a broken assumption: access is reviewable because it persists long enough to be reviewed. That assumption was designed for human-paced IAM and deterministic machine identities. It fails when the actor can independently choose tools, timing, and action sequence inside a live session. The implication is not simply that existing controls are incomplete, but that the review model itself collapses when the decision window shrinks to machine speed.

Execution-plane control is now the relevant NHI boundary for agentic systems. In agent programmes, the meaningful security question is no longer only whether an identity exists in a directory. It is whether the agent can be stopped before it reaches the tool that would make the decision real. This is where OWASP Agentic AI guidance and zero trust principles start to intersect with identity governance. Security teams should treat runtime interception as a core governance requirement, not an advanced feature.

Know Your Agent: The emerging governance pattern is point-of-action verification, where every consequential agent action must be tied to a verified authoriser at execution time. That matters because the older pattern, point-of-registration trust, is designed for stable identities with predictable behaviour. Once an agent can reason, choose, and act dynamically, the governance premise shifts from ownership to consequence. Practitioners need to evaluate whether their controls bind identity to action at the moment it matters.

Control plane plus execution plane is the right division of labour for AI agent identity. One layer should manage discovery, inventory, and lifecycle. The other should enforce scope, approval, and policy before a tool call executes. Organisations that collapse those responsibilities into a single control plane will keep finding blind spots when agents move from dormant inventory to active decision-makers. The practical conclusion is simple: track agents, but govern their actions separately.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader governance baseline, read OWASP Agentic AI Top 10 for the control failures that runtime policy needs to address.

What this signals

With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented policies, the market is signalling a familiar pattern: adoption is outrunning governance. For practitioners, the practical signal is that inventory alone will not close the gap. Execution-time controls and policy enforcement need to enter the programme now, alongside lifecycle discovery.

Runtime authorisation gap: this is the point where agent identity exists, ownership exists, but consequence control does not. As agent use spreads across code, data, and infrastructure workflows, teams should expect pressure to integrate runtime policy into zero trust architecture rather than treat it as a separate AI security problem. The decisive shift is from knowing the agent to constraining the action.

Programmes that already map machine identities and secrets should use that foundation to extend governance into agentic behaviour. The next control maturity step is not more inventory dashboards. It is the ability to block or scope tool access at the exact moment an agent crosses from intent into execution.

For practitioners

• Separate inventory from enforcement Use control plane tools to register agents, assign owners, and manage lifecycle events, but do not assume those functions can prevent unsafe tool calls at runtime. Map every agent to the systems it can reach, then identify where a policy engine must sit between the agent and the tool.
• Add execution-time policy checks to MCP paths Place policy enforcement at the Model Context Protocol layer so every tool request is evaluated before it reaches the target service. Require the check to confirm identity, scope, and context rather than trusting the presence of a valid credential.
• Replace static credentials with scoped verifiable credentials Bind agent credentials to a specific issuer, a single agent, a short validity window, and a narrowly defined action set. This limits how long an agent can act and makes the approval record auditable when the action is consequential.
• Define approval thresholds for consequential actions Set explicit rules for when an agent can act automatically and when it must pause for human authorisation, especially for infrastructure changes, sensitive data access, and payment-related workflows. Keep the approval decision linked to the action, not to the agent's general ownership.
• Test whether your programme can stop an agent before execution completes Run scenarios where an agent attempts an out-of-scope action and verify that the request is blocked before it reaches the target tool. If you can only decommission the agent after the fact, you have visibility but not runtime control.

Key takeaways

• AI agent governance breaks down when teams confuse lifecycle visibility with runtime control.
• The evidence points to a widening gap: agent adoption is accelerating while a majority of organisations still cannot fully govern or audit agent behaviour.
• The control that changes the outcome is execution-time policy enforcement tied to scoped, verifiable credentials and human approval for high-risk actions.

Key terms

• Execution Plane: The execution plane is the runtime layer where an AI agent's tool call is validated before the action reaches the target system. It is designed to decide whether a specific action should proceed right now, based on identity, scope, and current context.
• Control Plane: The control plane is the identity and lifecycle layer that records which agents exist, who owns them, and when they were created or decommissioned. It provides governance visibility, but it does not by itself authorise a live action or prevent a tool call from executing.
• Verifiable Credential: A verifiable credential is a cryptographically bound assertion that ties an agent's access to a specific issuer, scope, and validity window. In agent governance, it limits how long an identity can act and makes the approval record traceable at execution time.
• Know Your Agent: Know Your Agent is a governance model that ties consequential AI agent actions to a verified human authoriser at the moment of execution. It shifts control from registration-time trust to point-of-action verification, which is critical when agents can decide and act at machine speed.

Deepen your knowledge

NHI Governance, agentic AI identity, machine identity security, and secrets management 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 1Kosmos: When Control Plane Tools Don't Stop AI Agents from Acting: The Execution Plane Gap. Read the original.