Claims with the code attached

• claim · 01Shipped

  A token is a ceiling, never a decision

  Authorization is relationship-based. The scopes on a presented token cap what it can possibly do; the answer comes from the principal’s relationship to the object — organization role, team membership, project grant — read from the database on every check. A token carrying every scope in the system is denied everywhere if its holder is a member of nothing. domain/src/modules/authz/check.ts, held by a test literally named scopes are a ceiling, never the decision.
• claim · 02Shipped

  No machine can merge, at three independent layers

  Approving a fix and merging a pull request are refused to non-human principals. First, the approval endpoint checks the principal kind before it reads anything at all (approvals/requests.ts). Second, fix:approve is filtered out of every agent token at issuance and the merge tier is ungrantable (shared/src/scopes.ts). Third — the one that does not depend on a check being called — there is no merge method in the source-control client (domain/src/modules/scm/provider.ts). Any future action ending in .merge is treated as human-only by default.
• claim · 03Shipped

  Kill switches run before the relationship lookup

  AI can be disabled organization-wide, and agent pull-request creation separately. Both are read and enforced before any membership query, so switching them off does not depend on the rest of authorization behaving. domain/src/modules/authz/agent-policy.ts.
• claim · 04Shipped

  Offboarding a person disarms their machines, in one transaction

  Agents are principals with a mandatory human sponsor. Suspending that sponsor — including through SCIM deprovisioning — sets the agent’s lifecycle, revokes its tokens and revokes its delegations inside a single database transaction, so an offboarded employee cannot leave a live machine identity behind. domain/src/modules/agents/identity.ts.
• claim · 05Shipped

  A narrowed session cannot widen itself

  Delegation follows RFC 8693: nested actor claims, audience-bound tokens, a fifteen-minute default life capped at one hour, and the presented token as its own ceiling — the minted delegation is the intersection of what the human holds, what the agent may hold, and what was asked for. Incident-scoped tokens narrow that further to one incident and its objects, Ed25519-signed and re-verified by their own handler rather than trusting an already-attached principal. domain/src/modules/agents/delegation.ts, agents/blast-radius.ts.
• claim · 06Shipped

  The sandbox is disposed on every path

  A remediation run provisions a sandbox with default-deny egress, no production secrets and a hard timeout, and disposes it in a finally — including on throws, timeouts and metering failures, which are explicitly caught so that they cannot prevent disposal. A leaked sandbox is a bill and, on a hosted provider, a live shell. workers/src/remediation/execute-remediation-run.ts.

• claim · 01Shipped

  The database refuses to connect in the clear

  A DATABASE_URL naming a host reachable off the machine, with no TLS material configured, throws instead of connecting. Certificates are held as PEM text from encrypted secrets and handed to the driver as strings — there is no code path that reads a certificate from a file. db/src/db-tls.ts, with an allow/refuse table in db-tls.test.ts.

  What is not true yet: The code enforces “encrypted, and never on disk”. Whether the connection is genuinely mutual is enforced by the database endpoint, which demands a client certificate — the code would also accept server-authenticated TLS as protected. Loopback, private-range and Compose-service hostnames are exempt from the refusal, and there is a named escape hatch for transports secured elsewhere.

• claim · 02Shipped

  There is no plaintext .env, and the guard is arithmetic

  Secrets are sops + age ciphertext in the repository and are decrypted straight into a process; no command writes a decrypted value to disk. A pre-commit hook blocks secret-shaped paths, private-key material, and exact live secret values, matched by SHA-256 against a local fingerprint index. It never decrypts, so it can run where no key exists. scripts/secrets.sh, .githooks/pre-commit, and a thirteen-case battery in scripts/test-secret-guard.sh.
• claim · 03Shipped

  Personal data is removed before storage, and again before a model

  The scrubber runs before anything is persisted, on all three ingest paths: the worker pipeline, the agentless landing lane, and OTLP. No configuration flag disables it — session replay and agent-observability capture modes decide whether text is kept at all, and even their most permissive setting still scrubs. A second, stricter pass runs before an issue reaches a model, in the essence projection, in root-cause evidence assembly, and in fix authoring. domain/src/lib/scrub/, modules/essence/service.ts, modules/rca/evidence.ts, workers/src/remediation/execute-remediation-run.ts; see also session replay and privacy.

  What is not true yet: The fix-authoring prompt used to be the exception, and we found it while writing this page. It was built from the denormalized issue row — title, exception value, culprit — which carries only the storage-tier scrub, so an email address or IP embedded in an exception message could reach the model that drafts the patch. It now takes the same agent-tier pass as the essence and RCA paths, pinned by a test that fails if the tier is weakened. We are leaving the history here rather than quietly presenting the fixed state: writing this page is what found the defect, which is the argument for the page.

• claim · 04Shipped

  Access, portability and erasure, derived from the live schema

  Data-subject requests are implemented and organization-scoped behind an admin check. The subject surface is walked from the live foreign-key graph rather than a hand-maintained list of tables, so a table added tomorrow is covered tomorrow — and the test asserts completeness against that same graph. domain/src/modules/compliance/dsr.ts.

  What is not true yet: Erasure is a stated policy rather than a blanket delete: nullable references are nulled, non-nullable leaf rows are deleted, non-leaf rows keep a pointer at a pseudonymized tombstone, and the user row itself is pseudonymized. Audit logs are retained under GDPR Art. 17(3)(b)/(e), reduced to a principal id and a SHA-256 digest — never raw payload.

• claim · 05Partly shipped

  Retention windows, and what actually deletes

  Event data is archived to cold storage and the day-partition is then DROP TABLEd — not soft-deleted — with cold objects expired past their window. It runs hourly by default and drops by default. domain/src/modules/retention/pass.ts, workers/src/retention/scheduler.ts.

  What is not true yet: The second retention system — audit logs, spans, log records, replay segments — implements correct, tested hard deletion but has no scheduler. Today it runs only when an administrator calls the enforce endpoint. A policy with an operator-triggered sweep is a weaker control than an enforced window and should be read as one.

• claim · 06Partly shipped

  Audit events into your own SIEM

  Audit rows stream out as HMAC-signed NDJSON batches over a guarded HTTP client, with a durable per-sink cursor that advances only on successful delivery, so a failed batch is retried rather than skipped. domain/src/modules/compliance/audit-export.ts.

  What is not true yet: There is one sink kind — a generic webhook. No Splunk, Datadog or Elastic driver exists, so your collector has to accept signed JSON Lines over POST. Delivery is flushed on demand rather than on a schedule, so this is not yet a continuous stream.

• claim · 07Partly shipped

  Region residency

  Regions are a real constraint rather than a label on a DSN: a hard refusal fires when an organization’s region does not match the region the process is running in, and a cross-region migration path (export, import, cutover, abort) exists with digested bundles. domain/src/modules/compliance/residency.ts, compliance/region-migration.ts.

  What is not true yet: We operate one region. The EU control plane is marked inactive in the registry and does not exist, so nobody is running in it. The residency assertion is also applied per module — at the DSR and migration surfaces — rather than as a global request hook; residency for ordinary reads rests on a regional process holding a connection to only its own database.

• claim · 01Shipped

  Every audit row goes through one function

  modules/authz/audit.ts is the only caller of the audit-log create in the entire API; roughly 185 call sites across the modules reach it, directly or through four thin wrappers. The chokepoint is the control worth citing, not the count — audit coverage is reviewable by reading one function’s callers, and no module can invent an unlogged write path. The Human Accountability Ledger reads that trail back per person, weighting declines equally with approvals and classifying each decline by why.
• claim · 02Shipped

  Redaction that does not break the proofs

  Redacting a ledger entry nulls the readable envelope and stamps a reason, and leaves the leaf hash, every published root and every previously issued inclusion proof verifying unchanged — asserted by a test that publishes a checkpoint, redacts, and re-verifies. Entries containing personal data are refused at issuance rather than quietly edited later. domain/src/modules/proof-ledger/issue.ts, proof-ledger/personal-data.ts.
• claim · 03Shipped

  Verification you can run without us

  A Proof Ledger bundle verifies offline: RFC 6962 inclusion and consistency proofs, Ed25519 over DSSE, and every claim re-derivable from the document. There are three implementations — the issuer’s, a dependency-free CLI, and a browser build — and they are pinned to each other by differential tests over a corpus of over-claiming mutations, so the format is not one only its author can read. tooling/bucker-verify/, shared/src/proof-ledger/, tooling/bucker-verify/test/conformance-differential.test.ts.
• claim · 04Partly shipped

  Independent witnesses

  Checkpoint co-signature is implemented end to end: a witness registry, two transports, delivery with retries and receipts, and real Ed25519 countersignature verification against the witness’s own registered key. domain/src/modules/proof-ledger/witness.ts; the kit is documented in witness onboarding.

  What is not true yet: It is opt-in and defaults to none. Nothing requires a minimum number of witnesses, and a witness under Bucker’s own custody is reported as not independent — the API publishes an explicit flag for that rather than letting anyone infer independence from the presence of rows. Until a third party holds a checkpoint, the log proves internal consistency, not history.

Two different things in this system are called “signed” and only one of them means anything to you. Collapsing them would be the largest cryptographic overclaim available to this page, so they are kept apart everywhere, including in the product: the in-browser verifier refuses a pasted provenance certificate by name, explaining that a shared-secret MAC can be forged by anyone who can check it.

One further disclosure, because it changes what the top four rows are worth: the Ed25519 signing key has three possible provenances and the key endpoint states which is in use — a dedicated key, a fallback that reuses the access-token key, or an ephemeral per-process key when none is configured. An ephemeral key does not survive a restart and is not a durable attestation. Ask which one a deployment is running before relying on a signature from it.

These routes require no session and no API key. They are the ones that let an outsider check us rather than take our word.

• GET /transparency/register

  Deployment-wide miss rates — rejected patches, in-window regressions, prompt-injection trial results. No organization, project, issue or principal identifier appears in it. There is no edit, delete or retract route for a published snapshot, and a test enforces that.

• GET /transparency/snapshots/:leafIndex/inclusion-proof

  Re-derive a published snapshot’s Merkle inclusion yourself. The product’s own register page recomputes the root in the reader’s browser and ignores the API’s verified flag.

• GET /transparency/consistency-proof?oldSize=N

  Prove the log was appended to and not rewritten between two sizes.

• GET /.well-known/proof-ledger-keys

  The Ed25519 public key, with its provenance disclosed.

• GET /billing/plans

  The plan ladder the product enforces. This site’s pricing page reads it, so a published price cannot drift from the one that bills you.

The questions a security review actually asks, with the answers, including the ones where the answer is no.

Do you hold a SOC 2 report?

No. No audit is in progress, no auditor is engaged, and no observation window has begun. The readiness note maps what exists in code to the Trust Services Criteria, and lists the policy work that does not exist.

Is data encrypted in transit?

Yes to the database, and enforced rather than configured: a remote host with no TLS material throws instead of connecting in the clear (db/src/db-tls.ts). Outbound calls go through a guarded client that refuses private and loopback destinations (domain/src/lib/egress.ts).

Is data encrypted at rest?

Our own secrets are, with sops + age, and you can verify that from the repository. Storage-layer encryption of the database and object store is a property of the managed services we run on; we have not documented it and we do not assert it here.

Can your AI merge code into our repository?

No, and not because a permission is switched off: there is no merge method in the source-control client to call. See “No machine can merge” above for the two checks that sit in front of that structural fact.

Who can approve a change, and can you prove who did?

Only a human principal. Every decision is written through a single audit function and is readable per person in the accountability ledger, with the full chain of authority — actor, delegation, budget, trust rung, approval, certificate — resolvable for any one action.

Do you send our data to a model provider?

Yes, for root-cause analysis and fix authoring. Content is scrubbed before it is stored and again, at a stricter tier, before the essence and RCA paths reach a model — with the fix-authoring exception disclosed above. We have no zero-data-retention agreement to show you and do not claim one.

Can we get audit logs into our SIEM?

Yes, as HMAC-signed JSON Lines over a webhook, with at-least-once delivery. There is no vendor-specific driver and no automatic flush schedule yet.

How do we exercise a data-subject request?

Through the compliance endpoints: access and portability export, and erasure. Erasure pseudonymizes rather than deletes the subject row and retains audit logs under GDPR Art. 17(3)(b)/(e), reduced to an id and a digest.

Where is our data stored?

In the one region we operate. Multi-region residency is implemented with a hard refusal and a migration path, but the EU control plane is inactive and unbuilt.

Do you have an incident response plan, security training, or background checks?

No, none of the three. They are listed as policy-without-tooling in the readiness note rather than implied by anything on this page.

Do you have a third-party penetration test report?

No. One has not been commissioned.

Do you publish a status page or an SLA?

status.bucker.io publishes live reachability checks against our public endpoints, made from outside the infrastructure they report on, with the time of each check. It is not a hosted status page: no incident history, no subscriber notifications, no maintenance calendar. We offer no SLA and no SLO.

Is your source available for review?

Not publicly today. The Community Edition is the self-hostable subset, and its documentation says exactly where the commercial line sits. Every path named on this page is a path in the repository a licensee or a reviewer under agreement receives.

• SOC 2 readinessWhat is implemented in code, what is policy without tooling, and what has not been started. No certification, no audit in progress.