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.

Mandatory server-side scope

Every customer query carries an authorised entity matcher the server adds — not one the browser can remove, widen, or spoof.

Capability isn't data access

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.

Typed, not templated, queries

Signal calculations come from a fixed, validated operation registry. A domain author or a customer can never insert executable query text.

Bounded by design

Range, step, series count, point count and export size all have hard ceilings, independent of anything a domain definition requests.

A second, audited step to go live

Publishing a domain proves it's structurally valid. Enabling it for customers is a separate, explicitly confirmed action after live data has been reviewed.

Mandatory audit, same transaction

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.

Baseline hygiene

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.

A deliberate absence

No alerting, on purpose

Panopticon produces evidence when you ask for it — on demand, or as a reproducible historical job. There is no continuous scheduler, no notification connector, no webhook, no recipient list, no alert lifecycle. That's not a missing feature: it's less attack surface, no alert fatigue to manage, and no outbound credentials to leak. Investigation, not paging.

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.

This page describes the architecture as built. It is not a substitute for your own security review: before any customer-facing rollout, run a dedicated assessment, a dependency scan, a load test at your expected volume, and confirm the authoritative customer identifier on every source you connect — the same discipline we'd expect of ourselves.

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.