Skip to content

Cookie preferences

Choose which cookies and similar technologies this site may use. The strictly necessary ones keep the site working and remember this choice, so they cannot be turned off; they store nothing that identifies you or follows your browsing. Read the cookie notice

Continuumship
Menu

Trust

Your code stays yours. The record is ours to keep.

The platform holds your process, your decisions and the evidence for them. It never holds your source. This page says where each thing lives, and the mechanism behind each statement.

Where your code is

Your code never leaves your machines.

Runs execute on your runners, in an isolated worktree, under a signed brief and a policy the machine's owner sets. Our code-host credentials pass a method-and-path allowlist that cannot reach repository contents.

Stays on your machines

  • Source code, checkouts and dependency caches
  • Diffs, and the branches an agent works on
  • Secrets and provider credentials, sealed so the platform cannot open them
  • Model transcripts, your model credentials and your runner's private key

Held by the platform

  • Your process: flows, stages, guardrails and who owns each step
  • Decisions: every approval, who gave it, and what it was given against
  • Evidence metadata: check results, counts, hashes and signatures, each with its provenance
  • Previews, screenshots and attachments, in private storage or in your own bucket

Isolation

One workspace, one boundary.

Isolation is built into the database, the request and the network path. A dedicated test suite checks it on every change.

  • PostgreSQL row-level security, forced, on every tenant table
  • Three database roles; the roles that serve requests cannot bypass row-level security or delete audit rows
  • Every request resolves its workspace before it reads anything, and a request without one is refused
  • An id from another workspace answers 404, never 403, so it does not confirm that the record exists
  • Session cookies are host-only, bound to one host and one login
  • Outbound calls pass an SSRF guard with DNS pinning, so an address someone typed cannot reach an internal network

People decide

An agent proposes. A person decides. The platform proves it.

The rules that decide what an agent may do are records, not conventions.

  • 01

    Provenance on every claim

    Each check says where it came from — Verified by Continuumship, Measured by runner, Reported by agent — so a claim is never presented as a measurement. An integrity failure cannot be overridden.

  • 02

    Separation of duties

    Approval chains route each decision to the person who owns it, and the author of a change does not approve it.

  • 03

    Guardrails no team can remove

    Organisation rules are tried in shadow, then enforced at every run, step, approval and release. Each decision is recorded with its reason.

  • 04

    Autonomy is earned, and lost

    Standing approvals for named work are granted over a clean window of evidence, and step down on one failure.

What is stored

Every class of data, where it lives, and how long.

Every table and column is classified, and the classification is checked against the database schema on every change. Stored data lives in your workspace's region.

Work records — work items, approvals, briefs and comments
Where it lives: Our PostgreSQL database, under row-level security
How long it is kept: Under your workspace's policy. An approved snapshot is never rewritten.
Evidence metadata — check names, statuses, counts, hashes and signatures
Where it lives: Our database, beside the decisions it supports, with its provenance
How long it is kept: With the decisions it supports. An integrity incident keeps the original record. Filenames, diffs and transcripts are never part of it.
Previews of your interface — compiled static builds
Where it lives: Private object storage, scanned before they are unpacked, served from a separate origin
How long it is kept: Seven days after they lapse, by default. An approved draft keeps its bytes.
Attachments — screenshots, references and test evidence
Where it lives: Private object storage or your own bucket, downloaded through links that expire after five minutes
How long it is kept: Under your workspace's policy.
Credentials — hashes of tokens, never the tokens
Where it lives: Hashes in our database; your runner's private key in its operating system's keyring; your model credentials on your machines
How long it is kept: Short-lived: access tokens last minutes, run credentials end with their phase. None appears in a log, an audit event or an export.
Operational metadata — event ids, timestamps, states and failure codes
Where it lives: The audit log and the workspace's event records
How long it is kept: The audit log for twelve months by default, up to eighty-four as you set. Raw health observations for seven days, hourly summaries for ninety.

For your auditors

What an auditor gets.

The record is built to be taken away and checked, not just read on a screen.

  • The audit log, in your SIEM

    Append-only and hash-chained. Anyone with the auditor's permission can verify the chain, and it streams in order over signed HTTPS to your SIEM — nothing skipped, nothing sent twice.

  • The compliance pack

    A living map from the EU AI Act's human-oversight duties, and the controls your auditors work from, to the features that support them and the evidence that shows each one. It states what the product supports; compliance stays yours.

  • Reconstruction, to an attestation

    For any work item, one document: the intent, the ledger, every decision and run, verification, delivery and the audit trail, carrying its own SHA-256. The evidence chain runs from the accepted intent to a signed attestation.

Identity and access

Your directory decides who is in.

  • Single sign-on with SAML or OIDC
  • SCIM provisioning: people join and leave from your directory
  • Custom roles, down to an auditor who reads the audit log
  • API tokens stored as hashes, bound to one workspace, narrowed by scopes that never widen the holder's permissions, and revoked on departure

Sub-processors

Who processes data for us.

Each provider, what it does for us, and where.

Google Cloud
What for: The application servers and the PostgreSQL database, on a private network; the database has no public address
Where: Frankfurt, Germany
Cloudflare
What for: DNS, and private object storage for files, reached only through signed links
Where: Files in the EU jurisdiction; DNS at the edge
Stripe
What for: Subscriptions, invoices and payments
Where: Under Stripe's own data processing terms

Ask for the security review packet.

The data classification, the threat model, the outbound scope and a description of the compliance pack, sent by a person to the people doing your review.

Ask for the packet