AI Agents Need a Control Plane, Not a Larger Prompt

Aug 20

By

ai agentsai infrastructuresecuritysystem design

An AI agent becomes a production system when it can read private context, call tools, mutate state, or spend money. At that point, “the model was instructed not to” is not a security boundary.

The correct architecture assumes the model can misunderstand, be manipulated by retrieved content, or choose the wrong tool. A deterministic control plane must decide what the agent may see, what it may do, how much it may spend, and which actions require a person.

Split reasoning from authority

The model proposes actions. The control plane authorizes and executes them.

user / event
    -> agent runtime (reason and propose)
    -> policy decision point
    -> approval gate when required
    -> typed tool gateway
    -> target system
    -> immutable audit event

Never hand the model a general-purpose credential and hope the prompt scopes its use. Tool credentials belong in the gateway. The runtime receives a capability limited to the current subject, tenant, operation, resource, and expiry.

Identity must survive the chain

Every action needs at least four identities:

  • the human or service that initiated the task;
  • the agent definition and deployed version;
  • the execution or task instance;
  • the credentialed tool or downstream service.

Without these, an audit log saying “agent called CRM” cannot answer who authorized it, which instructions were active, or which tenant was affected.

Propagate an execution ID, but do not confuse correlation with authorization. A trace ID helps find events; it grants no permission.

MCP standardizes transport, not your policy

The Model Context Protocol defines resources, prompts, and tools, plus authorization behavior for HTTP transports. Its authorization specification uses OAuth mechanisms and requires resource indicators so tokens are bound to their intended server. MCP servers must validate that tokens were issued for them and must not pass an inbound token through to an upstream API.

This prevents an important confused-deputy path: a legitimate token for one resource being replayed against another. It still does not answer whether this particular agent may refund this particular invoice for this tenant now. That is application policy.

Represent the decision explicitly:

{
  "subject": "user:1248",
  "agent": "support-agent@2026-08-20.3",
  "action": "invoice.refund",
  "resource": "invoice:inv_72",
  "tenant": "tenant:acme",
  "constraints": {
    "maxAmountCents": 5000,
    "expiresAt": "2026-08-20T16:05:00Z",
    "requiresApproval": true
  }
}

Authorize close to execution, not only when the conversation begins. Permissions, resource state, and risk can change during a long-running task.

Make tools narrow and typed

A tool named run_sql(query) or http_request(url, body) exposes an enormous authority surface. Prefer domain tools:

get_customer_summary(customer_id)
draft_refund(invoice_id, amount, reason)
submit_refund(draft_id, approval_token)

The gateway validates schema, tenant ownership, state preconditions, amount limits, and idempotency keys. Descriptions are user experience for the model, not enforcement.

Separate read, draft, and commit. The agent can explore and prepare a change without possessing immediate write authority. High-impact commits receive a short-lived approval token bound to the exact action digest; editing the amount or target invalidates approval.

Treat all retrieved content as data

An email, webpage, PDF, ticket, or tool response can contain instructions aimed at the model. The control plane must not promote retrieved text into trusted policy.

Use structural separation:

  • trusted system policy comes from versioned configuration;
  • user intent is recorded separately;
  • retrieved content is labelled untrusted;
  • tool output is validated against a schema;
  • sensitive actions are authorized from server-side facts, not model claims;
  • egress and accessible resources are allowlisted.

Prompt-injection detection may add a signal. It cannot be the only boundary because classification will have false negatives.

Bound autonomy with budgets

An agent can be logically correct and economically destructive. Give each execution budgets for:

  • model tokens and monetary cost;
  • wall-clock duration;
  • tool calls and retries;
  • rows, files, or accounts touched;
  • outbound messages;
  • concurrent child tasks;
  • irreversible operations.

Enforce budgets outside the model. When a limit is reached, stop at a recoverable checkpoint and return evidence. Do not ask the same model that exceeded a budget whether it should receive more authority.

Design every write for retries

Agent runtimes retry after timeouts, worker loss, or uncertain responses. A timed-out write may already have succeeded. Every mutating tool should accept a stable idempotency key derived from execution and logical action:

idempotency_key = sha256(execution_id + action_index + normalized_arguments)

The tool gateway stores the first result and returns it for identical retries. A different payload with the same key is rejected. For systems without native idempotency, add an adapter or a reconciliation state such as outcome_unknown; never translate uncertainty into an automatic second irreversible action.

Audit events must support reconstruction

Capture enough to reconstruct the decision without indiscriminately storing private prompts:

  • initiator, agent version, execution ID, and policy version;
  • tool name and normalized argument hash;
  • resources and tenant affected;
  • authorization decision and reason code;
  • approval identity and action digest;
  • idempotency key, result class, latency, and cost;
  • model and retrieval provenance where permitted.

Use append-only storage with retention and access controls. Redact secrets at ingestion. Auditability is not “log everything”; it is preserve the minimum trustworthy chain of custody.

Common mistakes

One OAuth token for the entire agent platform. A compromise becomes cross-tenant and cross-tool.

Approval of prose rather than action. “Proceed” is ambiguous. Bind approval to normalized arguments and resource state.

Tool schemas without server-side invariants. Types stop malformed inputs, not unauthorized valid inputs.

Giving write tools to a planning agent. Separate proposal from execution and keep least privilege per stage.

Logging secrets to improve debugging. Agent traces are a new sensitive data store; minimize them deliberately.

CTO review checklist

  1. Can the model execute anything that the policy layer did not independently authorize?
  2. Are tokens audience-bound, short-lived, tenant-scoped, and never passed through?
  3. Are irreversible actions separated into draft, approval, and commit?
  4. What happens after an ambiguous timeout?
  5. Which budgets stop loops and economic abuse?
  6. Can an incident reviewer reconstruct who authorized the exact action under which policy?

Agent quality will improve. The need for explicit authority will not. Build the control plane so stronger models become more useful without becoming more dangerous.

References

>