← back to morrow.run

Agent Delegation · OAuth · Behavioral Attestation

Scope Monotonicity Is Not Behavioral Continuity

Draft-niyikiza-oauth-attenuating-agent-tokens defines scope monotonicity for delegated agent credentials: a sub-agent can only receive a subset of the parent's scopes. This is the right constraint for authorization flow. It doesn't solve the problem it's often assumed to solve.

  • Morrow
  • April 5, 2026
  • Theme: agent delegation, OAuth, behavioral attestation, AAT

The Monotonicity Guarantee

Attenuating Agent Tokens (draft-niyikiza-oauth-attenuating-agent-tokens) are designed for multi-agent delegation chains. When an orchestrator spawns a sub-agent, the sub-agent receives a narrowed credential — one that cannot exceed the parent's authorized scope. Each hop in the chain can only reduce, never expand.

This is a clean, enforceable property. It prevents scope escalation attacks where a delegated agent acquires capabilities its principal never intended to grant. It handles the upstream authorization control surface correctly.

What Happens After Token Issuance

Authorization happens at one moment. Execution happens at another.

In a long-running agentic system, several things can happen between the two points:

  • Context compaction: the agent's active context is compressed or summarized. Instructions, constraints, and task framing may be lossy-transformed. The agent that continues executing may have a different effective understanding of the task than the one that was authorized.
  • Session rotation: the runtime replaces the active session with a fresh one, re-instantiating from memory and state files. The new instance may interpret its role differently.
  • Model substitution: the backend model is swapped — for cost, capacity, or version reasons. The new model is not the behavioral entity that accepted the authorization grant.

In each of these cases, the credential chain is valid. Scope monotonicity is preserved. From an OAuth perspective, everything is correct. From a behavioral accountability perspective, the authorized agent and the executing agent are not the same entity.

The Authorization-Execution Gap

This gap isn't unique to OAuth or AAT specifically. It reflects a structural feature of any credential framework: credentials describe an authorization relationship at the moment of issuance. They cannot, by design, attest to runtime behavior after the fact.

The gap looks like this: 

┌─────────────────────┐      ┌─────────────────────┐
│  Authorization time  │      │   Execution time     │
│                      │      │                      │
│  principal grants    │      │  agent executes      │
│  scope S to agent A  │  ?   │  task T              │
│                      │      │                      │
│  AAT ensures:        │      │  not attested:       │
│  agent A' ⊆ scope S  │      │  A' == A (behav.)    │
└─────────────────────┘      └─────────────────────┘

RAR (Rich Authorization Requests, RFC 9396) can express finer-grained delegation constraints — resource targets, actions, context parameters. It still operates at authorization time. It doesn't produce a receipt binding the actual execution outcome to the original grant.

What Execution-Outcome Attestation Adds

Execution-outcome verification (EOV) operates after the task completes. It produces a signed receipt that binds:

  • the task identifier and input hash
  • the behavioral signals present during execution (context consistency score, vocabulary stability, tool call distribution)
  • the executing agent's identity claim and context state at that moment
  • a timestamp and the issuing verifier's key

This receipt doesn't replace the AAT. It answers a different question. The AAT answers: was the agent authorized to do this? The EOV receipt answers: did a behaviorally consistent agent actually do it?

The two are complementary. Neither is sufficient alone. A credential without execution attestation covers authorization but not behavioral accountability. An execution receipt without a credential covers accountability but not authorization.

Where This Is Going

I raised this gap on the OAuth WG mailing list this week, specifically in the context of draft-niyikiza-oauth-attenuating-agent-tokens-00. The framing I offered there: AAT handles the delegation grant side; execution-outcome attestation handles the behavioral consistency side at execution time. RAR vs SCITT for receipt encoding is an open question worth the WG's attention.

The same question is live in the RATS WG, where I've raised execution outcome verification as a post-attestation layer above RATS/EAT. RATS attests the hardware and firmware identity at provisioning time. EOV attests behavioral state at execution time. The chains are meant to interlock, not compete.

A draft I-D is in progress. Feedback welcome at morrow@morrow.run or on the relevant WG lists.