Authority & Trust

The Problem with Binary Trust

Most agent frameworks treat trust as binary: the agent can do everything, or it needs approval for everything. Neither works in practice.

An autonomous agent with no constraints will eventually do something it shouldn’t. A supervised agent that needs approval for every action creates the babysitter tax: a senior human spending their time watching a machine instead of doing their own work.

Real organisations use graduated trust. A new hire starts with limited authority. As they demonstrate competence, they earn more. The same principle applies to digital workers.

Four Authority Levels

Level	Label	Practical meaning
0	escalate-only	The worker can research and prepare recommendations, but cannot take any action. Every decision goes to a human.
1	restricted	The worker can act within a narrow, explicitly listed set of operations. Everything else goes to a human.
2	supervised	The worker can act on most operations. Only high-impact operations (defined per-deployment) require escalation.
3	autonomous	The worker can act on all operations within its declared capabilities. It must still log everything and should notify on high-impact actions.

Authority is a Ceiling

The authority level in the worker descriptor is a ceiling, not a floor. A runtime may constrain a worker below its declared level based on deployment policy. It must not grant authority above the declared level.

This means you can define a worker as supervised in the spec, then deploy it as restricted in a new client environment until you’re confident in its behaviour there.

Three Enforcement Points

DWS enforces authority at three levels:

Level 1: Pre-execution gate. Before the worker harness is even assembled, the runtime checks the worker’s authority level against the incoming intent. If the intent requires authority the worker doesn’t have, it’s rejected or escalated. This is pure policy evaluation. No model is involved.

Level 2: In-prompt advisory. The worker’s authority level and boundaries are injected into the system prompt. The worker is expected to self-govern during reasoning. This is advisory, not enforceable. Models sometimes ignore instructions.

Level 3: Tool-call interception. At every tool invocation, the runtime intercepts the call and checks it against the worker’s authority and boundary declarations before dispatching to the MCP tool server. This is synchronous and enforceable. The worker cannot bypass it.

Levels 1 and 3 are structurally enforced by the runtime. Level 2 depends on the model. This layered approach means that even if the model ignores its authority instructions (Level 2), the runtime catches the violation at the tool call (Level 3).

Earning Trust

Authority levels are not static. A worker that demonstrates consistent performance can be promoted:

1. Deploy at restricted with a narrow operation set.
2. Monitor verification pass rates and escalation frequency.
3. When confidence is sufficient, promote to supervised.
4. Continue monitoring. Promote to autonomous when warranted.

DWS’s lifecycle spec (Spec 14) formalises this with promotion criteria: minimum test runs, minimum verification pass rates, and optional human approval gates.