Security you can check.

Data protection

Redaction before anything leaves. Secrets, API keys, JWTs, emails, card numbers (Luhn-checked), and SSNs are scrubbed inside your own application process — before a trace is sent anywhere. Even your backend never sees them. Two tiers (standard/strict), custom patterns, key allow/deny lists.

Self-host — data never leaves. Runback is a Next.js app and a Postgres database. Run it in your own VPC — traces never touch our servers, and there's no telemetry call-home in the self-hosted core.

Keys and tokens never stored readable. API keys and session/magic-link tokens are never stored in the clear — only a non-secret prefix plus a SHA-256 hash. Session cookies are httpOnly, Secure and SameSite=lax with a bounded lifetime.

Encrypted secrets at rest. OIDC client secrets, customer model-provider keys, SIEM tokens, and workflow credentials are each AES-256-GCM encrypted under their own key, so rotating one never invalidates the others. Plaintext is never stored or returned by an API — only whether a secret is set, and its last four characters where that helps.

Tenant isolation. Every workspace is an isolated org. Every run is stored under its organisation as well as its own id, and the database itself refuses any link from one organisation's data to another's, so isolation is not a check someone might forget. Queries are org-scoped, and a source-level test fails any that aren't. Self-hosting gives each customer a dedicated database outright.

Access control

Runtime policy enforcement. Rules run before each tool call, so a violating action (an unescalated A$250 refund, say) is blocked BEFORE it executes. Two modes ship. In-process, the TypeScript SDK checks your rules as a pre-hook, with no network in the critical path. Server-side, the TypeScript and Python SDKs ask Runback to decide each call against the rules assigned to that agent; a call can be held for a human to approve, and each assignment sets whether the agent fails closed or open while Runback is unreachable (the TypeScript SDK first uses its cached copy of the rules, up to five minutes old). Every block is recorded as a hash-chained, re-runnable event — proof the control fired — and rules can be simulated against history before you turn them on. This is application-layer control: either way the check is made from inside your process, so prompt injection that takes the process can bypass it, and infrastructure isolation is a separate defence. An agent not calling through Runback at all is a different concern, covered below under Gateway credential isolation, SDK bypass detection and Governance coverage.

Gateway credential isolation. By default the gateway (@runback/gateway — base-URL swap, no SDK) forwards whatever credential the agent sends, so the key that reaches the gateway also reaches the provider directly, with nothing to tell you. RUNBACK_GATEWAY_UPSTREAM_KEY and RUNBACK_GATEWAY_TOKEN close that: the real credential lives only in the gateway process, injected server-side, while agents authenticate with a token worthless against the provider. Pair it with an egress rule allowing provider traffic only from the gateway. Unset by default, so it won't break local dev silently.

OIDC single sign-on. Enterprise SSO via OpenID Connect (Authorization Code flow), with issuer, audience and nonce verification against the IdP's JWKS. Works with Okta, Microsoft Entra ID, Google Workspace, Auth0 and Ping. Routed per-org by email domain.

Role-based access control. Four roles — owner, admin, member, viewer — enforced on every privileged route. Ownership is protected: only an owner can grant owner, and the last owner can't be removed or demoted.

SCIM 2.0 provisioning. Okta, Entra ID or any SCIM 2.0 provider provisions and deprovisions members automatically — including the discovery endpoints an IdP probes at setup, PATCH/PUT profile pushes, and userName lookup resolved in the database whatever the directory size. Deprovisioning removes access immediately rather than flagging a row inactive, so there's no offboarding step to forget. The endpoint authenticates with a scoped token that can't ingest runs, read run content or open a session, and refuses to deprovision the last owner. Deprovisioning also ends the person's sessions, and is remembered: an email link, a domain auto-join, an old invite or an SSO sign-in cannot re-add them until the IdP reactivates them. Groups are supported, and an admin can map a group to viewer, member or admin; a member's role then follows their groups at SSO sign-in and whenever the IdP changes a group (owners are never changed by mapping).

External auditor & regulator grants. Issue a read-only, time-limited key scoped to specific runs — or all of them — from Settings, and hand an auditor that instead of a login. It downloads the same signed record your team sees: byte-identical, not a summary. Revocable any time, and every grant is checked for expiry and revocation on every read.

Audit & integrity

Records that show any change. Every run exports as a SHA-256 hash chain with a final content digest, signed by Ed25519 when a keypair is configured (as on the hosted service) — asymmetric, verifiable offline against our published key, no shared secret or account required. Change one byte and verification fails. The digest covers the run's replay inputs too, so the record can be replayed, not just read. Without a keypair configured, deployments fall back to HMAC-SHA256: integrity, but not non-repudiation, since the verifier holds the same key; with neither key set, records are unsigned.

A log nobody can quietly edit. Org-wide, hash-chained log of every run's digest, with a checkpoint signed every hour, each carrying a Merkle root for inclusion proofs — an auditor can check that any run belongs to the signed history.

Externally witnessed checkpoints. Our signature proves nobody else altered the chain — not that we didn't, since we hold the key. So each checkpoint is also sent to two independent RFC 3161 timestamp authorities — best-effort: if an authority is unreachable the checkpoint is signed without its token — on certificates we don't control and can't backdate: rewriting history changes the checkpoint head, and no authority will date a token for the new head earlier. The raw tokens verify with `openssl ts -verify` against the authority's own CA, so checking our tamper-evidence needs no Runback software. Time-stamping alone wouldn't catch us keeping two divergent but honestly-timestamped histories and showing each to a different party — so every checkpoint is also published to a public, unauthenticated, hash-chained feed (`GET /api/transparency`), where two heads for the same (log, seq) would sit side by side for anyone who archived it, and the database rejects the second write. We skipped a blockchain anchor deliberately: anchoring needs a public network that air-gapped installs correctly refuse to depend on.

Administrative audit log. Recorded today: API key issuance/revocation, member invites (and invite withdrawals and resends)/removals/role changes, SSO configuration, model-provider credential changes, policy changes, prompt version saves and label moves, a human overriding a pairwise verdict or correcting a judge's calibration, legal holds placed/released, ledger checkpoint seals, evidence-package exports, and org settings changes. Each is written to a hash-chained log using the same method as the run log — deleting an entry breaks the chain, so the log can't be edited by the people it audits. Actor, source IP, and target are recorded; secrets never are. Sign-ins, sign-outs, failed and refused sign-ins are recorded in a separate sign-in log (shown on the same Activity page and exported to your SIEM), so their volume stays out of the chain. Not covered: retention-window changes, because retention is set by plan rather than in the product.

Legal hold. Retention deletion can be suspended for runs under a preservation obligation — litigation, a regulator request, an investigation — org-wide or per agent. Every deletion path consults holds first, and if the holds table can't be read the sweep is skipped: the failure favours keeping data. Placing and releasing a hold are both logged.

AI explanations you can trust later. A root-cause explanation or a control's evidence summary can be AI-generated on demand, then signed the way a run is: hash-chained to your org's prior narratives and signed, with the source evidence pinned by digest. If that evidence later changes, re-verification catches it. The explanation is disposable; the proof it wasn't rewritten is not.

Monitoring & governance

SDK bypass detection. The SDK integration (withDebugger) has no separate credential to isolate — it never held one apart from your real provider key — so a call outside the wrapper can't be made to fail. It can be noticed, though: installBypassGuard() (or enforceCapture: true) watches for calls to a known model-provider host made outside an instrumented call and reports them as a governance finding, through the same ServiceNow/Jira/PagerDuty pipeline as a coverage gap. "observe" (default) reports and lets the call through, matching the in-process gate's fail-open default (server-side enforcement sets its fail mode per policy assignment); "block" throws. Opt-in, because it patches globalThis.fetch process-wide.

Audit export to your SIEM. Administrative audit events forward to Splunk, Microsoft Sentinel, or any HTTPS collector hourly, so access evidence lands in your SOC, not just our dashboard. Delivery is at-least-once from a per-sink watermark, and every event carries its chain hashes so you can verify the feed wasn't altered in transit.

Governance coverage. Declare the agents you expect to be governed and Runback reconciles that inventory against what actually reports: declared but never instrumented, reporting then gone silent, or observed while absent from your register. Findings open a deduplicated ticket in ServiceNow, Jira, or PagerDuty.

External security-tool findings. A write-only, narrowly-scoped key lets a guardrail vendor (Lakera, Cisco AI Defense or similar) post findings into your own signed record rather than siloing them in their dashboard. Each is hash-chained and signed on arrival, separately from the run's replay inputs, so a vendor's webhook can never alter a run's replay identity.

The mechanism behind each criterion

CC6.1 · Logical access is restricted. OIDC SSO with per-org domain mapping, optionally enforced so it is the only way in for those domains (one audited break-glass owner excepted); four roles checked on every mutating route, with a build check that fails when one is missing; and API keys whose role follows a narrow scope, listed, revocable and expiring.

CC6.2 · Access is authorised before being granted. Membership is created by an admin invite, by SCIM from your identity provider, or by SSO sign-in; with SSO enforced, invites and domain auto-join are refused for the SSO domains. Federated users get the role mapped from their IdP groups, or the org's default.

CC6.3 · Access is removed when no longer required. SCIM deprovisioning removes the membership and ends the person's sessions immediately, and records the removal so no other sign-in path re-adds them. The last owner of an organisation cannot be removed, so an IdP error cannot strand a workspace.

CC6.6 · Data in transit is protected. HSTS with preload, a strict Content-Security-Policy, and HTTPS enforced at configuration time for every outbound integration — a plain-HTTP collector endpoint is rejected rather than accepted and used.

CC6.7 · Data at rest is protected. Disk-level encryption, plus AES-256-GCM application-level encryption for every stored credential, each under an independently rotatable key. Field-level encryption of run content is a disclosed gap above.

CC7.2 · Anomalies are detected. Server faults are captured, grouped by fingerprint, and pushed as a digest rather than logged unread. Ledger verification re-derives every entry from current data, so alteration is detected, not assumed absent.

CC7.3 · Incidents are evaluated and acted on. Governance findings — a ledger that fails verification, a critical agent gone silent — open a deduplicated ticket in ServiceNow, Jira, or PagerDuty, with an owner and an SLA.

CC4.1 · Controls are monitored over time. The administrative audit log records in-app operator actions — key changes, membership/role changes, policy changes, legal holds, checkpoint seals, evidence exports — in a hash chain the operators can't rewrite, and exports hourly to your SIEM. See the entry above for coverage detail.

C1.1 · Confidential information is identified and protected. On the Vercel AI SDK and Python/LangGraph collectors, redaction runs inside your process before egress, so secrets and PII its patterns match are never sent. Detection is by pattern, plus any keys and patterns you add. Integrations that ship via OpenTelemetry send raw spans to us first and are redacted server-side before storage or display instead — see the Integrations doc for which paths that applies to. Tenant isolation is enforced by the database itself, which refuses a link between two organisations' data, not by application checks alone.

P4.2 · Personal information is retained no longer than needed. Per-plan retention prunes payloads then summaries on a schedule, with deletions recorded so an audit trail can tell policy from tampering. Legal hold suspends deletion where a preservation obligation applies.

A1.2 · Availability is monitored. A health endpoint reports readiness against the database and answers 503 when it cannot serve, so an external monitor reacts without parsing a response body.

Every line is behaviour that ships in the product now.

Application-level field encryption at rest Roadmap

Data at rest is protected by Postgres and disk-level encryption in your VPC. Application-level field encryption (column-level or envelope encryption) is on the roadmap, not yet shipped. For regulated environments that require it, self-hosted deployment in your own KMS-backed VPC is the current path.

Database row-level security Partial

The database itself keeps each organisation's runs apart: it refuses any reference from one organisation's data to another's. In schema terms, a run is (org_id, run_id), not run_id alone, and events reference runs through a composite foreign key. RLS is enabled on every table, anon/authenticated roles are revoked, and default privileges close new tables on creation.

A dedicated tenant database role exists that cannot bypass RLS, with policies reading the tenant from a short-lived signed token rather than the query — so a read through it returns only one org's rows, and a missing filter returns nothing rather than another customer's data. Run, ledger, compliance, narrative, security-finding and external-grant reads go through it today. Writes for incidents, approvals, findings, narratives and policies go through a separate tenant-write role only where a deployment has switched it on (it is opt-in).

To be precise: policies are load-bearing only where the tenant role is configured — remaining reads, and every write unless the tenant-write role is switched on, still run as a role that bypasses RLS. Until every path migrates, isolation there rests on application-layer filtering plus CI guards that fail any query filtering on a run id without an org. The full design and per-path rollout state are available on request as part of a security review.

Session revocation and rotation Partial

Shipped: an admin can sign out any member's sessions from Team, and the revocation is recorded in the admin audit trail. Signing out revokes the session on the server, not just the cookie, and every sign-in revokes that user's earlier sessions.

Not yet: sessions stay valid for 30 days with no sliding expiry, a role change does not rotate the session, and there is no per-device session list or last-seen tracking, so you cannot sign out one device and keep another. If you suspect a session is compromised, an admin can sign that member out now; hello@runback.dev can help beyond that.

EU managed region Roadmap

A managed region in the EU is on the roadmap, with no committed date. Today: Managed cloud data — agent traces, audit records, account data and backups — is stored and processed in Sydney, Australia (AWS ap-southeast-2). Transactional email is delivered by Resend in the US, which receives the recipient address and message content only. Self-host keeps data in your own region, and Enterprise self-hosted is available now, in any region.