AI Agent Control Plane: Identity and Kill Switches (2026)

An AI agent control plane is the layer that gives every agent its own identity, decides which tools and data it may use on each call, records what it did, and can stop it within seconds. In 2026 Microsoft, Google, AWS and Okta all shipped one. Treat it as five parts: identity, registry, policy gateway, audit, kill switch.

Updated 13 November 2026. A year ago most production agents ran on a shared service account with an API key in an environment variable. That is changing fast. Each large platform vendor now sells an "agent control plane": a place to register agents, give them identities, put a policy check in front of every tool call, and switch them off. This post looks at what the vendors actually shipped, based on their own pages. It then sets out a reference architecture you can build or buy, with the failure modes that matter in production.

What is an AI agent control plane?

It is the management layer that sits outside the agent's reasoning loop and controls what the agent is allowed to do. The model decides what it wants to do next. The control plane decides whether it may, with which credentials, and records the result. The term comes from networking, where the control plane sets the rules and the data plane moves the packets.

A working control plane does five jobs:

1. Identity: each agent (and each instance acting for a user) has its own identity, not a shared key.
2. Registry: a single inventory of agents, their owners, tools, models and status.
3. Policy enforcement: a gateway that checks every tool call against rules before it runs.
4. Audit and observability: a trace of inputs, decisions, tool calls, approvals and outputs.
5. Kill switch: the ability to stop one agent, one tool or all agents quickly, without a redeploy.

Which vendors launched agent control planes in 2026?

All the large identity and cloud vendors now have one, and most went generally available this year. Here is what each one says it does, from their own pages:

Sources: Microsoft Agent 365, Google Agent Platform docs, AWS AgentCore Policy GA, Okta's Oktane release of 22 September 2026, Anthropic. Okta notes that features not yet generally available may slip, so check before you depend on them.

Two patterns stand out. First, the vendors agree on the shape: identity per agent plus a gateway that enforces policy on tool calls. Second, the kill switch is still the least mature part. Okta, for example, lists its expanded runtime kill switch for the fourth quarter of 2026.

How should AI agents get identities and credentials?

Give every agent its own identity in your identity provider, and give it short-lived, scoped tokens per task instead of long-lived keys. When an agent acts for a user, the token should carry both: the agent's identity and the user it represents. That is the only way your audit log can answer "which agent did this, for whom, with what authority?"

In practice:

• No shared service accounts. Google describes Agent Identity as a granular alternative to shared service accounts. Whatever stack you use, the principle holds.
• Short-lived tokens. Okta's Cross App Access replaces non-expiring keys with short-lived tokens. AWS and Anthropic keep long-lived secrets in a vault the agent never reads directly.
• Delegation, not impersonation. The agent should get a token that says "agent X on behalf of user Y, scope Z", not the user's own session. If the agent is compromised, the damage is limited to scope Z.
• Owner on record. Every agent identity has a named human owner and a review date, the same way you treat a privileged service account.

If your agents call MCP servers, this connects directly to the MCP authorization spec. Servers must reject tokens not issued for them, and token passthrough is forbidden. See MCP security in 2026.

How do you enforce permissions on an AI agent's tool calls?

Put a deterministic policy check between the agent and every tool, outside the model. The prompt can ask the model to behave, but only code outside the model can stop it. A tool call should pass four checks before it runs: is this agent allowed this tool? Is this argument within limits (amount, record count, recipient domain)? Does this action need human approval? Is the agent, tool or tenant currently disabled?

AWS's implementation shows the pattern: policies sit in a policy engine attached to the gateway, which "intercepts agent-tool traffic and evaluates each request against the policies before allowing or denying tool access". Google's Agent Gateway plays the same role, with Model Armor screening for prompt injection and data leakage. If you build your own, keep policies as versioned data (Cedar, OPA/Rego, or a simple rules table) so security teams can review and change them without a code release.

Approvals belong in the control plane

Human approval is a policy outcome, not a UI feature. The gateway returns "needs approval". The control plane parks the call, notifies the right person with the full context, and releases or rejects it. That way every agent and every channel gets the same approval rules, and the approval itself lands in the audit log. Our human-in-the-loop guide covers how to keep approvals fast enough that people actually use them.

What does a real kill switch for an AI agent look like?

A real kill switch is a set of graded stops that take effect in seconds without a deploy, and are tested regularly. One big red button is not enough. You need four levels:

Two details make or break it. First, token revocation: disabling an agent does nothing if it holds a valid token for another hour, which is exactly what Okta's planned runtime kill switch targets. Second, in-flight work: a stopped agent may leave a half-finished multi-step task. Design every tool to be idempotent and every workflow to be resumable or reversible, so stopping is safe.

Regulators expect this too. For high-risk systems, Article 14(4)(e) of the EU AI Act requires that people overseeing the system can interrupt it through a "stop" button or a similar procedure. Those obligations apply from 2 December 2027 for Annex III systems (see EU AI Act deadlines after the Digital Omnibus).

What should an agent control plane log?

Log enough to replay the decision. For every step, record the agent identity, the delegated user, the model and prompt version, the input the model saw (or a hash with a pointer for sensitive data), the tool call and arguments, the policy decision and rule ID, any approval, the result, and the cost. Keep logs append-only and outside the agent's own reach.

Common gaps we see in production:

• Tool results are logged but the policy decision is not, so you cannot show why an action was allowed.
• The model version is missing. After a model upgrade, you cannot tell which behaviour came from which model.
• Retrieved documents are not recorded, so an injected instruction hidden in a document is invisible during an investigation.
• Logs live in the vendor's console only, with that vendor's retention, instead of your SIEM.

The same traces feed your evaluation suite: replay last week's real tool calls against a new model or prompt version before you switch.

What does a reference architecture for an agent control plane look like?

Seven components, from the user's request to the tool and back:

1. Identity provider (Entra, Okta, Google, Cognito): issues agent identities and delegated, short-lived tokens.
2. Agent registry: agent ID, owner, purpose, model, allowed tools, risk tier, status (active, paused, retired).
3. Agent runtime: runs the loop (your code, a framework, or a managed runtime). It holds no long-lived secrets.
4. Tool gateway: every tool and MCP server sits behind it. It authenticates the agent, evaluates policy, enforces rate and spend limits, and screens inputs and outputs.
5. Policy store: versioned rules (allow-lists, argument limits, approval thresholds, kill-switch flags) that security can edit.
6. Approval service: parks calls that need a human, routes them, and records the decision.
7. Audit pipeline: append-only traces to your SIEM or warehouse, with alerting on denied calls, approval spikes and cost anomalies.

The runtime can be swapped (a vendor runtime today, your own tomorrow) as long as the gateway, policy store and audit pipeline stay yours. That is the real point of a control plane: it outlives any one model or framework.

Should we buy an agent control plane or build one?

Buy the identity and registry layer from the vendor you already use for identity. Build or carefully configure the policy rules yourself, because they encode your business: limits, approvals and who may do what. If you are all-in on Microsoft, Agent 365 plus Entra is the obvious start. On AWS, AgentCore Identity, Gateway and Policy cover most of it. Across several clouds and SaaS suites, an IdP-centred approach (Okta or Entra) with your own gateway in front of internal tools avoids tying governance to one runtime.

Whichever you choose, check that it can stop an agent mid-task, revoke its tokens, and export full traces. Those three are where products differ most today. Our enterprise agent platform comparison covers the rest of each vendor's stack, and the AI agent security checklist lists 24 controls to test against.

How BeevR builds this

Our agent work is built on the same principles we published in Kite, our open-source agent framework. The LLM is treated as untrusted. Every tool call passes kernel validation outside the model. Circuit breakers and idempotent tools make stopping safe, and a kill switch works without a redeploy. Every tool call and approval goes to an immutable audit log, and actions that touch patient records or money go through approval gates. When a client already has Entra, Okta or AgentCore, we plug into it instead of inventing a parallel system.

BeevR is a senior, founder-led team in Hanoi. Fixed-scope, fixed-price phases from $10K, a working demo every Friday, and you own the code and IP from day one. See how we deliver production AI agents.

Running agents on shared keys today? Book a 30-minute call and we will sketch the control plane for your stack.