How it works
A permission boundary is enforced outside the model, not requested inside the prompt. The agent proposes a tool call; the harness decides whether that call is inside the allowed set before anything runs. It has two layers that work together:
- A policy over the tool surface. An allow/deny list of tools, plus scoping on their arguments — which paths are writable, which network hosts are reachable, which credentials are mounted. The model never sees the tools it isn't granted.
- A sandbox that contains execution. Even a permitted call runs inside a jail — a scoped filesystem, a restricted network namespace, a token with narrow scope — so the effect of the call is bounded even if the intent was wrong.
The distinction matters: policy governs what the agent may attempt; the sandbox governs what actually happens if the attempt is malformed or hijacked. A well-built boundary assumes the model's reasoning can be corrupted and still holds. It is checked on every call, not once at startup, because agent state and context drift over a long run.
Crucially, the boundary is data, not judgment. It is a declared constraint the harness evaluates deterministically — no LLM sits in the enforcement path deciding whether a write is allowed.
Why it matters in an agent harness
An agent loop turns a stochastic model into a sequence of real side effects. Without a boundary, the agent's authority equals the authority of the process it runs in — which in practice is often the operator's full machine or a production credential. That makes the blast radius of a single bad step unbounded.
A permission boundary caps that blast radius before the fact. It converts "the agent could do anything" into "the agent can do these things, here, and nothing else." That has direct engineering payoffs:
- Containment of prompt injection. When a tool result carries an instruction to exfiltrate a key or delete a directory, the boundary is what stands between the injected instruction and the resource. Reasoning can be fooled; a filesystem scope cannot be argued with.
- Reversibility stays cheap. If an agent can only write inside a worktree it can only damage a worktree — so rollback is a discard, not an incident.
- Legible authority. The boundary is an artifact you can read, diff, and review. "What can this agent touch?" becomes a config question, not an audit of every reasoning trace.
- Failure containment across a team. In a multi-agent system, per-agent boundaries stop one worker's mistake from becoming a shared-state corruption.
The boundary is the harness feature that lets you grant real autonomy without granting real risk.
Permission boundary vs. least privilege
These travel together but they are not the same thing, and confusing them produces boundaries that are enforced but too wide.
| Least privilege | Permission boundary | |
|---|---|---|
| What it is | A sizing principle: grant the minimum needed | An enforced mechanism: the actual limit that holds |
| Answers | How small should the grant be? | What stops the agent at the edge? |
| Lives in | Design intent | Runtime enforcement (policy + sandbox) |
| Failure if absent | Over-broad grants | No containment at all |
Least privilege tells you where to draw the line. The permission boundary is the line, enforced. You want both: a boundary sized by least privilege, enforced by a sandbox. A tightly-scoped policy with no sandbox is a suggestion; a strong sandbox with an over-broad policy is a well-guarded open door.
The Rifty take
We treat the permission boundary as the thing that makes autonomy affordable. We would rather grant an agent narrow authority inside a real sandbox than broad authority behind a clever prompt, because we assume the reasoning layer is corruptible and the enforcement layer is not. The tradeoff we accept is friction — an agent occasionally blocked from a call it legitimately needed — because a boundary that only holds when the model behaves is not a boundary. Fitted, not configured: the grant should match the task, and expand by explicit decision, never by default.
Common failure modes
- Boundary checked once, then trusted. Authority granted at startup but never re-evaluated as context drifts — long runs slip past their intended scope.
- Policy without sandbox. An allow-list with no execution jail: the agent can't ask for the wrong tool, but a permitted tool with a malicious argument still does damage.
- Ambient credentials. A broad token or an inherited environment variable inside the sandbox quietly restores the authority the boundary was meant to remove.
- LLM in the enforcement path. Using a model to decide whether a call is allowed makes the boundary itself injectable. Keep enforcement deterministic.
- Over-broad write scope. Granting the whole repo or the whole home directory when a worktree would do — reversibility and blast radius both suffer.
- Silent widening. Adding a tool or a path to "unblock" the agent without review, so the boundary erodes one exception at a time.
Frequently asked questions
What is the difference between a permission boundary and a guardrail?
A permission boundary is the enforced outer limit on what resources an agent can reach, backed by a sandbox. A guardrail is a broader term for any constraint on agent behavior, including soft ones like prompts or heuristics. The boundary is the hard, deterministic subset that holds under prompt injection.
Why can't I just instruct the agent not to touch certain resources?
Because instructions live in the reasoning layer, which is stochastic and injectable. A tool result or crafted input can override a prompt-level rule. A permission boundary is enforced outside the model by the harness, so it holds regardless of what the agent decides or is tricked into deciding.
Does a permission boundary need a sandbox?
Yes. A policy alone limits which tools the agent may request, but a permitted tool called with a malicious or malformed argument can still cause damage. The sandbox contains the effect of execution — scoped filesystem, restricted network, narrow tokens — so a mistaken call is bounded, not just an intended one.
How does a permission boundary relate to blast radius?
The boundary sets the blast radius. Whatever the agent is permitted to reach and change defines the maximum damage a single bad step can do. Sizing the boundary by least privilege — a worktree instead of the repo, a scoped token instead of an admin key — is how you keep that radius small and reversible.
Should the boundary change during a run?
Only by explicit decision, never by default. Authority should be re-evaluated on every tool call, not granted once at startup, because agent state and context drift. Widening the boundary mid-run to unblock an agent should be a reviewed, logged action — silent widening is how enforced boundaries quietly erode into open doors.