Zero-retention architecture. Tamper-evident evidence.
Our evidence has to survive your audit firm's scrutiny — so our security has to survive your security team's.
Déjà never stores your source code, cannot alter receipts after issuance, and produces evidence that verifies offline forever — independent of whether Déjà continues to exist. This page documents the posture; everything your security team needs is requestable below, no sales gate.
We never store your source code.
Déjà reads transient webhook payloads at merge time and incident time. The engine extracts symbolic fingerprints and causal relationships — then discards the underlying content. If an attacker compromised Déjà's infrastructure tomorrow, they could not reconstruct your codebase, because the underlying code was never persisted.
In · transient
Webhook payloads — PR diffs at merge, error payloads at incident. Held in memory for analysis only.
Kept · symbolic
Fingerprints & causal relationships — SHA-256 incident fingerprints, schema signatures, producer-graph edges, PR metadata (number, author, files touched — never contents).
Discarded
The payload itself. No repository clones, no historical file reads, no runtime data access, no code contents at rest — ever.
What this means in a breach scenario: the most sensitive thing Déjà holds about your code is that a file named in PR-4611 changed a message schema — not what any line of it says.
Receipts that can't be altered after issuance.
Every signed receipt carries an Ed25519 signature computed at issuance over the JCS-canonicalized envelope. We can't modify the receipt after issuance — including us. Auditors verify receipts offline using the open dsr-verifier-cli — no Déjà account required (early access today · public release Q3 2026; audit firms receive the verifier during engagement).
Signature set at issuance
The Ed25519 signature is computed over the canonicalized envelope the instant the receipt is created. Any later change to any field — by us, by you, by an attacker — fails verification.
Append-only ledger
Receipts are written to a hash-linked, append-only chain rooted at your vault's genesis receipt. Altering one historical receipt breaks the hash of every receipt after it — tampering is arithmetically loud.
Verification never touches us
The verifier checks signatures against published keys, offline, on the auditor's machine. Déjà's API, uptime, and honesty are all out of the trust path at verification time.
Your copy is yours
Export your full ledger anytime — portable JSON, with PDF bundles for human readers. Exports verify with the same CLI, forever, with or without a subscription.
If Déjà has its worst day, your evidence doesn't.
Most vendor security pages argue a breach won't happen. This architecture is built for a harder standard: even a successful compromise of Déjà cannot forge or invalidate your receipts.
01 · Forgery fails
A forged receipt fails offline verification
Receipts verify against published signing keys on the auditor's own machine. An attacker inside our infrastructure could emit garbage — and every piece of it would fail your audit firm's verifier.
02 · History can't be rewritten
The chain makes tampering loud
Altering any historical receipt breaks the hash of every receipt issued after it — detectable by anyone holding any later receipt, including the copy your audit firm already exported.
03 · Your evidence outlives us
Receipts verify even if Déjà disappears
Exports are portable and the verifier is open source. Acquisition, shutdown, or compromise — your evidence remains valid, because its validity never depended on us.
How your data is handled.
Cryptographic tenant separation
Every customer has an isolated vault. Cross-tenant access is structurally impossible — separation is enforced at the data layer, not by application logic alone.
one vault · one ledger · one key lineage
Encrypted everywhere
AES-256 at rest with managed key rotation; TLS 1.3 in transit, enforced. No plaintext paths.
at rest: AES-256 · in transit: TLS 1.3
Residency you choose
US region live. EU and APAC regions targeted H2 2026 — region is signed into every receipt's envelope, so residency is itself evidenced.
region: in the envelope · permanent
You own when data leaves
Cancellation triggers export then destruction on your schedule. No retention beyond your instruction beyond legal minimums, which are documented in the DPA.
export → destroy · on your instruction
Portable, forever verifiable
Full-ledger export anytime: portable JSON + PDF bundles, verifiable offline with the open CLI. Leaving is a supported workflow, not a support ticket.
export: self-serve · verify: offline
Access on the record
Administrative access to customer vaults is logged, least-privilege, and reviewable — the audit trail applies to us too.
admin access: logged · reviewable
Departure is signed too.
When you leave, the destruction itself produces evidence: after your final export, data destruction is executed and a signed destruction receipt is issued into your exported ledger — cryptographic confirmation of what was destroyed and when. Even leaving Déjà produces a verifiable record. Your compliance team can evidence the offboarding the same way they evidenced everything else.
Who can reach your data — and what happens if something goes wrong.
Authentication and least-privilege access
- ✓SSO / SAML 2.0 on Standard and above; MFA mandatory for all accounts, including delegated connector invites
- ✓Role separation — admin, member, auditor roles with distinct permission sets; auditor seats are read-and-verify only
- ✓Audit logging — every admin and auditor action generates a governance log entry; logs are exportable with your evidence
- ✓Session management — configurable session timeout, device review, forced sign-out
If something goes wrong
- ✓24/7 on-call security rotation with defined severity tiers and response targets (documented in the architecture pack)
- ✓Customer notification without undue delay for incidents affecting your data, with a written timeline commitment in the DPA
- ✓Public disclosure policy — incidents affecting evidence integrity are disclosed, full stop; our credibility is the product
- ✓Responsible disclosure — security@deja.dev for researchers; reports acknowledged within one business day
Where we are, where we're going.
Same discipline as everywhere else on this site: what holds today is checkable; what doesn't yet is labeled a target, not a fact.
GDPR & CCPA alignment
DPA available on request; data-subject and deletion workflows implemented — including signed destruction receipts.
Penetration testing
Independent third-party test; executive summary available under NDA via security review.
Open verification
DSR/1.0 spec public; dsr-verifier-cli in early access (public Q3 2026) — the verification layer is inspectable, not trusted.
SOC 2 — Type I, then Type II
Type I targeted Q3 2026; Type II follows its observation window. Reports to customers under NDA on completion.
ISO 27001
Certification program planned alongside Enterprise general availability.
Regime-specific needs
HIPAA BAAs and other regime-specific arrangements are handled per engagement — raise them in a security review.
What you won't find here: a wall of logos for programs we haven't started. We list only work with an active workstream behind it — a shorter wall that's all true.
Every vendor that could see your data.
30-day advance notice before any subprocessor is added or changed — customers are notified in writing, and material changes can be objected to under the DPA. The list below is complete as of June 2026.
| Vendor | Purpose | What it can see | Region |
|---|---|---|---|
| Amazon Web Services | Cloud infrastructure — compute, storage, KMS | Encrypted vault data (AES-256 at rest) | US· EU/APAC H2 2026 |
| Supabase | Managed Postgres + authentication | Vault metadata, account records | US |
| Vercel | Application hosting + edge delivery | Application traffic in transit (TLS 1.3) | US edge |
| Stripe | Billing and payments | Billing contact + payment data — never vault contents | US |
| Resend | Transactional email + email delivery channel (when configured by Customer) | Email addresses, notification contents, recipient receipt metadata | US |
| Datadog | Infrastructure monitoring | Operational telemetry only — no vault contents | US |
| PagerDuty | On-call alerting for Déjà's own team | Alert metadata only | US |
| Slack Technologies | Outbound receipt delivery (when configured by Customer) | Abstracted receipt metadata — no customer payloads or vault contents | US |
Customer-directed delivery (not a subprocessor change). Déjà supports outbound delivery of signed receipts to customer-operated destinations — including outbound webhooks and ServiceNow instances — at the customer's direction. These destinations are controlled entirely by the customer and are not Déjà subprocessors; no Déjà DPA amendment is required. When ServiceNow delivery is enabled, Déjà connects to the customer's own ServiceNow instance using a least-privilege OAuth client credential scoped to read incidents and write work notes and attachments. No incident state is changed; the only writes are a work note and a signed receipt attachment. OAuth tokens are AES-256-GCM encrypted at rest and are never logged.
Splunk On-Call alerting source (customer-directed, not a subprocessor). When the Splunk On-Call alerting source is enabled, Déjà receives inbound webhooks from the customer's Splunk On-Call org and calls the Splunk On-Call REST API read-only (GET only) using the customer's own API credentials to confirm each webhook before recording it. Every webhook is confirmed against the Splunk On-Call API before it is believed — unconfirmed webhooks are discarded and logged, never used. Déjà never acknowledges, resolves, reroutes, or creates incidents, and never pages anyone. API credentials are AES-256-GCM encrypted at rest, redacted in all logs, and are never returned after the initial connect step. Because the customer's own credentials are used to access the customer's own Splunk On-Call org, Splunk On-Call is not a Déjà subprocessor and no DPA amendment is required.
Request what your security team needs.
Public documents are public. NDA-gated documents come through a security review — a direct exchange with our team, not a qualification funnel.
DSR/1.0 specification
The receipt format, signing scheme, and verification procedure — the category's foundation document.
Subprocessor list
The table above — also available as a signed document for vendor-management systems.
Data Processing Agreement
GDPR-aligned DPA including notification timelines and destruction commitments.
Architecture documentation
Zero-retention pipeline, key management, tenant separation — the engineering detail behind this page.
SOC 2 Type I report
Available to customers under NDA on completion; Type II follows its observation window.
Disclosure policy
How incidents are classified, disclosed, and communicated to affected customers.
Looking for the mechanism or the argument? The deterministic engine and receipt lifecycle live on How it works; the validation gates and category claim live on Why Déjà. This page's job is posture — documented, requestable, and held to the same standard as the receipts.
How it works →Why Déjà →Security is our product.
Déjà's job is to produce cryptographically signed audit evidence for regulated industries. If our own posture couldn't withstand the same scrutiny, the product wouldn't be worth shipping. Your security team's questions deserve direct answers — not sales gates.