Security & trust · posture and dependencies

Every claim here, and what it rests on.

Our evidence has to survive your audit firm's scrutiny, so this page has to survive your security team's. Most vendor security pages are a list of assertions. This one states each assertion next to the thing it actually depends on — including the ones we haven't finished yet.

Request a security review Jump to documents

Posture register

Reviewed 2026-09-22

Established: 6
In progress: 2
Not claimed: 4

What we assert	What it rests on	Status	How you check it
Your repositories are never cloned	Déjà reads pull requests through the GitHub App and reads no file outside a pull request's diff; it keeps each diff, secrets scrubbed, as attribution evidence	Established	Architecture pack under NDA; the extracted fields are listed in the DSR/1.0 spec
A signed receipt cannot be altered without detection	A signature computed at issuance over the canonicalised envelope — Ed25519 on Déjà's managed key, RSA-PSS or ECDSA on a vault's own KMS key	Established	Change a signed field of a receipt in an exported evidence bundle and re-run the CLI — verification fails. Files the bundle's manifest does not list, such as README.md, are not covered
Verification never touches Déjà	Open CLI, published keys, no network calls at verification time	Established	Run the verifier with networking disabled
Every vault is separated at the data layer	Row-level policies — not application logic alone. Signing keys are not per vault: Déjà-managed vaults share one, and only a vault on its own KMS key has its own	Established	Reviewable in the architecture pack; testable in your own trial
Administrative access is on the record	Administrative actions write governance receipts into your own ledger. Where an integration secret can be displayed back to you at all — today that is one integration, Sentry APM's webhook secret — revealing it writes one of those receipts naming who and when	Established	Query your governance receipts; ours appear alongside yours
Signing key history is published	Déjà's managed key and any key it has retired, served without authentication, each with the dates it entered and left service, or null where a date was not recorded. For vaults on their own KMS key, Déjà publishes the current public key of at most one such vault per organisation and no key that has been rotated out, so any other key an auditor needs comes from the customer.	Established	Fetch /api/public/signing-keys and check a receipt against the key whose window contains its issue time
Rewriting ledger history is detectable	Hash-chained receipts, an append-only database constraint, and any copy your auditor has already exported	In progress	Read the threat model below — we set out exactly what each layer does and does not defend
Independent penetration testing	Third-party engagement. [Awaiting owner: pen-test firm, dates, and whether a summary is shared]	In progress	Ask in a security review for the current stage rather than a summary that doesn't exist yet
Leaving produces a signed destruction receipt	Would require the deletion path to issue a receipt into the exported ledger. The retention tables and the design exist; the code path that issues it is not wired	Not claimed	Export is self-serve and real today. Ask us to demonstrate destruction during a trial, and hold us to what you see rather than to this row
Issuance time is externally anchored	Would require each receipt to be time-stamped as it is issued. Today DigiCert's public time-stamp authority (RFC 3161) stamps each company's ledger checkpoint about once a day, which proves a receipt existed by then, not when it was issued	Not claimed	Issuance time is asserted by us. If your control depends on independent time, raise it before the trial
A completed SOC 2 or ISO 27001 attestation	SOC 2 Type I in preparation, Type II follows its observation window; ISO 27001 planned	Not claimed	Ask for the control narrative and current gap list. [Awaiting owner: whether SIG Lite, CAIQ and the control narrative exist as documents]
Compromise of our signing key cannot forge receipts	Would require key custody outside the environment an attacker would already hold	Not claimed	Read the key custody section — the honest answer and the compensating controls are there

A row moves left only when it can be demonstrated. Rows have moved right before, and will again — the destruction-receipt row moved right in the same change that published this page.

Enterprise controls

The controls your identity and security teams ask for.

Each one as the product does it today, with the plans that have it.

SAML single sign-on: With Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, PingIdentity, JumpCloud or any SAML 2.0 identity provider. The setup marks PingIdentity and JumpCloud as beta.; Plans · Standard, Charter, Enterprise and Sovereign
OpenID Connect sign-in: With Auth0, Okta or any OpenID Connect (OIDC) provider.; Plans · Standard, Charter, Enterprise and Sovereign
SCIM 2.0 provisioning: Your identity provider adds, updates and suspends members through SCIM 2.0, with a token Déjà issues. Removing a member stays on the Team page. Each change to the token is a governance receipt.; Plans · Standard, Charter, Enterprise and Sovereign
Multi-factor authentication, required: Required on every paid plan. Members get 14 days to enrol; after that, sign-in and changes are refused until they do. An Owner can accept an identity provider's own MFA for sign-ins through it.; Plans · Standard, Charter, Enterprise and Sovereign
Custom roles: Create and assign custom roles on Charter, Enterprise and Sovereign. Standard uses the built-in roles.; Plans · Charter, Enterprise and Sovereign
Déjà staff access, approved by you: A Déjà staff member asks to read your organisation's activity for 1 to 24 hours, and only an Owner can approve, decline or end it. Every read under an access is listed, with 90 days exportable as CSV for your auditors.; Plans · Every plan
Audit log streamed to your SIEM: Your organisation's audit log is posted to an HTTPS address you choose. Each POST carries an HMAC-SHA256 Deja-Signature header, and adding, resuming or re-keying a stream is a governance receipt.; Plans · Every plan
Sign out everyone: An Owner can end every session of every member at once, their own current session excepted. It is a governance receipt.; Plans · Every plan
Scoped, expiring API keys: Each key reaches one vault or the whole organisation, carries the scopes it was given, and expires after 30, 90, 180 or 365 days. Owners and Admins make and revoke them.; Plans · Every plan
Your own signing key (BYOK): On Enterprise and Sovereign, a vault can sign with your AWS KMS key. Azure Key Vault and GCP KMS are not implemented.; Plans · Enterprise and Sovereign

Data minimisation

We never clone your repositories.

Déjà reads webhook payloads at merge time and at incident time. It keeps each merged pull request's metadata and the diff of every changed file, with secrets scrubbed before anything is written, and the error events your monitoring sends, because those are what a receipt's attribution rests on. It never clones a repository, never reads a file outside a pull request's diff, and never writes to your code.

In · at merge and incident

Webhook payloads

Merged pull requests with their diffs, and error events as your monitoring sends them.

Kept · as evidence

What a receipt rests on

Each pull request's metadata and diff, secrets scrubbed, including up to two years of past pull requests; error events with their stack traces and tags; SHA-256 incident fingerprints, schema signatures, producer-graph edges.

Never

Your repositories

No clones, no reads of files outside a pull request's diff, no writes.

What that means in a breach: the most sensitive thing Déjà holds about your code is the diffs of your merged pull requests, secrets scrubbed, and the stack traces in your error events — the lines that changed or failed, not your repositories.

Threat model

If Déjà has its worst day, what actually holds?

Most security pages argue a breach won't happen. That's not a claim anyone can keep. The useful question is what survives one — and the answer differs by scenario, so we set out all three rather than the flattering one.

Scenario one

An attacker reads our infrastructure

They can read the stored pull-request diffs and error events, and which schemas those changes touched. They cannot take your repositories from us, because we never cloned them. Vault data is AES-256 encrypted at rest.

partly holds · diffs are kept

Scenario two

An attacker alters the database without the signing key

Every modified receipt fails signature verification on your auditor's machine. Alteration is detectable by anyone holding a later copy — which is the point of exporting bundles.

holds · by signature

Scenario three

An attacker obtains the signing key

Then they can produce receipts that verify. No signature scheme survives key compromise — ours included, and any vendor claiming otherwise is describing a different product.

does not hold · compensating controls below

why

Why we state scenario three plainly

A page claiming that no compromise could forge or invalidate your receipts is claiming key custody stronger than the infrastructure the keys live in. Déjà's managed signing key is held as an encrypted secret in our hosting environment, not in a KMS, and is rotated by hand rather than on a schedule; only a vault on its own key signs in AWS KMS. An attacker who fully owned our environment would be inside the trust boundary. Pretending otherwise would be exactly the kind of unverifiable vendor assertion this product exists to replace.

Your auditor's copy is the strongest control

An exported bundle held outside our infrastructure cannot be retroactively rewritten by anyone who compromises us. A later export that disagrees with an earlier one is itself the detection. We recommend audit firms retain their bundles for exactly this reason, and it costs nothing.

Key history is published

Déjà's signing keys are published with the period each was in service, and our own verifiers, /verify and /verify-bundle, accept a key only for a receipt or bundle dated inside that period, so a retired key cannot vouch for anything dated after it was retired. A date we did not record is published as null; where that is a retired key's retirement date, those verifiers decline to vouch for the key rather than assume. The CLI checks against whichever key you give it: pick the one whose period contains the issue date. A key that appears without a corresponding rotation record is a signal in itself.

What would close the gap, and hasn't yet

External anchoring of the chain head started on 26 October 2026: about once a day each company's ledger checkpoint is time-stamped by DigiCert's public time-stamp authority (RFC 3161), and the token comes with each receipt's proof. A checkpoint rebuilt later has different bytes and does not match a token anyone already holds, and the key alone cannot make a new one with an earlier time. What it does not close: a receipt's own issue time is still Déjà's clock, receipts issued since the last stamp are covered only from the next one, and DigiCert does not publish what it stamped, so the check rests on someone keeping the tokens. Publishing the chain head somewhere we don't control would close that last part, and it is not implemented.

Handling · at a glance

At rest: AES-256 with managed key rotation
In transit: TLS 1.2 or higher, and TLS 1.3 where the client supports it; no plaintext paths
Isolation: One vault · one ledger · row-level policies. Tenancy is row-level in a shared database. Déjà-managed vaults share one signing key; a vault on its own KMS key has its own. A dedicated deployment: [Awaiting owner: whether a dedicated deployment is offered, and what it means]
Residency: US only. The region a vault was established in is written into its genesis receipt, so the region is on record from the vault's first link
Retention: Two years on Charter, five on Standard, custom above. Governance entries are kept for the life of the vault and are never trimmed on a schedule, because each one chains to the one before it
Ingestion: No repository clones, no reads of files outside a pull request's diff, no runtime access, no agent in your environment
Writes: Where you configure a destination: a Slack message, a ticket, or a ServiceNow record or work note with the signed receipt attached. And in two places besides: an event into Honeycomb when an incident is resolved (on by default), and ServiceNow incidents if you turn on incident sync
Network: No inbound listener into your network and nothing running in your runtime. Outbound connections go only to endpoints you named

Data handling

What Déjà can write into your tools is short, and listed.

The blast radius of a Déjà compromise is bounded by the credentials you connect with: what they let an attacker read, and the writes listed on this page. There is no path from Déjà into your runtime — no approvals, no remediation, no agent — and each write says whether it is on by default.

Where you configure a delivery destination, Déjà writes to it, because that is what you configured it for: a Slack message, a ticket, or a work note on a ServiceNow incident with the signed receipt attached. It also writes in two places besides. When an incident is resolved in Déjà, it posts an event into Honeycomb if Honeycomb is connected. That is on by default, and disconnecting Honeycomb stops it. If you turn on ServiceNow incident sync, which is off by default, Déjà also creates and updates incidents in your ServiceNow instance. It is worth saying plainly rather than claiming a blanket that the code would contradict.

Connector credentials are encrypted at rest with AES-256-GCM, redacted in logs, and never returned after the connect step. Where one can be displayed back to you at all, that reveal writes a governance receipt naming who viewed it and when. Inbound webhook secrets are stored so they can be re-displayed, which is standard for webhook verification; the trade-off is documented rather than left implicit, and forging an inbound webhook injects a false signal — it does not forge a receipt.

Where a connector permits it, we confirm before we believe: inbound alerts from Splunk On-Call are checked read-only against that vendor's own API using your credentials before anything is recorded. Unconfirmed webhooks are discarded and logged, never used.

Departure

Leaving is a supported workflow.

Receipt export is self-serve. The ledger export takes up to 2,500 receipts at a time and leaves out RV and RE receipts. Each receipt in it is a signed file dsr-verifier-cli checks on its own, except an R0, R2-F or R2-R issued before those types were signed, which is sealed by a content hash and listed in checked-online.json for deja.dev/verify to check; the bundle the CLI checks as a whole is the period report of an audit engagement. That bundle verifies offline with the same CLI, with or without a subscription, and you can generate one today.

What is not built yet is the receipt for the destruction itself. The design is export, then destruction on your schedule, with a signed receipt issued into your exported ledger so the offboarding is evidenced the same way everything else is. Cancelling the plan starts neither. The tables exist; the code path that issues that receipt does not. It is on the register above as not claimed, and it stays there until a customer can watch it happen.

One consequence worth stating: because signed organisations carry immutability protections, deletion is deliberately harder than creation. It requires an explicit authorised retention action rather than a single click — which is correct for an evidence product, and occasionally inconvenient. We'd rather it be that way round.

Access and identity

Auth: SSO with SAML 2.0 or OIDC on every paid tier, Charter included · MFA required on every paid tier: a member has 14 days to set it up, after which Déjà asks for it before anything else; an Owner can accept your identity provider's MFA in its place · SCIM 2.0 user provisioning
Roles: Owner, Admin, Compliance Lead, Member, Viewer and Auditor, with distinct permission sets; one Owner is the Primary Owner. An external auditor's access is not one of these roles — it is granted per engagement, scoped and signed, and is read-and-verify only · custom roles on Charter, Enterprise and Sovereign
Logging: Administrative actions write a governance entry, exportable with your evidence
Sessions: Session length set per deployment (8 hours by default), device review, sign out everyone
Disclosure: security@deja.dev · researcher reports acknowledged within one business day
Incidents: Anything affecting evidence integrity is disclosed. Notification timelines are written into the DPA

Attestations

Where we are, where we're going.

Same discipline as everywhere else on this site: what holds today is checkable, and what doesn't yet is labelled a target rather than a fact.

Holds today

GDPR and CCPA alignment

DPA text published, countersigned copy on request; data-subject and deletion workflows implemented. Export is self-serve; the signed destruction receipt is on the register above as not yet claimed.

continuous · active

Holds today

Offline verification

DSR/1.0 specification public; the verifier runs without a Déjà account, and v1.7.2 is publicly released.

continuous · active

Holds today

Governance receipts on our own access

Administrative actions against customer vaults write receipts into the customer's own ledger. The audit trail applies to us too.

continuous · active

Target

SOC 2 — Type I, then Type II

Type I in preparation [Awaiting owner: SOC 2 Type I target date, or none]; Type II follows its observation window. Reports to customers under NDA on completion.

in progress · not complete

Target

Independent penetration test

Engagement in progress. [Awaiting owner: pen-test firm, dates, and whether a summary is shared]

in progress · no report yet

Planned

ISO 27001

Certification programme planned alongside Enterprise general availability. HIPAA business associate agreement: [Awaiting owner: whether Déjà signs a HIPAA business associate agreement (BAA)]

2027 · planned

What you won't find here: a wall of logos for programmes we haven't started. We list only work with an active workstream behind it — a shorter wall that's all true.

Subprocessors

Every vendor that could see your data.

Thirty days' advance written notice before any subprocessor is added or changed, with a right to object under the DPA.

Vendor	Purpose	What it can see	Region
Supabase	Managed Postgres + authentication. Runs on Amazon Web Services — via Supabase, which contracts with AWS; Déjà has no AWS account	Déjà's database — vault data, receipts and account records, encrypted at rest	US
Vercel	Application hosting + edge delivery	Application traffic in transit (TLS 1.2 or higher, and TLS 1.3 where the client supports it)	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
Sentry	Error tracking for Déjà's own application	Exception type, message, stack trace and deployment metadata. Not request bodies, headers or user identifiers; no session recordings	Unconfirmed
PagerDuty	On-call alerting for Déjà's own team	Alert metadata only	US
PostHog	Product analytics for Déjà's own application	Page views, clicks and in-app events, and a signed-in user's ID, name and email	US
Anthropic	Claude in Déjà Help: answering and sorting support cases, and drafting fixes for a Déjà engineer to review	A support case's words and error details, with known secret formats removed first; and one vault's frameworks and delivery settings, only while an Owner allows it for that case	Unconfirmed
Slack Technologies	Déjà's own operational alerts and inbound charter applications	Alert metadata; the name, email, firm and role a charter applicant submits — no vault contents	US

Customer-directed delivery is not a subprocessor change. Déjà can deliver signed receipts to destinations you operate — outbound webhooks, your own ServiceNow instance — at your direction. Those destinations are controlled entirely by you and require no DPA amendment. Where ServiceNow delivery is enabled, Déjà uses a least-privilege OAuth credential scoped to read incidents and write a work note plus a signed attachment. That delivery changes no incident's state; ServiceNow incident sync is separate, off unless you turn it on, and does create and update incidents.

Documents

Public things are public.

Nothing below sits behind a qualification form. Public documents are linked directly; NDA-gated documents come through a direct exchange with our team, which is a conversation rather than a funnel.

Public

DSR/1.0 specification

Receipt format, signing scheme and verification procedure — the foundation document.

Read →

Public

Data handling, retention and data-subject rights in plain language.

Read →

Public

Subprocessor list

The table above, also available as a document for vendor-management systems, on request.

Read →

Public

Verifier CLI

The tool your audit firm runs: Apache-2.0, no account required. v1.7.2 is publicly released, with signed checksums.

About it →

Public

Data Processing Agreement

GDPR-aligned, including notification timelines and destruction commitments. The text is published; a countersigned copy is on request.

Read →

Under NDA

Architecture documentation

Data-minimisation pipeline, key management and tenant separation — the engineering detail behind this page.

Request →

Not confirmed

Security questionnaire

SIG Lite and CAIQ responses for your vendor-review process. [Awaiting owner: whether SIG Lite, CAIQ and the control narrative exist as documents]

Ask about it →

Not yet

SOC 2 Type I report

Available to customers under NDA on completion. In the meantime, the control narrative and gap list: [Awaiting owner: whether SIG Lite, CAIQ and the control narrative exist as documents]

Ask about it →

Looking for the mechanism or the argument instead? The path a signal takes lives on How it works; the case and its limits live on Compare. This page's job is posture.

Security is the product.

Déjà's job is producing evidence that a regulated firm can hand to someone who trusts nobody. If our own posture couldn't take the same scrutiny, the product wouldn't be worth shipping — and the fastest way to find a hole in it is to send us your security team.

Request a security review Read the changelog

Déjà supplies a record of what connected systems reported and what changed. It does not determine root cause, file regulatory reports, or discharge any obligation under DORA, 23 NYCRR Part 500 or any other regime — those remain with your named accountable individuals. "Sealed" means written into an append-only chain with a content hash when the receipt is issued; "signed" is used only where a receipt additionally carries a signature — Ed25519 on Déjà's managed key, RSA-PSS or ECDSA on a vault's own KMS key. Every receipt type is signed today; the R0, R2-F, R2-R receipts issued before 27 October 2026 carry the content hash alone, and the bundle states which is which per receipt. A receipt's issue time comes from Déjà's own clock. What an outside party vouches for comes later: about once a day a company's new receipts go into a signed ledger checkpoint, which DigiCert's public time-stamp authority (RFC 3161) then stamps. That proves a receipt existed by the stamped time, not when it was issued.