How it works
Delegated authority is the effective power an agent receives for a particular role or run. It is not whatever the prompt says the agent may do. It is the intersection of several enforceable controls:
- Identity: which agent, operator, service account, or run is making the request.
- Credentials: which systems and resources that identity can reach.
- Tool surface: which operations the harness exposes, including their parameters and constraints.
- Policy: which requests require denial, approval, or additional verification.
- Runtime limits: how long, how often, and within what budget the authority remains usable.
When the agent invokes a tool, the harness should evaluate the request against these controls before producing a side effect. The resulting decision should be attributable to the run and recorded with the requested action, target, decision, and outcome.
Authority should also have a lifecycle. It is granted for a defined purpose, narrowed when the task permits, and revoked or expired when the work ends. For sensitive operations, the harness can split authority across steps: the agent prepares a change, a verifier checks it, and an approval policy decides whether execution may proceed.
Why it matters in an agent harness
A model can generate an unexpected action even when its instructions are clear. It may misunderstand context, follow hostile retrieved text, select the wrong account, or repeat an operation after an uncertain result. Delegated authority limits what those failures can affect.
The important design question is not merely whether the agent can call a tool. It is what that tool can do with the credentials behind it. A generic shell, an unrestricted API token, or write access to an entire workspace creates a much larger failure domain than a task-specific operation with a scoped credential. Tool names and descriptions improve model behavior, but they do not create a security boundary.
Well-bounded authority improves several operating properties:
- Failure containment: a bad decision cannot escape the resources assigned to the task.
- Reversibility: destructive operations can be excluded, staged, or routed through compensating actions.
- Observability: decisions can be tied to a specific identity, permission, tool call, and result.
- Evaluation: tests can verify attempted prohibited actions, not just successful task completion.
- Recovery: expired authority prevents a resumed or duplicated run from acting under stale assumptions.
Broad authority also makes diagnosis harder. When one credential can touch many systems, an operator must reconstruct which capability the agent actually needed and why it used another. Narrow grants make the intended control boundary legible before execution and the actual behavior easier to audit afterward.
Delegated authority vs autonomy level
These concepts answer different questions. Autonomy level describes how much procedural discretion the agent has. Delegated authority describes the maximum power the surrounding system will honor.
| Design question | Delegated authority | Autonomy level |
|---|---|---|
| What does it bound? | Resources and permitted actions | Independent planning and execution |
| Where is it enforced? | Credentials, tools, policy checks, and runtime controls | Agent loop, orchestration, and approval flow |
| Primary failure controlled | Unauthorized or excessive impact | Unwanted independent decisions |
| Can it be narrow while the other is broad? | Yes. A highly autonomous agent can have tightly scoped permissions. | Yes. A supervised agent may receive broad power for one approved operation. |
Reducing autonomy does not compensate for excessive authority. An approval step may lower the chance of a bad action, but the approved process can still cause disproportionate damage if its credential or tool surface is too broad. Conversely, narrow authority can make substantial autonomy acceptable when every reachable action has a contained blast radius.
The Rifty take
We treat authority as an enforceable property of the harness, not a promise extracted from the model. We optimize for the smallest grant that lets the work finish, accepting some additional orchestration in exchange for clearer failure boundaries. Approval is useful for consequential judgment, but it is not a substitute for scoped credentials and constrained tools.
Implementation checks
- List the exact resources and actions required by each agent role.
- Remove ambient credentials that are unrelated to the current task.
- Separate read, prepare, approve, and execute permissions where consequences differ.
- Enforce restrictions below the prompt, at the tool or authorization boundary.
- Bind temporary grants to a run, task, tenant, target, or expiration time.
- Require fresh authorization after a checkpoint resumes into changed conditions.
- Record who granted authority, what was requested, and what the system allowed.
- Test denied actions, cross-scope access, repeated calls, and confused-deputy paths.
- Treat unknown outcomes carefully before retrying a side-effecting operation.
- Revoke authority when the task completes, fails, or exceeds its execution limits.
Frequently asked questions
How should I choose the right amount of delegated authority?
Start with the smallest resource set and action set that can complete the task, then remove ambient access and broad credentials. Add time limits, spend or execution limits, and approval gates where consequences are hard to reverse. Expand only from observed failures, not hypothetical convenience.
Is delegated authority the same as agent autonomy?
No. Autonomy describes how independently the agent selects and sequences work. Delegated authority describes what the system will let it do. A highly autonomous agent can operate inside a narrow sandbox, while a closely supervised agent may temporarily receive broad authority for one approved action.
Can prompt instructions safely restrict an agent’s authority?
Prompt instructions should shape intent, not enforce authority. Treat tool registration, credential scope, policy checks, sandboxing, and runtime limits as the enforcement path. If a prompt is ignored or manipulated, the same request should still be denied at the control boundary before the side effect occurs.
When should delegated authority be revoked?
Disable or expire delegated authority when the task completes, the run fails, its operating context changes, or its execution limits are exceeded. A resumed run should revalidate sensitive grants rather than assume they remain appropriate. Revocation should also invalidate cached sessions or tokens that could preserve access.