How it works
An authorization boundary sits between an agent’s proposed action and the system that can execute it. The model may decide that an action is useful, but the boundary decides whether that action is allowed. This separation matters because model intent is not authority.
A practical boundary evaluates each requested operation against current, explicit facts:
- Identify the actor, run, and delegated task.
- Resolve the requested tool, resource, operation, and credential scope.
- Compare the request with the applicable authorization policy.
- Allow, deny, or route the operation through an approval checkpoint.
- Record the decision and enough context to explain it later.
The boundary should be enforced outside the model’s reasoning path. A prompt that says “do not delete files” is guidance, not authorization control. The executable layer must reject a prohibited deletion even when the model argues that deletion is necessary.
Authorization can also change during a run. A read-only research phase may permit retrieval but forbid publishing. A later export phase may grant access to one destination for one asset. These transitions should be explicit state changes, not permissions inferred from the conversation. The useful unit is therefore not “what this agent can generally do,” but “what this run may do at this step, to this resource, under these conditions.”
Why it matters in an agent harness
Agentic systems turn generated decisions into side effects. That makes authorization a runtime reliability mechanism, not merely an access-control concern. The harness must assume that a model can misunderstand a task, follow hostile retrieved text, choose an overly broad tool, or continue operating after its context no longer represents the operator’s intent.
A well-placed authorization boundary limits the consequences of those failures. A research agent can search and extract without receiving publishing credentials. A drafting agent can write an artifact without modifying the authoritative workflow state. An exporter can publish an approved asset without gaining access to unrelated sites or records. Each delegation carries only the authority required for its function.
This improves control because policy remains enforceable even when model behavior varies. It improves failure containment because one mistaken tool choice cannot automatically reach every connected system. It also improves reversibility: actions with weak rollback options can require narrower conditions, a checkpoint, or direct approval before execution.
Authorization decisions must remain observable. A denial without an explanation is difficult to diagnose, while an approval without attribution is difficult to audit. The execution record should connect the request, resolved identity, policy version, decision, and resulting side effect. Sensitive credential values should not appear in that record, but the credential scope and authority source should.
The boundary also protects against confused-deputy failures. An agent may have legitimate access to a powerful tool while processing instructions supplied by a less-trusted source. If the harness treats tool possession as permission, retrieved content can influence the agent to spend authority that the source never had. The boundary should evaluate the operator’s delegation and workflow state, not just the model’s stated rationale.
Authorization cannot guarantee that an allowed action is correct. It answers whether the action may occur, not whether it is wise, accurate, or useful. Evaluation, deterministic verification, budgets, and stop conditions handle different failure classes. Treating authorization as a universal guardrail produces broad policies that are hard to reason about and still miss semantic mistakes.
Authorization boundary vs permission scope
The two concepts are related but serve different design decisions. Permission scope describes the authority attached to an identity or credential. An authorization boundary is where a concrete request is checked before that authority can produce an effect.
| Question | Authorization boundary | Permission scope |
|---|---|---|
| Primary concern | Whether this operation may proceed now | What operations a principal or credential can potentially perform |
| Typical inputs | Actor, run state, operation, resource, policy, approval status | Resource set, action set, constraints, credential lifetime |
| Failure when too broad | Prohibited actions cross into execution | Compromise or misuse exposes more capability |
| Engineering decision | Where and when to enforce | How narrowly to grant authority |
You need both. A tightly scoped credential reduces the maximum blast radius, while a boundary applies workflow-specific conditions inside that maximum. Credential scope alone may not know that publishing is forbidden before review. A policy check alone cannot recover authority already embedded in an unnecessarily powerful credential if enforcement is bypassed.
The Rifty take
We treat model output as a request for authority, never as authority itself. We optimize for narrow, explicit delegation and accept the extra policy and state machinery because implicit permission is harder to inspect and contain. Irreversible or externally visible actions deserve a boundary that the model cannot talk its way around.
Implementation checks
- Enumerate the exact tools, operations, resources, and side effects controlled by each boundary.
- Enforce policy in executable code outside prompts and model-generated plans.
- Bind authorization to the run, workflow stage, actor, and resource rather than only an agent name.
- Give workers scoped credentials instead of a shared credential with broad access.
- Deny requests when identity, scope, policy, or authoritative workflow state cannot be resolved.
- Require explicit approval for actions whose blast radius or reversibility exceeds the delegated task.
- Record allows, denials, approvals, policy versions, and per-call attribution without logging secrets.
- Test indirect requests from retrieved content, stale approvals, replayed calls, and attempts to switch resources.
- Verify that denied operations fail visibly and cannot succeed through another tool path.
- Revoke temporary authority when the stage, run, or approval window ends.
Frequently asked questions
Where should an authorization boundary be enforced?
Enforce it immediately before the protected operation reaches the tool, service, or credential that can create the side effect. Earlier checks can improve feedback, but they are not sufficient. Every alternative execution path must converge on an enforcement point the model cannot bypass through prompting or tool selection.
Is an authorization boundary the same as an approval gate?
No. An authorization boundary evaluates whether an operation may proceed under policy; an approval gate is one possible condition within that decision. Many low-risk operations can be authorized automatically, while high-impact operations may require approval. The boundary remains responsible for validating that the approval is applicable, current, and correctly scoped.
Should each agent have its own authorization boundary?
Not necessarily. Boundaries should follow authority transitions and side-effect surfaces, which may not match agent identities. Several agents can share a read boundary while publishing passes through a separate, stricter boundary. Design around operations, resources, workflow state, and blast radius rather than assuming one static policy per agent.
What information should an authorization decision record?
Record the requesting actor and run, requested operation, target resource, resolved permission scope, policy version, decision, approval reference when applicable, and resulting execution identifier. Exclude secret credential material. The record should let an operator explain why the call was allowed or denied and connect it to any side effect.
How should the harness behave when authorization context is missing?
Deny the operation and surface an explicit operational failure. Missing identity, policy, workflow state, or credential scope is not evidence of permission. A permissive default hides configuration defects and can expand authority silently. The failure should identify the unresolved input so the operator can repair the boundary rather than bypass it.