AI agent control planes define the governance layer enterprises need

At a glance

What this is: This guide argues that AI agent control planes govern runtime identity, policy, and auditability, and that agent sprawl fails when organisations treat dashboards, LLM gateways, and MCP gateways as the same layer.

Why it matters: IAM, NHI, and security teams need this distinction because autonomous agents create access, approval, and revocation problems that existing identity programmes and monitoring stacks do not solve on their own.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 88.4% of organisations experienced at least one AI agent security breach in the past twelve months.

👉 Read Obot's guide to AI agent control planes and governance

Context

AI agent control planes sit at the point where identity, authorisation, and auditability intersect for autonomous systems. In practice, that means the programme is no longer about whether agents can call tools, but whether those calls are uniquely attributable, policy-checked at runtime, and revocable when the owning team changes.

The governance gap shows up when teams scale agents faster than they can inventory them. A model, an MCP gateway, and a dashboard can all exist without answering the central identity question: who owns the agent, what can it do right now, and what evidence remains after it acts?

Obot frames this as a control-plane problem because the failure mode is cross-layer. That framing is typical for organisations that reach production with agent sprawl before establishing lifecycle control, approval boundaries, and audit reconstruction as part of the identity model.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What breaks when organisations manage agents like dashboards instead of governed identities?

A: What breaks is revocation, accountability, and incident reconstruction. A dashboard can show activity, but it cannot on its own prove who approved access, which policy fired, or how to shut the agent down cleanly. The result is a control gap that looks visible on paper but remains ungoverned in production.

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

What an AI agent control plane governs at runtime

An AI agent control plane is the enforcement layer between autonomous agents and the systems they touch. It handles identity issuance and revocation, evaluates policy on each tool invocation, and preserves an audit trail that links a decision to the action it produced. That is different from an LLM gateway, which governs model calls, or an MCP gateway, which governs tool transport and access. The key technical point is runtime enforcement. If policy is only documented, and not checked at execution time, the organisation has observability without control.

Practical implication: Treat the control plane as the runtime trust boundary, not a reporting layer, and require every privileged tool call to be evaluated before execution.

Why LLM gateways and MCP gateways do not solve agent governance

An LLM gateway can redact prompts, route traffic, and apply rate limits, but it does not decide whether a tool call should happen. An MCP gateway can authenticate connections to tools and inspect tool metadata, but it does not manage the broader identity lifecycle or the decision context that surrounds an agent’s action. The agent identity layer is what binds the actor to an owner, a scope, and a revocation path. Without all three layers, teams end up protecting the transport, not the behaviour.

Practical implication: Map each control to its layer and close the gaps between model, transport, and identity before allowing production-scale agent workflows.

Why revocation and auditability become control-plane requirements

A dashboard can show what happened after the fact, but it cannot prevent repeat misuse or reconstruct a defensible decision path by itself. Control planes need a kill switch, a lifecycle owner, and a record of the policy decision that justified each high-risk action. That matters because agent sprawl turns forgotten identities into persistent exposure. If an agent cannot be shut down cleanly, or if its decisions cannot be traced, governance has failed at the identity layer rather than at the monitoring layer.

Practical implication: Build revocation, immutable decision logging, and owner-based lifecycle controls into the agent operating model before scaling beyond a small pilot.

Threat narrative

Attacker objective: The objective is to turn an approved agent footprint into a wider, harder-to-audit access path that can perform actions beyond intended scope.

1. Entry occurs when an agent is granted service account access or tool access beyond the original review boundary, often as a shortcut to make a pilot work.
2. Escalation follows when the agent uses that access to call a tool it should never have reached, or chains multiple tool calls into an unauthorised workflow.
3. Impact appears when no decision trail exists, auditors cannot reconstruct the action, and teams cannot reliably revoke the agent or prove what it changed.

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

AI agent governance is now an identity problem, not a model problem. The article is right to separate the control plane from the LLM and the MCP gateway because runtime authority is the failure domain. Once an agent can select tools, invoke them, and act without human approval at each step, identity scope becomes the decisive security boundary. Practitioners should stop treating agent governance as an overlay and recognise it as part of the identity stack.

Agent sprawl creates a revocation deficit that monitoring cannot repair. The most operationally dangerous failure mode is not lack of visibility alone, but the inability to answer who owns an agent, what it can still do, and how it is shut off. That is a lifecycle failure that spans NHI governance, PAM-style control of elevated actions, and audit readiness. The practitioner implication is clear: if revocation is not reliable, governance is not real.

Runtime policy enforcement is the named concept this market keeps circling around. A control plane only matters when policy is checked at the moment of action, not after an incident or an audit request. That is the distinction between documentation and enforcement, and it is what separates agent observability from agent governance. Organisations that still rely on post-hoc logging are building for forensic recovery, not for safe execution.

Autonomous agents collapse the assumption that access is stable long enough to review. Access review processes were designed for identities whose entitlements persist until the next certification cycle. That assumption fails when an agent acquires and consumes access dynamically during execution, because the review arrives after the decision window has already closed. The implication is that governance has to move from periodic attestation to runtime control.

The market is converging on governance infrastructure, not point tools. Once organisations recognise that identity, policy, audit, and reversibility must operate together, they stop asking which single product solves agent risk. The discipline is moving toward shared control layers that can govern NHI behaviour across platforms, clouds, and workflows. Practitioners should expect procurement to shift from feature comparison to architectural fit.

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 lens, see OWASP Agentic Applications Top 10 for the runtime risk categories that control planes must enforce against.

What this signals

Runtime governance will become the dividing line between pilots and production. Organisations that cannot revoke an agent, trace its decisions, or tier its privileges will keep encountering the same failure mode under different labels. With 98% of companies planning more AI agents within twelve months, the pressure is not whether adoption grows, but whether identity governance grows with it.

Identity teams should prepare for control-plane buying criteria, not feature shopping. The market is moving toward shared enforcement layers that can connect agent identity, policy, and audit across workflows. That means procurement conversations will increasingly hinge on revocation, decision logging, and runtime policy checks rather than dashboard breadth.

Agent sprawl is creating a new form of governance debt. The longer teams defer identity assignment and lifecycle ownership, the more likely they are to inherit invisible access paths that were created for convenience and forgotten in production. That pattern is already visible in the broader NHI estate, and agentic systems are accelerating it.

For practitioners

• Define agent ownership before deployment Assign each agent to a named business or platform owner, bind it to a unique identity, and require a documented purpose, scope, and revocation path before production access is granted.
• Enforce policy at tool-call time Evaluate every high-risk tool invocation in context, including parameters, target system, and current state, rather than relying on session-level authorisation or prompt filtering alone.
• Create a clean revocation path Ensure any agent, connected service account, or tool integration can be disabled immediately without hunting across multiple workflows or teams, and verify that shutdown removes its effective access.
• Require decision-level audit records Log the input, policy check, tool call, and approval outcome together so investigators can reconstruct why the agent acted, not just that it acted.
• Tier agents by impact zone Separate low-risk assistants from agents that can touch production, payments, or sensitive data, then apply stricter approval and reversibility controls to the higher-impact tier.

Key takeaways

• AI agent control planes matter because they govern runtime behaviour, not just model output or transport.
• The evidence shows a widening gap between agent adoption and the ability to revoke, audit, and contain agent actions.
• Identity teams should treat agent governance as shared infrastructure, with ownership, policy checks, and reversibility built in from the start.

Key terms

• Agent Control Plane: An agent control plane is the policy layer that decides what an AI agent may do before execution. It connects discovery, identity, and authorization so the organisation can enforce task-scoped limits instead of relying on static registration or after-the-fact review.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• 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.
• Reversibility: Reversibility is the ability to stop an agent, roll back its access, and contain its effects without manual forensics across multiple systems. In identity governance, it is the control that turns a bad action into a recoverable event instead of a persistent operational incident.

What's in the full article

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

• The exact control-plane capability breakdown for identity issuance, policy enforcement, audit logging, and reversibility.
• The implementation distinctions between LLM gateways, MCP gateways, and agent identity layers in a production stack.
• The vendor's own architecture notes on integrating agent governance with existing identity providers and enterprise workflows.
• The deployment and operational considerations for running governance across multiple agent frameworks and environments.

👉 Obot's full post covers the control-plane architecture, layered governance model, and implementation detail behind the framework.

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