Chapter 13 produced an authorized candidate set and a decision reference. Those outputs describe one decision for one principal, operation, scope, policy version, and moment. The agent now reads a cache, consults memory, delegates an availability lookup, or resumes from a checkpoint. Each move reaches another protected system.
A shared trace identifier can make that whole path observable. It cannot make the path authorized.
Keep correlation and authority separate
The instrument begins with the candidate set from Chapter 13. Use Step to follow the healthy request across one boundary at a time, then choose Unsigned authority. The delegated branch still shares the trace identifier and ordinary labels, but the receiver denies it because those labels have no integrity protection. Choose Correlation lost and follow the same path again. Authority remains valid while the events can no longer be joined into a complete trajectory.
Trace
Failure to inspect
- 1
Scoped plan
permitThe plan retains the decision reference without copying credentials.
W3C Trace Context defines fields for correlating distributed work and cautions against putting sensitive information into them. OpenTelemetry baggage can carry application values across calls, but ordinary baggage does not establish that a trusted issuer supplied those values. A principal name, tenant, or approval copied into a header remains an assertion until the receiving boundary verifies it.
A governed request therefore carries two channels with different jobs:
| Channel | Purpose | Examples |
|---|---|---|
| Correlation | join events into a trajectory | trace id, span id, parent relation |
| Authority | support a current protected decision | issuer, principal, actor, audience, scope, expiry |
The authority channel can be a verified session, workload identity, scoped token, signed request, or another mechanism the receiving system trusts. The model does not mint it. The application obtains, narrows, exchanges, and validates it.
Let every receiver decide
A prior permit is evidence that an earlier boundary allowed an operation. It is not a transitive grant for every later service. The cache checks whether the entry’s authorization class matches the caller. The memory store checks whether the current principal may read the saved preference. A delegated service validates the target audience and operation scope. The final synthesizer rechecks that every active evidence reference remains eligible.
OAuth 2.0 Token Exchange supplies a useful model for delegation: distinguish the subject whose authority is exercised from the actor making the call, then bind the exchanged token to a target resource and scope. A search agent often acts on behalf of a person, but the agent workload and the person are different identities with different accountability.
This creates an auditable sequence of local decisions rather than one long-lived permit. Each protected step records the policy version and reason it applied.
Scope memory and caches like evidence
Memory feels internal because the agent wrote it earlier. Its contents can still cross users, tenants, tasks, or policy versions. A useful memory record includes an owner or principal reference, authorization class, source evidence references, purpose, creation policy version, and retention limit. A read checks all of those fields before the payload enters model context.
Caches need comparable keys. A cache hit based only on normalized query text can reuse candidates or generated prose across principals. A safe key includes every input that changes eligibility, or the cache is physically partitioned by an equivalent authorization boundary. A mismatched entry is a miss rather than a nearly correct answer.
Resume work without extending authority
Chapter 10 used checkpoints to preserve verified progress across tool failures. Checkpointing stores work; it does not freeze policy. A resumed trajectory resolves current identity and current policy, then reauthorizes saved plans, evidence, memory references, pending operations, and delegated work.
Choose Resume checkpoint, then Policy changed. The scenario loads evidence saved under household-v17 and continues under household-v18. Ratatouille remains active. Interstellar moves to quarantine because the new policy no longer permits that record for the fixture profile. The trajectory can narrow its answer or stop. It cannot keep using the record because an older checkpoint once contained it.
Policy changes are only one source of staleness. Credentials expire, group membership changes, a user revokes approval, a resource moves to another tenant, or a connector refreshes a classification. Resume logic needs typed outcomes for all of these cases:
| Outcome | Resume behavior |
|---|---|
| permit | continue with the revalidated artifact |
| deny | remove it from active state and stop any dependent work |
| reauthorize | obtain current claims or evaluate current policy before use |
| indeterminate | fail closed or narrow the task according to an explicit completion rule |
Trace decisions without leaking authority
An operational trace should answer which protected boundary decided, which policy version ran, which principal and actor references were involved, what target and scope were requested, and what outcome followed. It should not contain bearer tokens, complete identity claims, restricted records, or prompt copies by default.
This distinction keeps Chapter 12’s trajectory evaluation usable. An evaluator can measure denied calls, stale-policy resumes, cross-scope cache attempts, and reauthorization latency from categorical events. Sensitive payloads can follow separate sampling, access, and retention rules.
The resulting trajectory remains attributable even as authority narrows. Its final open dependency is the system outside the application that supplies claims, records, live reads, or effects. Chapter 15 turns those integrations into explicit trust boundaries.