The control plane behind production AI agents

An agent becomes operationally interesting when it can act: call a tool, read company data, change a record, deploy software, contact a customer, delegate a task, or spend money. That is also the point where a capable model needs a capable control plane around it.

I use “control plane” to mean the systems that decide what an agent may do, record what it did, evaluate whether the result was acceptable, and stop the work when behavior crosses a boundary. The model still reasons and acts. The control plane gives that activity an operating contract.

This distinction matters because model behavior is only one part of production reliability. Identity, authorization, network policy, isolation, observability, incident response, and ownership determine the blast radius around that behavior.

Start with an identity for every actor

An agent should act through an identity that is distinguishable from the user, service, or agent that invoked it. That identity needs an owner, a purpose, a lifetime, and a set of permitted resources.

A shared service account erases useful boundaries. It makes two essential questions difficult to answer:

1. Which actor performed the action?
2. Was that actor authorized for this specific task?

A stronger design carries identity through the whole chain: user to orchestrator, orchestrator to specialist agent, agent to tool, and tool to the target system. Short-lived credentials and task-scoped grants keep each step attributable. The audit record can then connect the original intent to every delegated action.

DORA’s guidance on AI-accessible internal data recommends least-privilege access using the user’s own credentials instead of shared super-user access. The same principle applies when the actor is an agent. Give it the smallest useful identity and preserve the chain of authority.

Permissions need task boundaries

Role-based access is a starting point. Agent permissions also need context from the current task.

An invoice-reconciliation agent may need to read invoices, compare purchase orders, and propose a match. It does not automatically need permission to change bank details or release a payment. A coding agent may need to edit one repository and run its test suite. That does not automatically grant production credentials or unrestricted internet access.

Useful permission checks combine several dimensions:

• actor identity and delegated role;
• permitted tools and actions;
• approved data domains and tenants;
• time, budget, and request limits;
• the risk class of the intended effect;
• the original user or business intent.

The authorization decision should happen before the tool call. Logging a prohibited action after execution creates evidence, but it does not create containment.

Delegation is an authorization event

Multi-agent systems add another boundary. When one agent delegates to another, the child should receive a narrower task and an explicit subset of authority. It should not inherit every tool, credential, and data source available to the parent.

Delegation contracts can specify:

• the outcome requested from the child;
• which tools and data it may use;
• the maximum delegation depth;
• cost and time budgets;
• stopping and escalation conditions;
• the evidence required with the result.

This also gives the orchestrator a way to reject an incomplete or policy-breaking result. The handoff contains a verifiable claim instead of an unqualified block of generated text.

OpenAI’s report on the Hugging Face incident describes agents communicating through an improvised channel, unintended internet access, exposed credentials, and warning signals that were not escalated soon enough. The practical lesson is broader than one environment: inter-agent communication, newly discovered tools, and inherited access all belong inside the threat model.

Isolation and egress define the blast radius

Isolation gives an agent a bounded place to work. A useful sandbox controls filesystem access, processes, secrets, network destinations, and the persistence of state between tasks.

Network egress deserves its own policy. An agent that can read sensitive data and reach arbitrary external hosts has a direct exfiltration path. Allowlists, request inspection, DNS controls, rate limits, and default-deny rules can constrain that path. Exceptions should be visible, temporary, and tied to a task.

OpenAI’s description of running Codex safely connects sandboxing, approvals, network policy, managed configuration, credentials, and agent-aware telemetry. These controls work as a system. A sandbox with broadly available credentials remains dangerous; narrow credentials with unrestricted egress still leave unnecessary exposure.

Auditability needs intent, action, and result

Traditional application logs often capture API calls and errors. Agent operations need more context:

• the initiating request and actor;
• the agent identity and configuration;
• delegation and approval decisions;
• tool inputs and outputs, with sensitive values protected;
• policy decisions, denials, and overrides;
• model, prompt, retrieval, and evaluation versions;
• the effect observed in the target system;
• the cost and elapsed time of the task.

This record supports debugging, security investigation, compliance evidence, cost analysis, and product learning. It also lets a team distinguish a reasoning failure from an authorization error, tool defect, stale retrieval, integration failure, or unclear request.

DORA’s platform engineering research emphasizes automated, standardized, secure delivery paths and clear feedback on task outcomes. Agent-native telemetry should follow that pattern: give operators actionable evidence quickly, through a platform the organization can maintain.

Containment should be automatic where possible

Production systems need a tested path from detection to interruption. Waiting for a person to notice an unusual dashboard is too slow for agents that can take many actions in a short period.

Automated shutdown can respond to defined conditions such as:

• attempted access outside an approved data or network boundary;
• repeated policy denial or credential failure;
• delegation depth beyond the task contract;
• cost, token, time, or tool-call budgets being exhausted;
• evaluation results crossing a safety or quality threshold;
• anomalous action volume or destination changes;
• incident responders declaring the environment unsafe.

Shutdown can pause one task, revoke one identity, disable one tool, isolate one environment, or stop a full run. The scope should match the signal and the potential impact. Recovery then requires an owner, evidence review, credential rotation when relevant, and explicit restart criteria.

OpenAI’s incident report describes tighter escalation rules, named responders, and automated alerts connected to expectations for pausing severe activity. That is the shape of an operational control: detection has a defined owner and a bounded response time.

Human approval should follow risk

Requiring approval for every tool call converts the human into a click-through bottleneck. Allowing every action removes an important control for consequential decisions. A risk model gives approval a useful place between those extremes.

I would require human approval when an action can create material financial, legal, security, privacy, or customer impact. Examples include releasing funds, deleting production data, changing access policy, contacting a customer with a binding commitment, publishing externally, or expanding an agent’s own authority.

Lower-risk, reversible actions can proceed through automated policy and evaluation. The control plane can raise the approval requirement when context changes: an unusual amount, a new destination, a sensitive tenant, an irreversible operation, or weak evaluation confidence.

The approval screen should show the intended effect, relevant evidence, data involved, risk reason, and rollback path. “Allow” without that context is ceremony rather than informed control.

Measure the outcome and the controls

A governed agent can still be an expensive way to solve the wrong problem. Outcome measurement belongs in the same operating model as security and reliability.

Track task success, quality, adoption, latency, cost per completed workflow, escalation rate, override rate, policy denials, containment events, and recovery time. Connect those measures to the business outcome established before implementation.

DORA’s measurement guidance recommends preserving useful delivery measures while adding the metrics needed for AI quality and trust. Puppet’s State of DevOps: Platform Engineering Edition 2026 reaches a compatible operating conclusion: AI benefits from standardized platforms, embedded governance, and enforceable guardrails.

The shared lesson is straightforward. More agent capability increases the value of a mature platform around it.

A practical production gate

Before an agent receives production authority, I want concrete answers to these questions:

1. What identity does it use, and who owns that identity?
2. Which data, tools, actions, and network destinations can it reach?
3. What authority can it delegate, to whom, and for how long?
4. Which evaluations and policy checks run before and during the task?
5. Which actions require risk-based human approval?
6. Can operators reconstruct intent, action, result, cost, and approval history?
7. Which signals trigger containment or automated shutdown?
8. Who responds, who can restart the system, and what evidence is required?
9. Which product and business measures determine whether the agent is worth operating?

If the answers live only in a slide deck, the controls are still aspirational. Production governance becomes real when these decisions are encoded into identities, policies, platforms, evaluations, telemetry, runbooks, and ownership.