Fence shared session caches with authorization generations

Trigger

Use this when one process serves multiple root and child sessions, caches context for later message transformation, and may outlive authorization replacement or revocation.

Failure prevented

A process-global or session-only cache can inject another session's context. More subtly, stale context can survive authorization replacement and appear to authorize queued network work. Deleting cache entries does not close the race when a worker already holds a snapshot or revocation occurs between a local check and request transmission.

Practical steps

1. Key every immutable entry by trusted root identity, child binding identity, authorization identity, and a nonreused authorization generation. Require exact lookup; never fall back to a latest, root-only, or neighboring entry.
2. Give each child an immutable sanitized snapshot and binding identity. On authorization replacement, recreate or explicitly rebind it with a new binding identity; never silently upgrade it.
3. Make replacement a linearizable authoritative transition. First make the old generation unusable, then establish the new generation. Cancel queued old-generation work and delete old entries afterward; deletion is cleanup, not enforcement.
4. Carry immutable generation and capability identity through publication, transformation, queues, and workers. Fence delayed writes and fail closed on absent state, errors, or mismatch.
5. Keep context separate from authority. Network operations require a short-lived capability bound to principal, generation, scope, audience, and expiry. Make capability consumption indivisible with revocation at one authority boundary, or validate and redeem it remotely. A local check immediately before send is insufficient because revocation may occur between check and transmission.
6. Bound memory with per-entry and total-byte limits, entry and active-session caps, idle expiry, and lifecycle deletion. Reserve capacity before asynchronous allocation. Account for stored entries, pinned snapshots, queued work, child count, and transient copies. Evict expired entries, then least-recently-used inactive entries; reject admission rather than evicting in-use state.
7. If context must be shortened, produce an explicitly marked, structurally valid, non-authoritative result. Never byte-truncate structured or security-relevant data.
8. Log only opaque identities, sizes, transitions, and rejection reasons, never cached content or capabilities.

Limits

This pattern does not define the distributed revocation protocol, remote consistency model, crash recovery store, or capability format. Immediate revocation across a network requires an authoritative redemption point or acceptance of a documented revocation window. Generations must remain unique across restart to avoid identity reuse. Resource limits must include all retained and in-flight representations, not just map entries.

This guidance is supported by reasoned security and concurrency analysis, including an independent reasoning review. No executed tests support it.