Skip to content

Your data, fenced in.

How Suture handles your traces, your code and your keys. This page describes how the product is built. It is not a certification, and we have no SOC 2 report yet.

( 01 )

What we store

in place
  • Traces, verdicts, Issues and fix runs live in Postgres. Each trace is stored after redaction, inside the database, because grouping and replay need the whole conversation and the recorded tool outputs. Moving large payloads to separate object storage is planned.
  • Your tracer stays the system of record. Suture keeps its own redacted copy so it can group failures and replay them.
  • Suture never asks you to paste keys into chat or plain-text fields. Connector keys are stored encrypted.
( 02 )

Redaction at ingest

partial
  • Emails, phone numbers, card numbers, IBANs, API keys and tokens, IP addresses and US Social Security numbers are redacted as traces arrive, before anything is written. So are Nigerian BVN, NIN and bank account numbers when they are labelled.
  • Names and street addresses are not caught by these rules. They need an entity-recognition step, which is optional and off by default, so treat names and addresses as stored as sent.
  • Redacted values are replaced with typed markers, like [REDACTED:email], so diagnosis still makes sense.
  • The original values are not stored. There is no map back to them.
( 03 )

Model providers

in place
  • Checks, diagnosis and fixes run on third-party hosted models: Jev by TypeSafe, and language models reached through OpenRouter.
  • They receive redacted trace text and, during a fix, the repository files the fix reads. Nothing is sent to them before redaction.
( 04 )

Tenant isolation

in place
  • Every tenant table carries an organisation id and has Postgres row-level security turned on.
  • Automated tests prove one organisation cannot read or change another organisation’s rows.
  • Background workers write traces under the same row-level security, one organisation at a time. A few internal jobs, like expiring buffered spans, run on a privileged connection.
  • Nexprove superadmins can see every organisation in an internal console. Every change they make is written to an audit log.
( 05 )

Sandboxed fixes

in place
  • The fix agent works in a short-lived sandbox with a fresh clone of your repo. Your code runs only after the sandbox is cut off from the network, and the sandbox is destroyed after the run.
  • Each PR is scoped to one Issue and may not touch files unrelated to the diagnosis. Dependencies, lockfiles, CI config and env files are never in scope.
  • GitHub access goes through a GitHub App with the permissions you grant per repository, never a personal token.
( 06 )

Replay without side effects

in place
  • Verification never calls your real tools. Replays use the tool outputs recorded in the original trace.
  • An unknown tool returns a stub, and that case is marked partially verified in the PR.
  • Each replay runs three times and the majority result counts, so model randomness is not mistaken for a fix.
( 07 )

Opt-in pattern sharing

planned
  • Off by default, per organisation. The pipeline that shares patterns is not running yet, so today nothing is shared.
  • When it runs, only anonymised patterns from organisations that opted in will be shared: failure type, model, fix template and outcome. Raw prompts, outputs, traces and code are never part of a pattern.
  • Once paid plans launch, opting in will take 20% off. Suture is free during the beta, so there is nothing to discount yet.
( 08 )

Self-host, SSO and residency

planned
  • Self-hosting with Docker or Helm, SSO / SAML and data residency are planned for the Enterprise plan.
  • Until then, Suture is a hosted service.