How an agent control plane works

The layers

In practice the runtime separates into a few distinct responsibilities. Each one maps to a familiar enterprise control, adapted for agents rather than people.

• Identity — each agent has its own identity, mapped to groups from your existing identity provider rather than a local user list.
• Authorisation — scopes declare the tools, data and environments an agent may reach. An empty policy denies everything.
• Model gateway — every inference call passes through a mediated path where the model, destination and content class are checked before the request leaves.
• Tool mediation — outbound calls to internal systems are brokered, so credentials never sit in agent code.
• Approvals — defined actions pause for a named human, with separation of duties enforced by the runtime.
• Budgets and rate limits — spend, tokens and call volumes are attributed to agents and projects.
• Observability and audit — runs, decisions, spend and alerts are recorded in a tamper-evident log.

Identity for agents

Agents should not run as anonymous services or share service accounts. Each agent should have an identity that maps to the organisation's directory, with group membership determining what it can do.

This matters because it makes the agent part of the same identity fabric as every other privileged workload. When an agent reads a customer record, the access log shows the agent's identity, not a shared application account. When an auditor asks who approved an action, the identity is the starting point for a complete chain.

Agent identity also enables lifecycle management. When a project ends, the agent's credentials, scopes and budget can be revoked cleanly. Without identity, agents become invisible long-lived service accounts that nobody owns.

Authorisation as policy, not permission

Authorisation for agents should be policy-based and deny-by-default. An agent with no policy can do nothing. Every granted scope is explicit, versioned and reviewable.

The policy language should be rich enough to express real constraints: which tools may be called, which environments may be reached, which content classes may leave the boundary, and which operations require approval. But it should also be simple enough that a security reviewer can read it without being a developer.

The right default matters enormously. A default-allow system silently expands when someone forgets to restrict a new tool. A default-deny system fails in a way that is visible and correctable. In agent runtimes, failing closed is safer than failing open.

Why fail-closed matters

Systems that default to permissive behaviour degrade quietly. A missing policy becomes an allowed action; a misconfiguration becomes an exception nobody notices. Fail-closed defaults invert that: the absence of an explicit grant is a denial, and the failure mode is a blocked run rather than an unrecorded one.

It makes early configuration slower and everything afterwards defensible. Teams spend more time up front declaring what an agent may do, but they spend far less time investigating incidents caused by implicit permissions.

Fail-closed also protects against drift. As new tools, new models and new data sources are added, the runtime continues to deny access until a human updates the policy. That turns expansion into a deliberate act rather than an accidental one.

The model gateway

A model gateway sits between agents and every model they might call. Its job is to enforce the organisation's model policy at the point of inference.

That policy might say: this agent handles customer complaints, so its prompts may not contain personal data, and they may only be sent to the self-hosted model in the UK environment. Another agent might be allowed to call a frontier model, but only after a sanitisation step and only for content classified as public.

The gateway also provides the single point of observability the organisation needs to attribute spend and risk by model. Without it, model usage is scattered across applications, providers and invoices, and nobody can answer basic questions about total exposure.

Tool mediation and secrets hygiene

One of the most common security mistakes in agent systems is embedding credentials in agent code. An agent that needs to query a CRM, write to a database or call an internal API is given a token, and that token ends up in a repository, a prompt, or a notebook.

A control plane brokers these calls. The agent asks for an action; the control plane authenticates the request against the agent's identity and scope, then calls the target system using centrally managed credentials. The agent never sees the secret.

This pattern is familiar from API gateways and privileged access management. Applied to agents, it prevents the sprawl of long-lived credentials and makes it possible to rotate, audit and revoke access without touching agent code.

What changes for engineering teams

Teams stop writing governance code. Scopes, model choices, approval gates and budgets become configuration held in version control alongside the agent definition, reviewed like any other change. The application code goes back to being about the task.

This separation of concerns is the real productivity gain. Developers build the agent logic. Security owns the policy. Operations owns the runtime, the capacity and the budget. Legal and compliance rely on the records the runtime produces. Each group works in its own language, but on the same shared source of truth.

The result is that agents can move from experiment to production without a complete rewrite. The control plane provides the missing enterprise layer.