What we do, stated plainly — including what we don't do yet.

Tenant isolation

Every table carries a workspace_id and has PostgreSQL Row Level Security enabled. A signed-in user can only read rows belonging to a workspace they are a member of, and that is enforced by the database itself — not by front-end code, and not by an ORM that could be bypassed by a crafted request.

This is tested rather than asserted. A test suite creates two unrelated workspaces, signs in as each, and fails if either can see a single row belonging to the other — through any table, any view, or any function. It runs after every schema change, because a leak of this kind looks identical to a working system until someone checks.

API keys

Keys are stored as SHA-256 hashes with a short display prefix. The raw key is shown once, at creation, and is not recoverable afterwards — not by you, not by us, and not by anyone who obtains a copy of the database. If a key is lost, the only option is to revoke it and create a new one. Revocation takes effect immediately.

Test keys and live keys are separate. A sk_test_ key can never read live-mode orders; the scope is applied server-side on every request.

Provider credentials

Credentials for connected payment processors and suppliers are encrypted at rest with a key held in the database's vault, and the ciphertext never leaves PostgreSQL — decryption happens inside a function that the browser has no permission to call. The functions that can reach the vault are executable only by the service role, which is never present in any page we serve.

Moving money

Relay can issue refunds and cancel supplier orders. That is the one part of the system where a bug costs a customer real money, so the rules that govern it are database constraints, not application code. An Edge Function can be redeployed by anyone with dashboard access; a constraint in Postgres survives that.

• Off by default. Remediation is disabled per workspace until you switch it on. A workspace that has never considered it can never have money moved on its behalf.
• Approve first. A plan cannot reach the executing state without an approval, enforced by a status-machine trigger rather than an if statement. You can raise a per-flag ceiling to let small, well-understood fixes run automatically; an unbounded automatic policy is deliberately not expressible.
• Exactly once. Each plan has a unique key derived from the workspace, order, flag and action, and the same key is sent to Stripe. Proposing twice returns the original plan; a retry after a timeout returns the original refund instead of issuing a second one.
• Amounts come from the order. Never from the request body — so a caller asking to remediate an order cannot influence how much money moves.
• Customers cannot execute. Members propose and approve; only the service role executes. A customer cannot author a refund plan, and cannot mark one succeeded that never ran.
• Append-only history. Every transition is recorded with who and when, in a table with no update or delete policy for anyone.

These are asserted by an 18-check suite that runs against the schema, including a simulated double refund, an unapproved execution, and one tenant trying to approve another's fix.

Transport and infrastructure

Everything is served over HTTPS. The database and API run on Supabase (PostgreSQL) in a single region, currently US East. Backups are managed by Supabase. If your data must stay in a specific jurisdiction, tell us before you send anything — we would rather move the deployment than discover the constraint later.

Webhooks

Outbound deliveries carry an X-Relay-Signature header. Verify it before trusting a payload; the method is documented in the API reference. Inbound webhooks from providers are signature-verified with timestamp replay protection, and an unverified payload is recorded but never allowed to write orders or cash flow.

What is not in place yet

Relay is early, and pretending otherwise would be the least secure thing on this page.

• No SOC 2 or ISO 27001. No audit has been performed. If you need one to buy, say so and we will tell you honestly where that sits on the roadmap.
• No penetration test by an external firm.
• No SSO or SCIM. Sign-in is email/password, Google, or GitHub.
• No customer-managed encryption keys and no per-customer data residency.
• No formal uptime SLA except where one is written into a signed agreement.

Reporting a vulnerability

Email yduan2435@gmail.com with "security" in the subject, or use the contact form. We will acknowledge within two business days. Please give us a reasonable window to fix an issue before disclosing it publicly. We do not currently run a paid bounty programme, and we will not pursue anyone acting in good faith.

Last updated 1 September 2026. If something on this page stops being true, it is a bug — tell us.