{"trust_center":"runback-procurement/v1","generated_at":"2026-11-07T07:28:15.000Z","note":"Answers reflect shipped mechanisms, not intentions. Gaps (no SOC 2, no third-party pentest) are stated plainly, not omitted.","regulatory_mapping":[{"framework":"EU AI Act · Art. 12","requirement":"Automatic event logs for high-risk AI systems over their operational lifetime — applying from 2 December 2027","control":"Every decision context, model version, and policy state is cryptographically sealed the moment it happens — a tamper-evident record we call a cassette","evidence":"Exportable cassette file per run, verifiable without Runback"},{"framework":"EU AI Act · Art. 14","requirement":"Human oversight — ability to understand, monitor, and override AI outputs","control":"Policy gates block non-compliant calls before execution; sealed record enables post-hoc review","evidence":"Policy block events are cassette entries with rule, predicate, and full decision context"},{"framework":"APRA CPS 230","requirement":"Operational incidents and near misses must be identified, escalated, recorded, and addressed — CPS 230 does not name AI; this applies to any material business process, AI-driven or not","control":"Deterministic replay of any agent decision from the exact captured context","evidence":"Re-executable run record with the exact inputs the model received"},{"framework":"APRA CPS 230","requirement":"Critical operations must stay within tolerance during disruption, with a business continuity plan to maintain them","control":"Each policy assignment fails closed or open when Runback is unreachable (closed by default for agents declared critical, once the SDK has fetched its policy bundle — before that first fetch it fails open); decisions made during an outage are reported and sealed afterwards while the agent process keeps running (an in-memory queue); failed trace sends retry in-process on the next flush","evidence":"Server-side decide with a per-assignment fail mode (TypeScript and Python SDKs); the TypeScript SDK also falls back to its cached policy for up to 5 minutes"},{"framework":"APRA CPS 234","requirement":"Information security commensurate with the degree of risk","control":"PII redacted before storage (in-process on first-party SDKs, server-side on OTel); RBAC; self-hosted VPC option","evidence":"Redaction log; RBAC audit trail; self-host keeps your data entirely in your perimeter"},{"framework":"NIST AI RMF · Govern 1.2","requirement":"Organisational accountability for AI risk decisions","control":"Every decision attributed to a specific run, model version, and policy state — tamper-evident","evidence":"Each run's record is hash-chained and its digest signed, so an edit after the fact is detectable — including one made by Runback. Ed25519 when a keypair is configured, HMAC-SHA256 as the fallback, and unsigned if neither key is set. Ledger checkpoints are sealed hourly into an append-only Merkle-chained ledger and sent to two independent RFC 3161 timestamp authorities on a best-effort basis — the timestamp covers the checkpoint, not each decision individually."},{"framework":"NIST AI RMF · Measure 2.5","requirement":"AI system performance monitoring in production, including drift detection","control":"Continuous capture of decisions with policy evaluation; model diff on real production inputs","evidence":"Model diff report showing behavioural change before a model upgrade ships"},{"framework":"NIST AI RMF · Govern 4.1","requirement":"Independent oversight — the org's own risk decisions are subject to external review","control":"A time-limited, read-only key scoped to specific runs (or all of them) grants an auditor or regulator the same signed record your own team sees — no platform login, no export handed over blind","evidence":"Byte-identical signed audit record, downloadable by the external party directly; every access checked for expiry and revocation, not just at issuance"}],"caiq":[{"domain":"Hosting","status":"yes","q":"Where does our data live?","a":"Self-host in your own VPC — your data never reaches us. 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. EU residency requires Enterprise self-hosted."},{"domain":"Data residency","status":"partial","q":"Can we control the region?","a":"Self-host: you choose the region — your cloud, your perimeter. Managed cloud: Sydney, Australia only. Enterprise self-hosted gives you full control of the infrastructure and region."},{"domain":"Encryption — transit","status":"yes","q":"Is data encrypted in transit?","a":"Yes. Managed cloud uses TLS throughout. Self-host runs behind your own TLS terminator. Session cookies are Secure + httpOnly."},{"domain":"Encryption — at rest","status":"partial","q":"Is data encrypted at rest?","a":"At-rest encryption relies on your Postgres and disk encryption. Application-level field encryption is on the roadmap — not yet shipped, disclosed on our security page."},{"domain":"Access control","status":"yes","q":"How is access controlled?","a":"RBAC with four roles — owner, admin, member, viewer — enforced on every privileged route. The last owner cannot be removed."},{"domain":"Authentication","status":"yes","q":"What sign-in methods are supported?","a":"Passwordless magic link, and enterprise OIDC SSO (Okta, Microsoft Entra ID, Google Workspace, Auth0, Ping)."},{"domain":"PII handling","status":"yes","q":"How is sensitive data protected?","a":"Keys, emails, card numbers (Luhn-checked) and SSNs are redacted before storage, by pattern — a value no pattern matches is not. On the Vercel AI SDK and Python/LangGraph collectors this happens inside your process, before any trace leaves it; OpenTelemetry integrations send raw spans to us first and are redacted server-side, before storage or display. Standard and strict tiers, plus custom patterns."},{"domain":"Audit logging","status":"yes","q":"Is there a tamper-evident audit trail?","a":"Yes — tampering is detectable, not just discouraged. Each run is a SHA-256 hash chain with a digest signed by Ed25519 by default: asymmetric, verifiable offline against our published key, so non-repudiation doesn't require trusting our servers. Without a keypair, deployments fall back to HMAC-SHA256 — integrity, but not non-repudiation, since the verifier holds the same key. Every checkpoint is also time-stamped by two outside RFC 3161 authorities we don't control and published to a public, hash-chained append-only feed (GET /api/transparency), so two divergent but honestly-timestamped histories would sit side by side for anyone who archived it — closing the one gap time-stamping alone leaves open. Self-hosted customers holding their own AUDIT_SIGNING_KEY / AUDIT_ED25519_PRIVATE_KEY improve their position further."},{"domain":"Sub-processors","status":"yes","q":"Who are your sub-processors?","a":"Supabase Inc. (US) — managed Postgres database (stores agent traces, account data, audit logs). Resend Inc. (US) — transactional email delivery (magic-link sign-in and alert notifications). Vercel Inc. (US) — application hosting and edge delivery for the managed cloud; receives request data in transit and provides cookieless page analytics for the marketing site, but does not store agent trace content. Groq LLC, OpenAI and Anthropic, PBC (US) — model inference for replay, LLM-as-judge scoring, run narratives and adversarial test generation when an organisation has not configured its own provider key; they receive the captured prompt content of the step being processed. Note: Lemon Squeezy LLC acts as Merchant of Record for paid subscriptions and is an independent data controller for payment data — it is not a sub-processor bound by Runback's DPA. The complete list, with the change-notification commitment, is in the DPA; countersignable copy at legal@runback.dev."},{"domain":"Data portability","status":"yes","q":"Can we export our data in a portable format?","a":"Yes. Agent trace cassettes use the open, documented runback.cassette/v1 JSON format, exportable per run any time — no Runback account or software needed to read them after export. Chargeback data exports as CSV; compliance reports as structured JSON. Managed cloud provides a data export window before deletion; self-hosted customers own the Postgres database outright. These support your GDPR Art. 20 data-portability obligations."},{"domain":"Data deletion","status":"yes","q":"Can we delete our data?","a":"Yes. A signed-in workspace admin can delete any run (DELETE /api/runs/{run_id} from a browser session, not an API key, with a confirmation that repeats the run id). That removes the run, its events, its regression-test copy, its alert-delivery records and its share of the dashboard totals. A run under a legal hold cannot be deleted until the hold is released. Every deletion is written to the admin audit log, and the run's sealed ledger entry stays with a tombstone recording that it was deleted and by whom, so the ledger still verifies. On plans with the audit ledger, a signed checkpoint covers that tombstone before the run is removed; the name of who deleted it is recorded but is not part of what the checkpoint signs. Kept: hash-chained records about the run (AI narratives and security findings, where removing one entry would break the chain for every later one) and governance records that refer to it by id (approvals, incidents, attestations, policy decisions, external access grants that list it, and dataset items someone copied from it). Runs are also deleted automatically at the end of your plan's retention window, and erasing the account of a workspace's only member deletes the workspace and all its runs. On termination we delete or return your data within 30 days, except where retention is required by law. Self-host: entirely under your control."},{"domain":"Data use","status":"yes","q":"Do you use our data to train models?","a":"No. We do not train models on your data and do not sell personal data."},{"domain":"Operational resilience","status":"partial","q":"What happens if Runback is unavailable?","a":"Observation runs async — never in your agent's critical path. Policy enforcement fails closed or open per policy assignment (closed by default for agents declared critical, once the SDK has fetched its policy bundle; before that first fetch it fails open unless the agent sets its own fail mode to closed), and decisions made while Runback is unreachable are reported and sealed once it answers again, if the agent process is still running (that queue is in memory). A failed trace send is requeued in-process and retried on the next flush — that buffer is in-memory only, not persisted to disk, so events not yet flushed are lost if the process exits first."},{"domain":"Certifications","status":"not_yet","q":"What certifications do you hold?","a":"None yet, and none in audit. SOC 2 Type II is planned but not started — the observation window alone runs 3–6 months, so we won't imply it's closer than it is. What exists today: a control-by-control mapping on the security page, against shipped mechanisms, not intentions. We operate GDPR-aligned, with a DPA on request. Self-host keeps your data in your own perimeter, which simplifies your own compliance posture."},{"domain":"Penetration testing","status":"not_yet","q":"Do you conduct penetration testing?","a":"Not yet by an independent third party — we won't claim an assessment we can't produce a report for. Security work to date is internal: adversarial testing of the audit verifier and tamper-evidence chain, CI guards against cross-tenant reads and unbounded queries, and the control-by-control review on the security page. An external test is planned alongside SOC 2 Type II; we'll publish the date once engaged. Self-hosted deployments run in your own perimeter — your team's standard assessment process applies, and we'll support it."},{"domain":"Vulnerability disclosure","status":"yes","q":"How do we report a vulnerability?","a":"Email security@runback.dev. We acknowledge within two business days and credit reporters once a fix ships."},{"domain":"Staff access","status":"partial","q":"Can Runback employees read our agent traces?","a":"On managed cloud: infrastructure staff have database-level access. On the Vercel AI SDK and Python/LangGraph collectors, PII is redacted inside your application process before anything is sent. Detection is by pattern (card numbers, emails, SSNs, keys) plus any keys and patterns you add, so a value no pattern matches is sent as written. On OpenTelemetry-fed integrations, raw spans reach our servers and are redacted before storage — the unredacted payload transits our infrastructure, even though it isn't retained unredacted. Either way, the redacted trace content that remains is readable by anyone with database access. Self-hosted: your data never touches our servers; this question doesn't apply."},{"domain":"Business continuity","status":"yes","q":"What happens to our audit records if Runback ceases to operate?","a":"Self-hosted customers own the database — records remain in your infrastructure regardless of what happens to Runback. Managed cloud: cassette files use an open, documented format (runback.cassette/v1) with a public schema, and export/verify independently without our software or an account. We provide a data export window before any cessation of service."},{"domain":"Data erasure","status":"yes","q":"How does GDPR right to erasure apply to your append-only ledger?","a":"The append-only ledger is designed so removing an entry breaks the hash chain — that's the point of tamper-evidence. Our approach: redaction keeps personal data from reaching the cassette. If PII did reach a managed-cloud cassette, a workspace admin can delete the run (or we do, on a verified erasure request). The run goes; its ledger entry stays with a tombstone, so the chain still verifies and records that an authorised deletion happened rather than hiding it. On plans with the audit ledger, a signed checkpoint covers that tombstone. Hash-chained AI narratives and security findings about that run are kept, which is another reason redaction comes first. Self-hosted: you own the database and the erasure decision."},{"domain":"External auditor access","status":"yes","q":"Can we give an external auditor or regulator access without sharing a login?","a":"Yes, on Enterprise. An admin issues a time-limited, read-only key from Settings — scoped to specific runs or to all of them — and hands it directly to the auditor. It downloads the exact same signed audit record your own team would see, byte-identical, not a summary. Revocable at any time; access is checked for expiry and revocation on every read, not only when the key is issued."},{"domain":"Reviewer identity","status":"partial","q":"Is an approver's identity erasable once their decision is sealed?","a":"Not while the workspace exists. An approval or rejection is sealed into the audit ledger with who made it (their sign-in email — API keys cannot decide approvals) and when, and the sealed record cannot be edited or deleted, because changing it would break the hash that proves the decision. Deleting the reviewer's account or the run does not remove it; deleting the workspace does. If reviewer identities must be erasable, have reviewers decide from role accounts rather than personal ones."}],"documents":{"security_overview":"https://runback.dev/security","dpa":"https://runback.dev/dpa","terms":"https://runback.dev/terms","privacy":"https://runback.dev/privacy","procurement_page":"https://runback.dev/procurement","signed_dpa_request":"legal@runback.dev"}}