# Session- and auth-bound task context cache
## Trigger
Use when an agent plugin caches task context before a system-message transform, multiple root or child sessions share one process, and authorization can be revoked or replaced while a root session remains alive.
## Failure this prevents
A process-wide or session-only cache can inject one session's context into another, retain context after authorization replacement, or let stale context authorize queued, retried, or background network work. Unbounded entries and retained callbacks can also exhaust memory.
## Practical steps
1. Use a canonical immutable key containing plugin instance, tenant or authorization lineage, root session, session epoch, live authorization generation, content revision, and explicit child binding. Include capability or policy scope when reuse could cross those boundaries. Use reserved root sentinels that real identifiers cannot produce.
2. Keep root and child entries separate. Inherit only through an explicit immutable snapshot; do not share mutable objects, buffers, request objects, closures, or full histories.
3. Read authorization state and its generation as one consistent snapshot. At every cache read, transform injection, and network operation, obtain live authorization state rather than trusting a generation captured across an await.
4. On revocation or replacement, atomically advance the generation, close and tombstone the old generation, cancel its queued and in-flight work where the transport supports it, and prevent old callbacks, retries, refreshes, redirects, streams, and follow-up calls from writing or dispatching.
5. Treat context as descriptive intent only. Enforce authorization at the network boundary with a defined linearization point or transport-level cancellation guarantee. Deny when authorization state is missing, stale, inconsistent, or changes before the operation's permitted dispatch point.
6. Remove entries on completion, failure, cancellation, timeout, epoch change, and shutdown. Ensure eviction and invalidation synchronize with readers and that closures and copied representations do not retain sensitive data.
7. Bound memory with per-entry and aggregate byte limits, entry-count limits, TTL or idle expiry, and LRU eviction. Count object overhead, copied strings and buffers, tombstones, queued work, and in-flight work. Reject oversized values explicitly.
8. Keep logs, errors, metrics, traces, serialization, timing, and size signals value-free where context may be sensitive. Fail closed during startup, restart, authorization-provider errors, and external authorization changes.
## Limits
A cache key does not replace authorization. Equality of identifiers is insufficient when authorization state can change or be reused; the live authorization source and consistency model must be authoritative. A pre-dispatch check alone cannot prevent a later revocation unless the network layer provides a cancellation or enforcement guarantee. Managed runtimes may retain immutable credential copies, so clearing sensitive material is best-effort unless storage is explicitly controllable. TTL and LRU alone are not hard memory bounds unless all retained work and representation overhead are included.
## Validation scenarios
Reason through concurrent roots, sibling and nested children, replacement during cache population and transform execution, queued dispatch, retries, redirects, streaming, background refresh, child inheritance, late callbacks, provider failure, eviction pressure, and cross-session lookup attempts. This guidance is based on reasoned analysis in the supporting discussion; no repository-specific inspection or executed tests support it.