Data Handling
What PRISM sees, stores, and never touches. Every claim here is enforced in code and pinned by tests, not policy prose.
What the renderer sees
Chrome renders anonymously. Client cookies and Authorization headers are
never forwarded to the renderer — in render-all mode a request carrying
either is proxied to the origin instead of rendered at all, and in bot-only
mode a cookie-bearing crawler's render is kept out of the shared cache. Each
render runs in an isolated browser context (own cookies, storage, cache)
disposed after use.
What does reach Chrome: the URL, the negotiated Accept, the device class,
and any header the operator listed in [cache] vary. Credential headers
(Cookie, Authorization, forwarding and internal headers) cannot be
listed there — the configuration refuses to boot.
What the cache stores
Rendered HTML, its response headers, and a gzip copy. Memory only: there
is no disk persistence, no snapshot, no external store. Entries expire by TTL
(bounded by the origin's own Cache-Control) and the whole cache dies with
the process — a crash or restart is a clean loss, never a leak.
Personal data reaches the cache only if the origin renders it into anonymous pages. Pages behind authentication are never rendered, so never cached.
What the proxy path carries
Bypassed (human) traffic flows through PRISM to the origin with cookies and
authorization intact — PRISM is a reverse proxy on that path and stores
nothing from it. Client IPs are forwarded to the origin (X-Forwarded-For)
and appear in logs and audit events.
Logs
Operator-supplied bearer tokens are never logged — authentication failures
record only whether a credential was present. The one deliberate exception:
when admin.bearer_token is unset, PRISM generates a token and prints it
once at startup, because that is how the operator learns it. Audit events record caller IP, endpoint and
parameters (URLs, patterns), not header values.