How it works
A control boundary turns an open-ended agent action into a governed unit of execution. It defines the conditions under which the step may operate and what must happen when those conditions no longer hold. The boundary belongs in the harness, where it can be enforced independently of the model’s reasoning.
A useful boundary covers six surfaces:
- Inputs: which instructions, records, files, and retrieved context the step may consume.
- Actions: which tools and operations it may invoke.
- Permissions: which resources it may read, create, modify, or delete.
- Execution: how long it may run, how often it may retry, and how much work it may initiate.
- Oversight: which actions require approval, produce an interrupt, or trigger review.
- Recovery: which state is checkpointed and whether failure calls for retry, rollback, compensation, or escalation.
These controls should be evaluated at runtime, not left as prose in a prompt. Before a tool call, the harness checks the proposed action against the permitted scope. After the call, it records the result and updates authoritative workflow state. If the action exceeds the boundary or produces an unknown outcome, execution stops on a visible state rather than continuing from an assumption.
A boundary may surround one tool invocation, one workflow stage, or an entire delegated run. Smaller boundaries usually make attribution and recovery clearer, but they add orchestration work.
Why it matters in an agent harness
Models can propose actions, but proposals are not authority. Without an explicit control boundary, the effective authority of an agent is whatever its credentials, tools, context, and retry behavior happen to permit. That accidental boundary is usually wider and less legible than the operator intended.
The first benefit is failure containment. A research step with read-only access cannot turn a retrieval mistake into a destructive write. A publishing step limited to one draft cannot update unrelated records. A retry limit prevents a transient error from becoming an unbounded loop of repeated side effects. The boundary does not make the model more accurate. It limits what an inaccurate decision can do.
The second benefit is reversibility. Recovery is credible only when the harness knows which state existed before the action, which changes were attempted, and whether the operation completed. Checkpoints, idempotency keys, execution journals, and compensating actions make different kinds of recovery possible. A generic “undo” instruction does not.
Control boundaries also improve observability. An operator can distinguish a denied action from a tool failure, an approval wait, or an unknown outcome. That distinction matters during incident response because each state calls for a different intervention. It also makes evaluation more useful: tests can ask whether the agent stayed within authority, not merely whether its final answer looked acceptable.
There is a cost. Narrow boundaries require more explicit state, permission design, and transition handling. Boundaries that are too tight can fragment useful work into approval-heavy steps. The engineering decision is therefore not maximum restriction. It is the smallest authority and blast radius that still lets the delegated task complete reliably.
Control boundary vs permission boundary
A permission boundary is part of a control boundary, but the terms should not be treated as interchangeable. Permissions answer what an actor is authorized to access. A control boundary also governs execution conditions, state transitions, oversight, and recovery.
| Design question | Control boundary | Permission boundary |
|---|---|---|
| What does it constrain? | Inputs, actions, permissions, execution, oversight, state, and recovery | Access to resources and operations |
| What happens on violation? | Stop, deny, interrupt, compensate, or move to an explicit failure state | Deny the unauthorized operation |
| Does it govern retries and budgets? | Yes, when those can change risk or cost | Usually not |
| Does it define recovery? | Yes | No |
This distinction changes implementation. Scoped credentials may prevent an unauthorized database write, but they will not stop an authorized operation from being repeated twenty times. Conversely, a retry budget will not prevent the first call from reaching the wrong account. Production harnesses need both controls, connected to the same run state and audit trail.
The Rifty take
We treat control boundaries as executable contracts around delegated work, not as reminders embedded in prompts. We optimize for small, inspectable units with explicit authority and recovery states, accepting some orchestration overhead to keep failures attributable and contained. If the harness cannot tell whether an action completed, it should preserve that uncertainty rather than infer success and continue.
Implementation checks
- Define permitted inputs, tools, resources, and write scopes for each automated step.
- Enforce the boundary outside the model’s prompt and reasoning context.
- Separate read, create, modify, delete, and external-send permissions where their consequences differ.
- Put limits on retries, iterations, elapsed time, tool calls, and delegated sub-work.
- Require approval before irreversible, high-impact, or scope-expanding actions.
- Record proposed actions, authorization decisions, tool results, and state transitions.
- Give unknown outcomes their own state; do not collapse them into success or failure.
- Specify whether each side effect is idempotent, reversible, or compensatable.
- Test denial, interruption, timeout, partial completion, and recovery paths.
- Revisit the boundary when tools, credentials, workflow state, or downstream consequences change.
Frequently asked questions
Where should a control boundary be enforced?
Enforce a control boundary in the harness around tool invocation, state transition, and recovery logic. Prompt instructions may explain the policy to the model, but they should not be the enforcement mechanism. The model proposes work; deterministic code checks whether that work falls within the delegated authority.
How narrow should a control boundary be?
Make the boundary as narrow as practical without breaking the task into unusable fragments. Start at the smallest unit with distinct permissions, side effects, or recovery needs. Broaden it only when repeated handoffs or approvals add more operational risk than the additional authority would create.
Is least privilege enough to create a control boundary?
No. Least privilege constrains resource access, but a control boundary must also cover inputs, execution limits, oversight, state transitions, and recovery. An agent can remain within its permissions while retrying an authorized side effect excessively, acting on untrusted context, or continuing after an ambiguous result.
What should happen when an agent crosses a control boundary?
The harness should deny the action and move the run into an explicit, inspectable state. Depending on the contract, it may request approval, interrupt execution, compensate for completed side effects, or fail the step. It should not silently widen authority or reinterpret the action as successful.
How do you test a control boundary?
Test the boundary with actions just inside and just outside every limit. Include unauthorized tools, excessive retries, malformed inputs, partial writes, timeouts, interrupted approvals, and unknown outcomes. Verify both prevention and evidence: the run should stop correctly and leave enough state to explain and recover from the event.