# Policy Through the Trajectory

Search Engineering · Course · Part 3 · Chapter 14

Interactive edition: https://mutapa.dev/search-engineering/course/policy-through-the-trajectory

Authority is local to each protected decision. Every cache, memory store, delegated service, and resumed checkpoint must verify the current principal, audience, scope, policy version, and validity before using evidence.

[Chapter 13](https://mutapa.dev/search-engineering/course/permissioned-retrieval.md) 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](https://mutapa.dev/search-engineering/course/permissioned-retrieval.md). 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.

> Interactive instrument: Policy trajectory lab. The interactive edition follows correlation and verified authority through caches, memory, delegation, and checkpoint resume, showing where a protected receiver must deny or narrow work.

[W3C Trace Context](https://www.w3.org/TR/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](https://www.rfc-editor.org/rfc/rfc8693) 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](https://mutapa.dev/search-engineering/course/maintain-state-and-recover.md) 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](https://mutapa.dev/search-engineering/course/evaluate-agentic-search.md)'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](https://mutapa.dev/search-engineering/course/connectors-and-trust-boundaries.md) turns those integrations into explicit trust boundaries.