Include the actual data scope in the design
RFC 9111 distinguishes private and no-store directives. Those headers do not automatically govern a custom in-memory cache. This local design keys authorised results by tenant, subject, scope and relevant policy revision; do not place raw credentials in a key.
| Request | Available cache | Decision |
|---|---|---|
| Tenant A, reader U1 | Tenant B result | Never reuse across tenant boundary |
| U1 after export permission removed | Result under earlier policy revision | Check current permission; refuse revoked export and invalidate the cached result |
| Sensitive response marked no-store | Custom persistence path | Ensure that path also respects storage policy |
Test a policy change against a warm cache
Populate the cache as an authorised synthetic user, remove the relevant permission and repeat the request. The revoked export must return no restricted response body even with a warm cache. Log the cache decision with safe identifiers, without copying the private response into diagnostics.
Does Cache-Control: private alone prevent your own application from sharing one result between users?
Show the worked answer
No. It constrains compliant shared HTTP caches; your application still needs correct scope keys, access checks and invalidation rules.