Security and trust.
This page describes the security practices that are actually in place in Suede Agent Studio today — no more, no less. Where a formal certification is not yet in place, we say so plainly on this page rather than leaving you to guess.
Where we stand on certifications
Suede Agent Studio is not SOC 2, HIPAA, or ISO 27001 certified. Those require a third-party audit engagement, and we will claim them the day they are real and not before. If your procurement process requires a certification we do not yet hold, tell us — we would rather have that conversation directly than have you find out later. Everything below is a current, factual description of how the product handles your data and money.
How your data moves
Traffic to agents.suedeai.ai is served over HTTPS. The first-party cookie that identifies your workspace is set HttpOnly and Secure in production, so it is never exposed to page scripts and never sent over plain HTTP. Agent runs that call third-party model providers do so over the provider's own encrypted APIs.
How your data is stored and separated
Every request is scoped to a workspace owner before it touches storage. Ecosystem-authenticated identities are only ever derived from a verified session — they are explicitly rejected when presented as a raw header or cookie value, so no one can claim another signed-in user's workspace by guessing an id. If a request ever arrives without a resolvable owner in production, the request fails closed rather than pooling into a shared account.
Workspace data lives in Supabase (managed Postgres) behind row-level security. The application reaches it through a server-only request secret; direct browser traffic cannot read or write those tables, and the runtime role has no DELETE privilege on them.
Secrets and credentials
Platform secrets — model keys, the payment signer, the connection encryption key — live in the deployment environment and are never committed to source. When you store a third-party credential as a Connection, it is encrypted with AES-256-GCM before it is written, cryptographically bound to your workspace and that specific connection so a ciphertext cannot be replayed under a different identity, and the plaintext is wiped from memory immediately after use. When you launch a webhook-triggered agent, its signing secret is generated from a cryptographically secure random source, stored only as a hash, and shown to you exactly once.
How payments are verified
Paid calls use the x402 standard: a caller's wallet signs a USDC payment on Base, and the endpoint verifies it before doing any work. Before a payment is ever forwarded for settlement, Suede independently checks that the signed authorization pays the correct wallet, for at least the required amount, on the supported network — a definitively invalid payment is rejected locally, not passed through. Settlement defaults to dry-run: a newly launched agent does not move real money until its creator explicitly switches it live. Payouts route 95% to the creator's own wallet; Suede never custodies creator funds. Settlement happens on a public blockchain, so payment amounts and wallet addresses are visible on-chain by the design of the network.
Abuse and spend controls
Inbound webhook calls must carry a valid HMAC-SHA256 signature and a recent timestamp — signatures are compared in constant time and stale or replayed requests are rejected. Rate limiting and per-IP token budgets throttle abusive traffic, the free tier is gated so a freshly minted key cannot farm funded model capacity, and every run enforces a hard per-run spend ceiling so a single flow cannot run up an unbounded bill. Outbound calls Suede makes to a creator's own server are themselves HMAC-signed so the creator can verify they genuinely came from Suede.
You are not locked in
Any flow exports to TypeScript with the Suede SDK, so your engineers can read, own, and self-host the exact logic. Creator payouts go to a wallet you control. Reported agents can be taken down, and you can request deletion of a workspace and its data at any time from the account and data deletion page.
Reporting a vulnerability
Found a security issue? Email security@suedeai.ai. Our machine-readable disclosure policy lives at /.well-known/security.txt. We read these directly and typically reply within one business day. Please do not publicly disclose an unpatched issue before we have had a chance to respond.
What we're working toward
The following are on our roadmap and are not in place today. We list them so you know the direction, not so you count them as shipped:
- A formal third-party security audit (the path toward SOC 2 Type II).
- Globally-coordinated rate limiting (today's limits are effective but enforced per running instance).
- A dedicated key-management service (KMS/HSM) backing secret storage, and rotatable, regenerable webhook secrets.
- SSO/SAML, exportable audit logs, and a signed Data Processing Addendum for enterprise buyers.
Enterprise buyers who need a DPA, a completed security questionnaire, or a deeper architecture review can reach us at security@suedeai.ai and we will work through it with you.
Last updated .