Claims register
Each security claim, and where it stands.
Our register gives the status of each of our 40 security claims, in each environment. This page shows one environment.
The status column is the state of our repository, not of the service we run today. Some of these controls are not yet in the build we run. The production column follows our next production verification.
Mechanism detail for findings still open in production is shared under NDA until they are fixed.
Register as of .
Status
Where the claims stand in our repository.
Each row below is a claim as we test it. Its status says how far it holds in our repository. The test count is the number of tests the register names as evidence for it.
The ledger verifier recomputes the SHA-256 chain of an execution-ledger export in your browser. The check makes no server round-trip.
- Verified
- 25 claims
- A test or a reading shows it holds.
- Partial
- 11 claims
- Part of it is shown to hold. The rest is not yet.
- Unverified
- 0 claims
- Not shown either way.
- Not true
- 3 claims
- Shown not to hold.
- Not applicable
- 1 claim
- The capability does not exist here.
Register
The claims, by family.
Other Nervos pages cite a claim by its identifier, such as AUTHZ-01. Each row here is anchored by it.
| Claim ID | Claim | Repository status | Tests named |
|---|---|---|---|
Authorization AUTHZ | |||
| AUTHZ-01 | Every write to a connected system of record is dispatched only under a server-recorded, bound, unrevoked human authorization that meets the policies' quorum of distinct approvers. | Verified | 3 |
| AUTHZ-02 | Replay cannot re-run a write that was never approved, was revoked, or whose authorization no longer binds the proposal as it stands. | Verified | 2 |
| AUTHZ-03 | A second, distinct approver is enforced when the policies require one (high risk and irreversible, or at or above the amount threshold). | Verified | 2 |
| AUTHZ-04 | A revoked authorization dispatches nothing — including a revocation recorded after the route verified it but before the send. | Verified | 1 |
Halting execution KILL | |||
| KILL-01 | Execution can be halted — for one organisation or globally — without a deployment, and a halt that cannot be read is treated as a halt. | Verified | 6 |
Separation of duties SOD | |||
| SOD-01 | An approval by the proposer on record is refused, at approval and again at dispatch. Until a pending migration is applied, a member can set who is on record. | Partial | 1 |
Roles RBAC | |||
| RBAC-01 | No member can grant themselves or anyone else a role beyond what their own role may grant, or perform through the API a governed write their role does not hold. | Partial | 11 |
Membership changes TEAM | |||
| TEAM-01 | A membership change made through the members route is made only in the remover's organisation and on the role its checks read, never leaves the organisation without an owner, and is recorded from the database's answer — never as done when it matched nothing, never unrecorded when it landed. | Partial | 13 |
Row-level security RLS | |||
| RLS-01 | Row Level Security is enabled on every table in the public schema. | Verified | 2 |
| RLS-02 | FORCE ROW LEVEL SECURITY is set on every table. | Not true | 2 |
| RLS-03 | No tenant table has a policy that admits every row (USING(true)). | Verified | 2 |
Tenant isolation TEN | |||
| TEN-01 | Tenant isolation for signed-in users is enforced by the database: every policy scopes rows to the caller's organisation (current_org_id()), never to a parameter the caller supplies. | Verified | 3 |
| TEN-02 | A request with no session (anon) cannot read tenant data. | Verified | 2 |
Ledger and history HIST | |||
| HIST-01 | Members cannot update or delete a row of the execution ledger, the audit log or verification records. Once a pending migration is applied, neither can anyone holding the service key. The database owner still can. | Partial | 5 |
| HIST-02 | Every step of an execution is recorded in a hash-chained ledger that anyone in the organisation can verify. | Verified | 2 |
Stored credentials SECRETS | |||
| SECRETS-01 | A member cannot read or replace another user's stored connector credentials or Vault secrets. | Verified | 4 |
| SECRETS-02 | Only a role that may change connector credentials stores, replaces or deletes a Vault secret, and a member is served only a secret stored in the organisation they are in. | Verified | 3 |
| SECRETS-03 | A stored credential (connector credentials, NetSuite OAuth tokens, the Slack bot token) decrypts only in the row it was written for: a copied or moved value is refused, and nothing is sent with it. | Partial | 6 |
| SECRETS-04 | A stored credential is served only in the organisation it was stored for, and a Vault secret only through the session of the person it is checked for. | Partial | 12 |
Outbound requests EGRESS | |||
| EGRESS-02 | A connector request is never sent to the server's own network — loopback, private, link-local, unspecified or cloud-metadata addresses, whether named directly or reached through a DNS answer — and never follows a redirect. | Verified | 8 |
Inbound webhooks INGEST | |||
| INGEST-01 | A NetSuite webhook event is accepted only with a valid credential inside its replay window, is recorded once, and is recorded under the one organisation it belongs to — or not at all. | Verified | 8 |
| INGEST-02 | A Stripe webhook event is accepted only when signed with the configured secret, and a blank or whitespace-only secret verifies nothing. | Verified | 4 |
Billing BILL | |||
| BILL-01 | Plan limits follow the Stripe entitlement: a subscription's tier applies only while its status entitles it — a canceled, unpaid or incomplete_expired subscription, or a status Nervos does not know, is the free plan whatever its price — the webhook stores a subscription as Stripe holds it now, never the event's snapshot, and the one-time pilot is granted only for the pilot price, once per purchase, and never for a payment that failed. | Partial | 22 |
Audit log AUD | |||
| AUD-01 | A member can write an audit row only under their own user id, and every row the server writes belongs to the organisation it concerns. | Verified | 4 |
| AUD-02 | Audit history is written by the server only: a member reads their organisation's audit log and action history and writes none of it, and what a row says (its action and detail) is chosen by server code, never by a member. | Verified | 7 |
Notifications NOTIFY | |||
| NOTIFY-01 | A notice reaches, and names, only people in the organisation of the record it concerns, and carries no error or provider text: a caught error or a provider's words go to the log under a trace id, member-chosen text is escaped and bounded for Slack, a button is only an http(s) link, and a link carrying one person's credential goes to that person alone. | Verified | 11 |
Provisioning IDP | |||
| IDP-01 | SCIM provisioning acts only in the organisation its token belongs to, admits an existing account only through a pending invitation of that organisation (consumed with the admission), never deprovisions an owner, withdraws the person's pending invitations when it deprovisions, and audits every write it makes or may have made. | Verified | 8 |
Knowledge record KNOW | |||
| KNOW-01 | A memory, a memory relationship, a claim-journal entry, a belief or a belief revision is written only by the server, in the organisation the database resolves for the caller — no member writes the knowledge record an analysis recalls from. | Verified | 9 |
| KNOW-02 | An analysis run or a prediction is written only by the server, in the organisation the database resolves for the caller, and a registered prediction is never rewritten or deleted — by a member or by the service role. | Verified | 5 |
Single dispatch IDEMP | |||
| IDEMP-01 | One approval produces at most one dispatch: a second request for the same proposal while an attempt is in flight or unresolved is refused. | Partial | 5 |
Execution outcomes EXEC | |||
| EXEC-01 | A write is recorded as executed only when the provider confirms it. A refusal, or an attempt whose outcome is not established, is recorded failed (with evidence that nothing was written) or unknown — never executed — and a write whose attempts may each have created a record is not settled on the one record a lookup names. A compensation is recorded compensated only when the provider confirms it, refused only with evidence that it did nothing, and unknown otherwise: a refused compensation is never recorded as a rollback, and one that got no conclusive answer is never reported as not reversed. | Verified | 26 |
| EXEC-02 | One person's word does not settle whether a write landed: an operator's finding about a write whose outcome is unknown settles it only when a second, distinct holder of actions:execute who is not the proposer agrees — each naming the account the write was sent to — or a provider lookup does. Until a server step that may have sent something has acted on corroborated testimony, a provider lookup outranks it — in the ledger, the proposal row and the decision record alike — and while such a step is still open the testimony moves the decision neither way. For a write whose attempts may each have written, a lookup that finds a record defeats testimony that none exists. | Verified | 63 |
| EXEC-03 | A lookup, a retry and a reversal act only in the account the write went to: the dispatch records the NetSuite account it was sent to, a provider lookup answered by another account settles nothing, a replay and a compensation are refused before anything is sent when the connection points at another account, and the idempotency cache serves a record only in the account the write would go to. | Partial | 21 |
Error handling ERR | |||
| ERR-01 | A server fault reaches the caller, the execution ledger, the audit log and the system records as a stable code and a trace id — never the database's or a provider's error text. | Partial | 27 |
Database functions DB | |||
| DB-01 | Every database function in the public schema pins its search_path, and anonymous callers may execute no SECURITY DEFINER function except current_org_id(). | Partial | 2 |
Security headers HDR | |||
| HDR-01 | Every page is served with an enforced Content-Security-Policy (not report-only), HSTS with preload, and anti-framing, anti-sniffing and cross-origin isolation headers. | Verified | 2 |
Continuous integration CI | |||
| CI-01 | CI logs are public. | Not true | 0 |
| CI-02 | Typecheck and the full test suite run on every push and pull request. | Verified | 0 |
Certification CERT | |||
| CERT-01 | A statement that Nervos holds a third-party security report, certification or authorization. | Not true | 0 |
Production verification PROD | |||
| PROD-VERIFIED | Any statement that a test has shown a control to hold in the service we run. | Not applicable | 0 |
The ledger verifier
Recompute an execution ledger in your browser.
Paste an execution-ledger export and recompute its SHA-256 chain. The check makes no server round-trip. The chain is tamper-evident. It has no external anchor yet. A rewrite of one step and every step after it still verifies. So does removing the last steps. Keep the step count and the last hash from an earlier export to catch either. A later export must have at least that many steps, and the same hash at that step.