Security & trust
Isolation you don't have to take on trust.
Tenant isolation is a release-blocking property, not an afterthought. It's compiled into every query on the server, not filtered by the interface — which means there's no client-side check to forget, misconfigure, or bypass.
How isolation actually works
The browser never sends a query.
It sends catalogue identifiers, filter values and a time range. The server resolves the current account's roles and grants, compiles the query itself with an authoritative customer identifier injected into every matcher, escapes every value, and only then sends the request to the metrics store.
Every customer query carries an authorised entity matcher the server adds — not one the browser can remove, widen, or spoof.
An administrator who manages users and domains gains no implicit ability to query customer metrics. The two are separately granted, and combining them is visible and deliberate.
Signal calculations come from a fixed, validated operation registry. A domain author or a customer can never insert executable query text.
Range, step, series count, point count and export size all have hard ceilings, independent of anything a domain definition requests.
Publishing a domain proves it's structurally valid. Enabling it for customers is a separate, explicitly confirmed action after live data has been reviewed.
User, grant and domain changes write their audit record inside the same database transaction as the change — never as an afterthought that can silently fail.
The unglamorous fundamentals, done properly
Argon2id password hashing with bounded parameters. Opaque, hashed session and CSRF tokens. Idle and absolute session expiry with server-side revocation. Login throttling by source and by account, with a precomputed hash so an unknown username takes the same time as a known one. A strict content security policy, no framing, no MIME sniffing, HTTPS required for anything beyond loopback.
Alerting is opt-in, and contained
On-demand and reproducible historical evidence stays the default: nothing is scheduled unless you ask for it. Alerting is a separate subsystem that stays off until you enable it and is gated by its own capability. When you do turn it on, it is built to add as little attack surface as possible — channel secrets are encrypted at rest with AES-256-GCM, webhook delivery refuses loopback, private, link-local and cloud-metadata targets and pins the vetted address it dials, a rule notifies once when it fires and once when it clears, and every rule change and delivery attempt is audited. Investigation first; paging only if you choose it.
Where it runs
Your infrastructure, your data, full stop.
Panopticon is a single self-hosted binary. Your metrics stay in the metrics store you already run; your identity data stays in the database you already run. Nothing about a customer's data has to leave systems you control to get this evidence in front of them.
Have a security question before you evaluate further?
Ask us directly — we'd rather answer it now than after you've committed time to a trial.