How it works
Scoped permissions turn a broad instruction such as “update the customer record” into an enforceable authorization envelope. The harness grants access according to the task, not the agent’s general capabilities. That envelope can constrain which tools the agent may call, which resources it may address, which operations it may perform, and how long the authority remains valid.
A typical control sequence is:
- Resolve the task into required operations and resources.
- Grant the narrowest permissions that can complete those operations.
- Check every tool invocation against the grant at execution time.
- Require approval or a new grant when the agent crosses the boundary.
- Revoke the grant when the task ends, expires, or enters an uncertain state.
The check must use authoritative runtime data. Prompt instructions such as “only edit this file” are useful direction, but they are not authorization controls. The tool adapter, credential broker, sandbox, or policy layer must reject an out-of-scope operation even when the model requests it confidently.
Scope can cover several dimensions at once: read versus write, named records, filesystem paths, API methods, environments, transaction limits, time windows, and delegation rights. The effective permission is their intersection. A grant that restricts the tool but leaves its credentials unrestricted is only partially scoped.
Why it matters in an agent harness
Agents select actions from context, and that context can be incomplete, stale, ambiguous, or adversarial. Scoped permissions limit what a mistaken selection can change. They do not make the model correct. They make certain incorrect actions impossible or explicitly interruptible.
This changes the failure model. If an agent preparing a release note has read access to a repository and write access only to one draft, a confused instruction cannot directly alter production code. If the same agent holds a general repository token, the prompt may describe a narrow task while the runtime still exposes a broad blast radius. The real boundary is the authority accepted by the underlying system.
Scoped permissions also improve legibility. A trace can record the grant, the attempted operation, the policy decision, and any approval that expanded authority. Operators can then distinguish three different events: the model chose the wrong action, the harness denied an unauthorized action, or the authorization policy allowed more than intended. Without that separation, permission failures look like generic agent failures.
Reversibility still matters. Permission checks can prevent an unauthorized write, but they cannot undo an authorized write that produced a bad result. High-impact operations need both narrow authority and recovery controls such as staged changes, checkpoints, diffs, idempotency keys, or compensating actions.
Scope should follow task state. Research may require broad read access but no mutation. Drafting may permit writes to a workspace. Publishing may permit one destination only after an approval gate. Carrying every permission through the whole loop makes early context or planning errors unnecessarily powerful.
Delegation creates another boundary. A parent agent should not be able to give a worker authority it does not hold, and it should not pass its entire grant when the worker needs only one operation. Otherwise, adding subagents quietly widens the number of actors able to exercise the same privilege.
Scoped permissions vs least privilege
The distinction affects implementation. Least privilege is the governing principle. Scoped permissions are one mechanism for enforcing it during a particular task or run.
| Concern | Scoped permissions | Least privilege |
|---|---|---|
| Primary question | What may this agent do for this task? | What is the minimum authority any actor should hold? |
| Typical boundary | Tool, resource, operation, time, and run | Role, service, user, process, or system design |
| Runtime behavior | Authorizes or denies individual actions | Guides how grants and roles are designed |
| Common failure | A grant is narrow on one dimension but broad on another | A nominally minimal role accumulates exceptions over time |
A system can claim least privilege while issuing long-lived, reusable credentials to agents. Conversely, a task-scoped grant can still be excessive if its resource set or write authority is broader than the work requires. The principle and mechanism must agree.
The Rifty take
We treat permissions as executable task boundaries, not behavioral suggestions placed in a prompt. We optimize for narrow, short-lived authority and accept the extra policy work because a denied edge case is easier to inspect than an invisible expansion of blast radius. When the required authority changes, the harness should make that transition explicit.
Implementation checks
- Define scope across tools, resources, operations, environment, duration, and delegation rights.
- Enforce the grant at the tool or credential boundary, outside the model’s prompt context.
- Separate read, create, update, delete, publish, and administrative authority where consequences differ.
- Bind grants to a task or run, then revoke or expire them at a clear terminal state.
- Deny unspecified operations rather than treating an incomplete policy as broad access.
- Record grants, denials, expansions, approvals, and revocations in the execution trail.
- Test indirect paths, including shell access, generic HTTP clients, shared credentials, and delegated workers.
- Pair authorized high-impact writes with diff review, checkpoints, rollback, or compensating actions.
- Treat unknown execution outcomes as unresolved authority use until the underlying system is reconciled.
Frequently asked questions
Are prompt instructions enough to scope an agent’s permissions?
No. Prompt instructions describe expected behavior, but the model can misunderstand or disregard them. Permission scope must be enforced by the harness, tool adapter, sandbox, credential layer, or destination system. The runtime should reject an out-of-scope action even when the agent believes the action is necessary.
How narrow should a permission grant be?
A grant should cover the smallest practical set of tools, resources, operations, environments, and time needed to complete the defined task. Scope should not be so brittle that routine work constantly fails, but convenience alone does not justify reusable credentials or unrelated write access.
Should permissions change during an agent run?
Yes, when the task enters a stage with different authority requirements. Research, drafting, review, and publishing usually need different access. The harness should revoke obsolete grants and make any expansion explicit through policy or approval instead of carrying maximum authority through the entire loop.
How should scoped permissions work with subagents?
A subagent should receive only the subset of the parent’s authority required for its delegated task. It must not gain authority the parent lacks, inherit unrelated permissions automatically, or retain credentials after completion. Record the delegation so each sensitive call can be attributed to the effective actor and grant.
Do scoped permissions make agent actions reversible?
No. Scoped permissions reduce which actions can occur, but an allowed action can still be harmful or incorrect. Reversibility requires separate mechanisms such as staged writes, checkpoints, diffs, idempotency, rollback, or compensating actions. Strong harnesses combine authorization boundaries with recovery paths for consequential mutations.