Notifications
Clear all
Topic starter
24/06/2026 7:14 pm
TL;DR: Control plane tools can discover, inventory, and assign ownership to AI agents, but they do not stop an agent from acting three months later when it independently calls tools or provisions infrastructure, according to 1Kosmos. The real governance gap is runtime authorization: existing identity models assume access is stable enough to review, but autonomous agents can create and use privileges inside a single session.
NHIMG editorial — based on content published by 1Kosmos: When Control Plane Tools Don't Stop AI Agents from Acting: The Execution Plane Gap
Questions worth separating out
Q: How should security teams govern AI agents that can call tools autonomously?
A: Security teams should govern autonomous agents at two layers.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
1Kosmos's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how the execution plane intercepts MCP tool calls before they reach the target system.
- Detailed description of verifiable credential fields, including issuer identity, validity window, and permitted scope.
- How CIBA-based approval flows work when an agent needs human authorisation for a high-risk action.
- The article's own compliance framing for GDPR Article 22, SOC 2, and OWASP Agentic Top 10 alignment.
👉 Read 1Kosmos's analysis of control plane and execution plane governance for AI agents →
AI agent control plane gaps: are your runtime checks keeping up?
Explore further
25/06/2026 4:27 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent governance needs an execution plane, not just inventory
