Security & Responsible Disclosure

Email security@trysalty.com with reproduction steps and any relevant details. Please give us reasonable time to remediate before public disclosure. Our machine-readable contact is published at https://trysalty.com/.well-known/security.txt (RFC 9116).

All traffic to the API, MCP server, and web app is served over TLS. Data at rest is encrypted by our infrastructure providers (database, hosting, and email).

Three bearer paths run through one auth middleware: sk_live_… API keys hashed with argon2id (looked up by a short prefix), OAuth salty_oat_… access tokens (SHA-256 at rest) issued via OAuth 2.1 with PKCE, and Supabase JWTs for the admin web app. Secrets are shown once and stored hashed; OAuth authorization codes are single-use and tokens rotate on refresh. Admin accounts can add a second factor — an authenticator app (TOTP) or a passkey (WebAuthn) — and API keys can be scoped read-only so an agent or tool can look but not change anything.

Every API query is scoped to the authenticated workspace, so one workspace cannot read or modify another’s data. Row-level security and locked-down database grants provide defense-in-depth at the data layer.

Deletes are reversible: a deleted record moves to a 30-day trash and can be restored, and there is deliberately no agent tool that hard-deletes — so an agent can’t irreversibly destroy your data. The database is covered by our provider’s managed backups, plus an independent nightly logical dump kept off-platform. You can export your full workspace as JSON, or delete your workspace entirely, at any time from the dashboard. See Your data, your control.

Outbound webhook payloads are signed with HMAC-SHA-256 using a per-endpoint signing secret and a timestamp, with a 5-minute verification window so receivers can reject replays. Delivery targets are validated to prevent requests to internal or private network addresses (SSRF), and inbound billing webhooks are signature-verified with constant-time comparison.

We never see or store full payment card details. Payments are handled by Dodo Payments as Merchant of Record, which is responsible for PCI-DSS-compliant processing of card data.

The service enforces per-workspace rate limits and usage caps, request size and input-validation limits, and security response headers (Content-Security-Policy, HSTS, X-Frame-Options) on the web app — the consent screen in particular is frame-protected against clickjacking. Credentials and tokens are scrubbed from logs and error reports, and email confirmation is required for new accounts.

Salty runs on managed providers (Supabase, Railway, Vercel, Cloudflare, AWS SES). See our Privacy Policy for the full subprocessor list. We connect to third parties (such as our payments provider) only over validated, TLS-protected connections.

In scope: the API (api.trysalty.com), MCP server (mcp.trysalty.com), CLI, and the marketing/admin site. Out of scope: volumetric denial-of-service, social engineering, spam/content reports, and the third-party services we depend on (report those to their vendors).

If you make a good-faith effort to comply with this policy during your research, we will consider it authorized, will not pursue legal action against you, and will work with you to resolve the issue. Avoid privacy violations, data destruction, and service degradation, and only interact with accounts you own or have permission to test.