Keep authenticated AI answers out of shared HTTP caches

Review the response after the application cache

A fictional support assistant stores completed answer A-17 for Cedar. Its database and application cache correctly enforce Cedar membership. A reverse proxy then receives the HTTP response. If that proxy can reuse the response without reaching the application, correct database authorization alone cannot establish the delivery boundary.

This guide covers GET delivery of completed answers, not caching inference POST requests or streaming fragments. Draw the browser, each TLS-terminating proxy or CDN, and the origin. Record which components can store responses and which configuration takes precedence. An opaque answer URL is not permission to share its contents.

The original worksheet below is PROPOSED_UNRUN. No application/test HTTP request, cache experiment, CDN change, model call or customer-data inspection was performed. The fictional routes and headers are design choices to review, not this hub's deployed configuration.

Separate credential forms from sharing permission

RFC 9111 sections 3.5 and 7.3 distinguish an Authorization request header from cookie-based personalization. Shared-cache reuse of an Authorization response requires a permitting response directive and compliance with its constraints. The listed exceptions include public, s-maxage and must-revalidate. Other storage and reuse conditions still apply.

Consequently, do not treat must-revalidate as a privacy barrier: it governs stale reuse and can unlock that Authorization restriction. Cookies do not inherit this special protection; even a Set-Cookie response field does not itself prohibit caching. Neither credential form replaces an explicit response policy.

For A-17, choose the same confidentiality requirement whether the application authenticates with a bearer header or a session cookie. Keep credentials and sensitive questions out of URLs and ordinary diagnostics. This worksheet does not propose putting bearer tokens into a cache key.

Choose storage and reuse separately

MDN's Cache-Control reference explains three different choices. Unqualified private excludes shared-cache storage while permitting a private cache. Unqualified no-cache allows storage but requires successful origin validation before reuse. no-store directs both private and shared HTTP caches not to store the response.

For the sensitive answer route, the fictional policy selects Cache-Control: no-store. For a separate, less-sensitive personal status view, it deliberately allows browser storage with private, no-cache. That tradeoff needs product approval: a retained personal representation is different from a no-storage requirement. A browser cache is not an application account-isolation service on a shared device.

Do not add public freshness directives to authenticated content merely to improve performance. Review managed-cache overrides separately; emitting a header is not evidence that every deployed intermediary follows the intended policy.

Use an eight-case delivery decision matrix

Cedar reader C can access A-17; Maple reader M cannot. Resource P-1 is a separately reviewed public help page containing no personalized answer. The public freshness duration below is an invented 60-second choice, not a recommended universal lifetime. Each expected result is a proposed acceptance condition.

The denial status is an application disclosure decision; preserve the protocol requirements of any chosen status. Explicitly cover redirects and error middleware too, rather than attaching policy only to successful controller output.

Authorize before validating a stored representation

RFC 9110 sections 13.2.1 and 15.4.5 put normal request checks before conditional evaluation. A 304 tells a conditional GET or HEAD client to use its stored representation. It is therefore consequential even though it transfers no new answer body.

For the optional private status view, resolve the current identity and object permission first. Then select the authorized representation and evaluate its validator. A matching ETag must not turn a denial into 304. Return the applicable cache and validation metadata on a legitimate 304, including Cache-Control, ETag and Vary when the corresponding 200 would carry them.

MDN documents Vary as identifying request-header dimensions that influence response selection, consistently including 304 responses. For P-1, language negotiation warrants Accept-Language. Vary is not an authorization check, a purge mechanism or a substitute for excluding private answers from shared storage.

Keep retained copies and evidence limits visible

MDN's caching guide notes that no-store does not delete an already-stored response. Browser history restoration also differs from a new validated HTTP fetch. Plan actual invalidation and retained-copy handling for a policy change; a new origin header cannot retract a downloaded answer.

A future offline recorder could compare these invented request states with expected status and header records. Passing it would establish only that recorder's logic. Actual intermediary storage, revalidation, overrides and browser behavior require separately authorized verification; this article establishes none of them.

Boundary is a prelaunch model router with planned request-path checks, not a shipped HTTP-cache enforcement service. Its eight mock action-policy tests do not test this worksheet or a live CDN. Keep review records to synthetic case IDs and decisions, without real tokens, prompts or answer bodies.