Security
ShiftGraph watches the third-party APIs your software depends on. Doing that well means handling as little of your data as the job allows, and then proving the limit rather than promising it.
This page is the security summary our Data Processing Addendum offers on request. Everything below describes a control that is in the product now.
Values never leave your process
The recorder that runs inside your application replaces every value in a response with a typed placeholder before anything is transmitted. A string becomes a marker that says “string”. A number becomes a marker that says “number”. What travels to us is the shape of the response: field names, types, nullability, nesting. The amount on a charge, the address on a customer, the text of a message: none of it is ever sent, because none of it survives the step before sending.
That guarantee is not left to the client to honor. Our ingest endpoint independently validates every batch and refuses any that still carries a real value, returning the exact path that offended so you can fix the recorder. A refused batch is not stored in any form. This is the reason the promise is worth something: a bug in your integration, or a deliberately modified client, cannot put values into our database, because the door checks.
Uploaded captures work the same way and go further. A file you upload is parsed in memory and reduced to structure; the file itself is never written to storage. There is no retention window on it because there is no copy to retain.
Tenancy is enforced by the database
Every table carries row-level security in its forced form, and each request runs under an identity the database itself checks. A query that forgot its workspace filter returns nothing rather than someone else’s rows, because the filter is not in the query. This is deliberate: application code is where tenancy bugs live, so tenancy is not implemented in application code.
The application connects through four separate database roles with different privileges: one for the request path, one for background work, one that owns schema changes, and one that owns the few functions permitted to touch secret material. The request path holds no privilege on any column containing a secret. Reading one does not return a filtered result; it raises an error.
By default, no one here can read your data
Support access is off until you grant it. A grant is read-only, expires on its own, can be revoked by you instantly, and is recorded in your audit log. While a grant is active the secret columns stay unreadable, so even granted access cannot expose credentials.
Our own test suite includes a probe that attempts to read customer data as the operator and fails if it succeeds. The claim on this page is therefore checked on every build rather than asserted once.
Accounts and sessions
A second factor is required of every account, with no plan or role that skips it. You may use a passkey or an authenticator app. Recovery codes exist for a lost device and are single use.
Passwords are hashed with Argon2id and a server-held secret, and are checked against public breach corpora at the moment they are set, using a method that never transmits the password. Sessions are short-lived and refreshed; a refresh token that is presented twice is treated as theft and every session on the account is revoked. Sign-in failures slow the endpoint progressively rather than merely counting.
Organizations on the Enterprise plan can require single sign-on, restrict access to named networks, shorten the maximum session age, and provision members automatically. The network restriction refuses to save a list that would exclude the administrator setting it.
An audit log that cannot be quietly edited
Security-relevant actions are appended to a hash-chained log: each entry commits to the one before it, so a removed or altered entry breaks the chain and is detectable. The log is append-only by design, and administrators can read and export it. Retention purges and deletions write their own entries, with counts, so what was removed is itself part of the record.
The network boundary
Every page is served with a per-request content security policy and a strict transport policy, and state-changing requests are checked at two independent layers before they reach application code.
Where you ask us to call a URL you control, such as a webhook, the address is resolved once and that single resolution is used both for the safety check and for the connection itself, so an address cannot be checked as safe and then swapped for a private one. Private, loopback, link-local, and cloud-metadata ranges are refused.
What the cross-company network can and cannot see
Early warning works by comparing contract-change signatures across organizations. A signature is a structural fingerprint, never a payload. It is published only after at least three independent organizations have observed the same one, and counts stay coarse below five, so a signal cannot be traced back to a single contributor.
The table holding published signals is tenant-free at the schema level, and the table that would connect a signal to a contributor carries no privilege for the request path at all: the application physically cannot perform that join. Contribution is a setting you control, and turning it off deletes the contributions you have already made and recounts the aggregates they supported, at the moment you click.
Retention, export, and deletion
Drift events and their evidence are purged automatically past your plan’s retention window, or past the window your order specifies. Purges are recorded with counts.
You can export a portable copy of your workspace at any time, on any plan, because access to your own data is a right rather than a feature. Deleting a workspace soft-deletes it first, leaving a window in which an owner can restore it, and then removes it and everything attached to it. Cancelling gives you thirty days of read-only access to export, after which the same deletion path runs. The full timetable is in the DPA and the Privacy Policy.
How changes reach production
Every change runs a gate before it can ship: type checking, unit tests, a security suite executed against a real database rather than a mock, a production build, a scan of the built client bundle for anything secret, and a repository-wide secret scan. A new endpoint that fails to declare its authorization is failed by the suite automatically, so the protection is the default rather than something a reviewer has to notice.
The recorder and the command line tool are published as open source, so the component that runs inside your application, and therefore the value-free claim itself, is code you can read rather than a promise you have to take.
Vendors
We keep the list of every vendor that processes anything on our subprocessors page, and we give at least thirty days’ notice before adding or replacing one, with a right to object. Data is hosted in the United States. Traffic is encrypted in transit, and our database and object storage providers encrypt data at rest.
Reporting a vulnerability
Write to security@shiftgraph.dev. Our security.txt carries the same address. Tell us what you found and how to reproduce it, and please give us a reasonable window to fix it before publishing. We will confirm receipt, keep you updated, and credit you if you would like to be credited. We do not currently run a paid bounty.
What we do not have yet
A security page that lists only strengths is not useful to the person reading it to make a decision, so this is the rest of the picture.
No SOC 2 report. We hold no SOC 2, ISO 27001, or equivalent third-party attestation today. We will say so on a questionnaire, and we will not describe an audit as underway before it is. What we can offer a reviewer instead is this page, the DPA with its technical and organizational measures, the open-source recorder, and direct answers to a security questionnaire.
No independent penetration test yet. The controls above are tested by our own automated suite on every build. An external test is something we intend to commission, and we will date it here when it has happened rather than before.
One region. All processing is in the United States. We do not offer data residency elsewhere, and we would rather say that than imply a choice that does not exist.
Key custody. Encryption keys are held in the deployment’s secret store rather than a dedicated key-management service with split custody. That upgrade is on our list; it is not done.
Questions, or a security questionnaire you need completed, can go to security@shiftgraph.dev. Legal questions belong at legal@shiftgraph.dev.