Security claims stay testable.

Tenant data is isolated in PostgreSQL.

Tenant tables carry an organisation key and use forced PostgreSQL row-level security under transaction-local tenant context. Without that context, a query returns no tenant rows. A tenant cannot read, insert, update, or delete another tenant's row, including by primary key.

The pool refuses a database role with superuser or row-security bypass privileges. Seven named elevated functions handle lookups needed before a tenant is known. Schema audits reject other elevated functions and unprotected tenant tables outside three named non-tenant exceptions.

Always-on database integration testing remains planned. The current tests skip when a test database is not configured.

Each run has isolated credentials and execution.

A per-run token is limited to one organisation, workspace, and run, with named audiences. The MCP server and model proxy reject a closed, revoked, expired, stopped, or wrong-audience token on every request. Serving records first contact for each audience, while a separate strict attach operation rejects a second attach.

Each run receives one disposable Docker agent container with per-run sidecars, or one disposable Box VM. Docker production runs use an internal network and a non-root, read-only container with dropped capabilities, resource limits, no host namespaces, and no Docker socket. Box runs install a root-owned firewall before the unprivileged agent starts.

Managed browsing runs in a separate per-run browser container. Result collection rejects unsafe file types and path escapes. Docker and Box cleanup check that the execution resource is absent after deletion.

Physical media erasure proof, separate runner and agent user IDs, a fix for the known IPv4-mapped IPv6 metadata-address form, a typed browser-service field for the MCP sidecar, and a shared atomic model-budget ledger remain planned.

Product routes share a central authorizer.

Authenticated API resource routes and console product reads and writes use the central authorizer. It verifies the accepted credential class, matches the organisation and workspace, checks a closed permission set, and writes each grant before acting. It attempts to record each tenant-attributable refusal in that tenant's audit log.

Human sessions read current membership on every request. Machine credentials use the role and scopes stored on their credential row. Owner, admin, member, and reviewer roles map to a closed permission set. Protocol services for MCP, models, browsers, and connectors enforce their own checks rather than all calling the central authorizer.

Per-tenant, per-key, and per-address HTTP request rate limits remain planned.

Human sign-in fails closed.

OIDC sign-in uses authorization code flow, PKCE S256, state, nonce, and a browser login-binding cookie. It validates issuer, audience, signature, provider keys, and nonce. Discovery requires HTTPS and keeps provider endpoints on the issuer origin outside loopback tests. The console wires the ID-token path used by Google and Microsoft.

Browser sessions require a separate binding cookie, have idle and absolute limits, rotate without extending the absolute lifetime, and revoke the session family when an old rotated secret is replayed. Console mutations require an allowed origin and matching CSRF token.

The auth package can enforce provider MFA assertions through its policy values.

The console does not pass an MFA policy, so its effective policy is off, and it does not wire GitHub user sign-in. SAML, native Repro MFA, console configuration for provider MFA, live Google, GitHub, and Microsoft validation, key-bound browser sessions, and console wiring for provider refresh-token revocation and upstream logout remain planned.

Machine credentials keep no plaintext secret half.

Workspace API keys, service credentials, and per-run tokens have distinct prefixes and scopes. Stored rows contain a keyed HMAC-SHA256 digest and key ID, not the secret half. Comparison is constant-time, and an unknown identifier receives a dummy MAC operation.

Verification reads the database on each call and rejects missing, malformed, wrong-class, unknown, expired, revoked, wrong-audience, closed, replayed, and stopped credentials. Rotation can revoke the old credential immediately or after an explicit grace period.

KMS-backed or hardware-backed key custody and a tested operational key-rotation process remain planned. HMAC and sealing keys currently come from environment configuration.

Kill switches block new work and preserve operator access.

Global and per-workspace switches block new-run admission. A workspace stop also revokes its open run tokens, and releasing the switch does not revive them. The workflow checks admission before every post-run stage, so it does not release a result after a stop. API and console stop and release operations are permission-checked, and a stop does not end an operator's console session.

Production wiring from stop notifications to the active execution process remains planned. Immediate in-process cancellation is not a current production claim.

The audit log is append-only and tenant-scoped.

The application role receives only read and append grants. Row-level security has read and append policies but no update or delete policy. A trigger rejects update, delete, and truncate even for the table owner. Append and export use the caller's tenant context. Export is paginated in sequence order, emits JSON Lines, and is available through a permission-checked console download.

The central authorizer refuses a grant if its audit write fails. It attempts to record tenant-attributable refusals, while a refusal with no tenant to address has no tenant log.

Anomaly detection, alerting, a SIEM sink, and automatic log PII controls remain planned.

The product stores defined operational data.

• PostgreSQL identity, tenancy, session, credential, audit, and kill-switch records.
• Ticket bodies and replies, run state, transcripts, evidence, connector installations, and delivery history.
• Configured source metadata, versioned documents and logs, retrieval data, run evidence, and run envelopes.
• Approved browser origins, usernames, sealed login credentials, login procedures, screenshots, and capture metadata.
• Plans, entitlements, trials, billing-provider identifiers, usage counts, invoices, and verified provider webhook payloads. Card details are not billing-schema fields.
• Evaluation case sets, boards, comparisons, learning records, proposals, skill versions, and leakage findings.

The model proxy can write model usage and event JSON Lines files on the control host, and the launcher copies run results to a host result directory. When the webhook delivery log is configured, it can contain exact inbound headers, bodies, outcomes, customer content, and authentication headers.

Plaintext machine-credential secret halves, session cookies, CSRF tokens, and PKCE verifiers are not stored. Human identity-provider passwords are not received. Managed browser passwords are stored sealed. Model-provider keys currently come from the model proxy environment or credential file.

A retention schedule, scheduled deletion, a cross-store data inventory, and PII filtering for host JSON Lines files remain planned.

Encryption has application-level controls today.

OIDC discovery, model upstreams, and browser destinations enforce HTTPS outside loopback test exceptions. Recoverable auth secrets, connector secrets, and browser profile credentials are sealed with AES-256-GCM and context-bound additional authenticated data. Machine credential secret halves use HMAC-SHA256.

The model proxy adds provider credentials only while forwarding and does not return them to a run. Its current custody uses a deployment-wide key from an environment variable or file.

Evidence for public TLS, storage encryption, encrypted backups, KMS-backed keys, key-rotation operations, redemption audit, and restore drills remains planned.

Runtime deletion is tested, with known limits.

Credential, run-token, and session-family revocation applies on the next verification. Docker cleanup removes the run container, writable volume, and networks and checks their absence. Box cleanup deletes the per-run Box and checks its absence. The browser container is removed when its run session closes.

There is no organisation-deletion service or customer deletion flow today. Many tenant foreign keys cascade, but retained audit and workflow records can block a direct organisation delete, and no test proves complete deletion. Organisation and cross-store erasure, retention jobs, backup expiry, and physical media erasure proof remain planned.

EU-only service location is a deployment requirement.

The stated service location is EU-only. The stated production layout places the control plane on the production host and uses Box by ASCII EU boxes or Docker on that host for execution. The Box request does not select or attest a region, and no infrastructure configuration proves that the control-plane host is in the EU.

Automated region selection, region attestation, and a deployment test for the EU boundary remain planned. The repository does not prove the production deployment or its public network boundary.

Subprocessor data paths are disclosed.

The security record describes these integration paths:

• OpenAI. When selected, it receives the model request, prompt, supplied context, and provider credential. The proxy removes the run token before forwarding.
• Anthropic. When selected, it receives the model request, prompt, supplied context, and provider credential. The proxy removes the run token before forwarding.
• Box by ASCII. It receives the run bundle, prompt, optional run token, and run output while hosting a per-run executor.
• GitHub. The connector sends installation authentication and selected repository, issue, comment, and patch data.
• Stripe. When configured, it receives the billing contact email, organisation ID as metadata, customer and subscription IDs, plan, usage counts, invoice lines, and checkout URLs.
• Cloudflare. The stated production layout places public HTTP requests and connection metadata at its edge. The repository has no Cloudflare configuration or test. planned
• Robotomail. It receives mailbox addresses, email headers, bodies, attachments, and outbound replies for configured email connections.

Repository checks for processor region, contract, DPA, retention, and production configuration remain planned. Read the draft data processing agreement.

Independent assurance is not yet available.

An incident contact, incident response runbook, independent penetration test, production-environment control test, SOC 2 evidence, and DPA evidence are not yet available.

Questionnaire answers are direct.

• SSO.PartialOIDC authorization code and discovery are tested. SAML, live-provider validation, and GitHub console wiring are absent.
• MFA.PartialProvider assertion enforcement is tested. The console leaves the policy off, and Repro has no native MFA.
• Encryption in transit.PartialOIDC, model upstream, and browser HTTPS checks are tested. Public TLS deployment is not proved.
• Encryption at rest.PartialSelected recoverable secrets use AES-256-GCM. Disk, result, JSON Lines, and backup encryption are not proved.
• Backups.Not yetNo schedule, encrypted backup proof, restore procedure, or restore drill exists in the repository.
• Audit export.YesTenant-scoped JSON Lines export is tested and downloaded through the console.
• Deletion.PartialRuntime resource cleanup is tested. Organisation and cross-store deletion are absent.
• Incident contact.Not yetThe repository names no incident contact.
• Penetration test.Not yetThe repository contains no independent penetration-test report.