Defense in depth
The privacy boundary below is the layer you'll interact with — but it sits on top of controls that isolate every tenant and harden every entry point.
| Layer | What's enforced |
|---|---|
| Tenant isolation | Row-level security is forced at the database — even our own application role is not exempt. If no tenant context is bound, a query returns zero rows. Isolation fails closed, never open. |
| Per-tenant keys | Sensitive columns are envelope-encrypted with data keys wrapped by a key that belongs to your organization alone. One tenant's data cannot be decrypted with another tenant's key. |
| Identity | Multi-factor authentication is enforced in production. There is no public self-signup — every account is provisioned. Sessions expire after 8 hours (30 minutes idle), and destructive actions require fresh re-authentication. |
| Edge | A web application firewall with OWASP rulesets and US-only geo restriction fronts the application; backend services are not directly reachable from the internet. Your data is stored in US regions. |
| Ingest | Every uploaded file passes a malware scan gate before any processing touches it. |
| Our own access | No ChargeStack employee holds standing access to production infrastructure. Access is time-boxed, break-glass, and audited — the same "receipts, every time" standard we apply to your data. |
What we mean by "literally cannot read"
Every column in our database is classified into one of three tiers. Ops staff get Tier 0 by default; Tier 1 visibility is governed by your organization's privacy posture; Tier 2 only with a customer-issued grant — never as a default, never as an "emergency override."
| Tier | What it covers | Default visibility |
|---|---|---|
| 0 Structural | IDs, timestamps, counts, sizes, status enums, error codes — never derived from your input. | Visible |
| 1 Sensitive metadata | Case names, case numbers, court names, filenames, folder skeletons, org names. | Visible to ops by default, with every read audited. For criminal-justice orgs this is true today as well — runtime gating of Tier 1 is in development. See Criminal-justice mode below for the plain statement of where that stands. |
| 2 Content | Case descriptions, document text, AI extractions and analyses, conversation messages, agent artifacts, embeddings, free-text error messages. | Always blocked without an active debug grant. |
When an ops query selects a Tier 2 column, our data-access layer
refuses to execute it and raises
OpsForbiddenColumnError before the query ever reaches
the database. The check runs on every query the ops session issues —
including queries the ORM generates implicitly, not just the ones we
wrote by hand — and it is pinned by unit tests, so it cannot be
removed quietly.
A fair question at this point: what about access that bypasses the application entirely? That path is closed a different way. No ChargeStack employee holds standing access to the production database — reaching it directly requires a break-glass grant that is time-boxed and audited. And the most sensitive content columns are envelope-encrypted with your organization's key, so a raw read returns ciphertext, not case content. The gate, the access model, and the encryption are three separate layers; a reviewer should evaluate them together.
Debug grants
When support needs deeper access — to diagnose a specific case, say — they request a grant from inside the ops console. You see the request in your Privacy & Audit panel: who's asking, what case, what tier, why. You choose the duration (up to your org's configured maximum) and approve. Or reject.
Grants are scoped to a single case by default. They expire automatically on a clock you set. You can revoke at any moment — revocation takes effect on the very next query.
The audit trail
Every /ops_admin/* request — including pure-metadata
ones like "list this org's billing rollup" — writes a row to your
org's audit log. The row records who, when,
which tables they touched, the maximum tier they read, and
the grant ID under which they read (if any). You see this in your
Privacy & Audit panel.
For criminal-justice orgs, your Privacy & Audit panel additionally shows a daily access digest — even when zero access happened. The "zero access today" entry is itself the trust signal.
Criminal-justice mode
Police agencies, prosecutors, public defenders, and government investigative offices are onboarded in CJ mode. The designation is set when we provision the organization — and since there is no self-serve signup, there is no path onto the platform that skips it. In this mode:
- The privacy posture is locked at maximum at provisioning. No support or admin staff can change it; relaxing it requires an explicit action by a ChargeStack owner — in practice only after a written request from your agency — and that change itself writes an audit row with a recorded reason.
- The org's display name in our ops console is the UUID, not the chosen name — so the org name itself doesn't reveal patterns.
- To be plain about where Tier 1 stands today: sensitive metadata — case names, case numbers, court names, filenames — is currently visible to our ops staff for CJ orgs, with every read written to your audit log and surfaced in your daily digest. Runtime per-case gating of Tier 1 is in development as the next hardening phase; until it ships, the audit trail is the control, and we would rather tell you that than imply otherwise.
Legal compulsion
If we receive a subpoena, search warrant, or court order, we follow a separate code path with its own audit trail. Two ChargeStack signers must approve before any data is exported, and the second signer must re-authenticate to do so. You receive notification within 24 hours unless we are served a gag order alongside.
We commit to publishing a quarterly transparency report — counts by category (subpoena, search warrant, court order, NSL). The goal is that every count stays zero; if it doesn't, you'll know.
CJIS alignment
ChargeStack's controls are mapped to the FBI CJIS Security Policy v6.0 — access control, auditing, encryption, identification & authentication, and incident response — and every intentional deviation is documented alongside its compensating control. We do not claim CJIS certification: no vendor can self-certify, and accountability always rests with the agency. A plain-language compliance summary is available on request to security@chargestack.ai.
Verifying our claims
This page is the customer-facing summary. An implementation reference for engineers, auditors, and security reviewers — mapping each guarantee on this page to specific code, the SQLAlchemy event hook, and the unit tests that verify the gate — is available on request. So is our full control matrix, which covers the topics a procurement review asks about next: encryption in transit and at rest, backups and disaster recovery, vulnerability management, personnel screening, subprocessors, data retention and deletion at offboarding, and breach notification.
Procurement, security review, or audit liaison: security@chargestack.ai. We respond within one business day.
Last updated: 2026-08-14.