How it works
A control surface turns policy into an enforceable decision at a specific point in execution. It sits between an agent’s proposed move and the system capable of carrying that move out. A prompt telling the agent to avoid destructive actions is guidance. A tool wrapper that rejects an unauthorized deletion is a control surface.
A useful control surface usually performs a short sequence:
- Capture the proposed action and relevant execution state.
- Resolve the actor, delegated authority, permission scope, and applicable policy.
- Evaluate deterministic limits and, where required, request approval.
- Allow, deny, narrow, pause, or redirect the action.
- Record the decision and enough context to explain or replay it.
The enforcement point can appear at input assembly, tool selection, credential issuance, state transition, loop continuation, export, or recovery. Its location matters. A check performed after an irreversible side effect is observability, not control.
The strongest surfaces operate on structured actions and authoritative state. They do not rely on the model to describe its own intent accurately. They inspect what will actually execute, apply policy outside the model, and make the result visible to the rest of the harness.
Why it matters in an agent harness
Agents convert uncertain reasoning into concrete actions. Without control surfaces, the distance between a mistaken inference and a real side effect can be one tool call. The harness may log the error, but it cannot contain it. Control surfaces create places where uncertainty meets deterministic authority.
Permissions are the clearest example. An agent may be allowed to read a repository but not publish changes, or draft a message but not send it. Those distinctions only hold when enforced at the credential, tool, or state-transition boundary. Instructions inside model context are insufficient because they compete with other instructions and do not limit the underlying capability.
Control surfaces also make autonomy adjustable without redesigning the entire workflow. A low-risk read can proceed automatically. A write can require a validated diff. A financial or destructive action can require explicit approval. The same agent loop can therefore operate under different authority while the harness retains a stable enforcement model.
They improve failure containment by stopping invalid work before it propagates. A schema check can reject malformed output before another agent consumes it. An execution limit can halt a looping worker. A checkpoint can prevent continuation when required evidence is absent. These controls narrow the blast radius of both model errors and infrastructure faults.
A surface should also produce evidence about its own decisions. Record the proposed action, policy version, relevant state, decision, and resulting transition. This supports audit, evaluation, and incident analysis. It also exposes a common design error: a policy may exist in documentation while no runtime component actually enforces it.
The tradeoff is friction. Every surface adds policy code, state handling, and possible delay. Too few surfaces leave authority implicit. Too many scatter control across wrappers, prompts, and callbacks until operators cannot predict which rule wins. I prefer a small number of explicit surfaces placed immediately before consequential transitions.
Control surface vs control plane
The distinction changes where engineering responsibility belongs. A control surface is the local enforcement point. A control plane defines, distributes, or coordinates the policy and state used by one or more surfaces.
| Axis | Control surface | Control plane |
|---|---|---|
| Primary role | Enforce a decision at an execution boundary | Manage policy, authority, or coordination across boundaries |
| Typical scope | One tool call, transition, credential, or loop decision | Multiple agents, runs, tools, or policies |
| Failure question | Did this action bypass enforcement? | Was the wrong policy or state distributed? |
| Required property | Cannot be skipped on the protected path | Remains authoritative and consistent enough for its consumers |
A system can have control surfaces without a centralized control plane. That is often reasonable for a small harness. What it cannot safely have is a control plane whose policies are advisory because execution paths bypass the surfaces meant to enforce them.
The Rifty take
We optimize for controls that are close to the side effect, explicit about authority, and legible after the run. We accept some execution friction when an action is difficult to reverse, but we do not treat approval as the only form of control. A deterministic denial, narrowed permission, execution budget, or recoverable checkpoint is often the stronger boundary.
Implementation checks
- Identify every path that can produce an external, costly, privileged, or irreversible effect.
- Place enforcement before the effect, including alternate tools and recovery paths.
- Evaluate the actual structured action rather than the model’s explanation of its intent.
- Resolve permissions from authoritative state and scoped credentials, not prompt text.
- Define the possible outcomes: allow, deny, narrow, pause, redirect, or terminate.
- Fail closed when policy, identity, or required state cannot be resolved.
- Record the proposal, applicable policy, decision, reason, and resulting state transition.
- Test bypasses, stale approvals, retries, duplicate calls, and resumed executions.
- Verify that operators can locate and change the controlling policy without tracing scattered callbacks.
- Reassess the surface whenever a new tool, credential path, or autonomous transition is added.
Frequently asked questions
Is a system prompt a control surface?
A system prompt can influence behavior, but it is not an enforceable control surface by itself. The model can misunderstand it, encounter conflicting context, or produce a prohibited action anyway. The control surface is the external mechanism that inspects and blocks, narrows, pauses, or redirects that action before execution.
Where should control surfaces be placed?
Place control surfaces immediately before consequential state transitions or side effects. Common locations include tool invocation, credential issuance, writes, publication, loop continuation, and recovery. Earlier checks can improve efficiency, but the decisive check must guard the execution path that actually carries authority.
Does every tool call need human approval?
No. Approval is only one control decision and is usually too expensive for every call. Low-risk operations can pass deterministic checks automatically, while destructive, privileged, costly, or difficult-to-reverse actions receive stricter limits. Match intervention to permission scope, reversibility, and blast radius.
How do you test a control surface?
Test both expected decisions and attempted bypasses. Submit allowed, denied, malformed, duplicated, stale, resumed, and over-scoped actions through every execution path. Confirm that no protected side effect occurs before evaluation and that each decision leaves enough evidence to explain the policy and resulting state.
Can observability replace a control surface?
No. Observability explains what happened, while a control surface can change whether it happens. Traces and alerts may reveal a dangerous action after execution, but they do not contain it. The useful design pairs enforcement with records that show what was proposed, decided, and ultimately executed.