Security

A regulated team’s first question about any agent platform is some variation of “can I prove what happened?” If you can’t, the platform doesn’t get past procurement. SprintLoop was designed around that question. This page is the answer in detail — what gets signed, what gets stored, what your auditor sees, and what you bring yourself.

The threat model in one paragraph

We assume an attacker who has read access to a workspace user’s session, the public internet between you and our edge, and SprintLoop’s own infrastructure team’s laptops. We do not assume the attacker has access to your model provider’s signing keys, your git host’s branch protection, or your federation root key. The interesting security work is in keeping the second list valid even when the first list is compromised.

Provenance: what gets signed and stored

Every meaningful action in a SprintLoop workspace lands as a provenance entry — an append-only ledger row signed with Ed25519 over a BLAKE3 hash of the entry’s payload. Entries are chained: each entry’s signature includes the previous entry’s hash, so tampering with any historical entry invalidates every entry that follows it.

What’s signed:

• Lane lifecycle events: open, dispatch, scope claim, sign-off, close.
• Tool calls: file reads, file writes, shell commands, model invocations.
• Reviewer verdicts: every Architect / Security / QA / custom-reviewer decision.
• CI ingest: every status check from GitHub / GitLab.
• Federation events: chain heads stamped into the workspace root.
• Identity changes: invites, joins, role grants, token issuance, token revocation.

What’s not signed (deliberately):

• The contents of your source code. Provenance entries reference commit hashes — they don’t snapshot the tree. Your source stays on your git host.
• Model prompts and responses. The invocation (timestamp, model, token count, request hash) is signed. The body is stored encrypted, retrievable for 30 days, and deleted thereafter unless you’ve enabled extended retention.
• Personally identifiable details about workspace members beyond what’s needed for the invite chain.

Federation root and BYOK

The workspace’s chain head is signed daily into a federation root — a hash that’s published to a public timestamping service (currently Sigstore / Rekor) and to a customer-controlled S3 bucket if BYOK is enabled.

BYOK (“bring your own key”) flips the workspace to use a customer-controlled HSM for the federation root signature. The setup:

1. You provision an HSM-backed key (AWS KMS, Google Cloud HSM, Azure Key Vault).
2. Grant SprintLoop’s signer service kms:Sign on that key only — no kms:GetPublicKey, no kms:Decrypt.
3. The signer rotates daily. Every federation root signature carries the customer key’s identifier.

With BYOK enabled, even SprintLoop cannot sign a new federation root for your workspace if you revoke the key. That’s the point — it gives you a unilateral kill switch on your audit trail’s integrity guarantee.

Encryption at rest and in transit

• At rest: Postgres data is encrypted with AES-256-GCM at the storage layer. Workspace-scoped data (model logs, attachments, evidence bundles) is additionally envelope-encrypted with a workspace-specific KEK derived from the workspace handle. Cross-workspace key derivation is mathematically prevented by the HKDF salt.
• In transit: TLS 1.3 only. HSTS preload is in place for app.sprintloop.ai, api.sprintloop.ai, and docs.sprintloop.ai. Internal service-to-service traffic uses mTLS with short-lived certs (15 min TTL) issued by an internal CA.

Row-level security (RLS)

Every Supabase table that holds workspace data has RLS enabled with policies derived from auth.uid() and workspace_id. We test RLS via:

• A test suite that runs on every PR — creates two synthetic workspaces, asserts that user A in workspace X cannot read or write any row owned by workspace Y under any of the documented access paths.
• Periodic adversarial scans using supabase-pentest — currently 27 anti-patterns checked weekly.
• An internal red-team rotation where one engineer per quarter spends a week trying to bypass RLS from inside an authenticated session.

The full RLS schema is checked into the public repo. You can read every policy that governs your data without filing a support ticket.

Identity and access

SSO. SAML 2.0 and OIDC. Tested integrations: Okta, Auth0, Azure AD / Entra ID, Google Workspace, JumpCloud. Custom IdPs that conform to the spec work; we stake no claim that any specific custom IdP is supported.

SCIM. SCIM 2.0 for user and group provisioning. Same IdPs as above. SCIM-driven group changes propagate to workspace role membership within 60 seconds.

MFA. Required for all workspace owners. Optional but strongly recommended for members. WebAuthn (security keys, platform authenticators), TOTP, and recovery codes. SMS is not offered as an MFA factor.

Tokens. API tokens are scoped, expire (default 90 days, max 365), and are revocable. Tokens for editor extensions and MCP servers carry shorter default TTLs (30 days). All token issuance and revocation lands on the audit ledger.

Compliance status

Framework	Status	Notes
SOC 2 Type II	In progress (audit window opens 2026-Q3)	Type I report issued 2026-Q1; available under NDA.
ISO 27001	Planned 2026-Q4	Auditor selected; gap assessment underway.
HIPAA	BAA available on the Enterprise tier	Workspace-isolation review documented per BAA.
GDPR	Workspace-tier data residency in eu-west-1	DPA available; processor-of-processor relationships documented.
FedRAMP	Not in scope	Roadmap target 2027 if customer demand justifies.

For an evidence bundle (current SOC 2 Type I report, RLS schema, infrastructure diagram, BCP/DR plan, recent pentest summary), email security@sprintloop.ai from a domain associated with an active workspace.

Penetration testing

Independent third-party penetration tests are conducted twice a year (the most recent finished 2026-Q1). The summary reports — list of findings, severities, and remediations — are shared under NDA. We don’t publish the raw reports because they include details about internal infrastructure that aren’t useful for adversaries to know.

We also run a bug bounty program at https://hackerone.com/sprintloop. Findings under the standard disclosure program get acknowledged within 24h and triaged within 72h.

What you can do today

If you’re evaluating, three things are worth doing in the first hour:

1. Mint a test workspace and try to dispatch a lane. Note that every action shows up in the audit log; click into one and verify the signature is shown.
2. Open the audit-export endpoint with a test token and download a signed evidence bundle. Validate the signature with the workspace’s public key (linked from your workspace’s security settings page).
3. Check the federation root at https://federation.sprintloop.ai/<workspace-handle> — it shows the most recent stamped chain heads. The hashes there are the same ones in your audit export.

If those three checks pass, the rest of the security review is paperwork. If anything looks off, file a ticket — security findings get priority routing.

Reporting a vulnerability

security@sprintloop.ai (PGP key on the website footer) or via HackerOne. We do not pursue legal action against good-faith researchers acting under our published disclosure policy.