Trust · security

Security.

Relay sits between AI agents and third-party APIs and stores credentials on your behalf. Every design decision here optimizes for keeping those credentials out of attacker hands without making the product unusable for agents.

Encryption at rest

Every credential column (third-party API keys, tenant webhook signing secrets, pending-account credentials) is encrypted at the application layer with AES-256-GCM. Each ciphertext carries a 12-byte random nonce and a 16-byte authentication tag. The master key is a 32-byte secret stored in Vercel environment variables and never logged or committed. A key_version column on every encrypted table makes rotation to a v2 master key possible without a migration window.

Encryption in transit

TLS 1.2+ on every public endpoint. HTTP-to-HTTPS redirects handled by Vercel's edge. HSTS with a year-long max-age and preload.

Authentication

  • Human sign-in — passwordless email OTP + WebAuthn passkeys. No password storage; no password reset email path.
  • Agent tokens — stored as SHA-256 digests. The plaintext is shown exactly once at mint and never again. Revocation is a server-side flag that invalidates the row immediately.
  • Integrator webhooks — outbound calls carry an X-Relay-Signature: sha256=…header HMAC-ed with the tenant's per-product secret. Integrators MUST verify this before acting.
  • Inbound email — SendGrid Inbound Parse posts to /v1/webhooks/email?secret=…. Any value mismatch returns 401 and drops the payload.

Audit log

Every mutation by an authenticated caller writes an audit_log row with actor, action, target, timestamp, and contextual metadata. Supported events include signup_create, key_create, key_reveal, key_deliver, account_delete, tenant_create, admin.raise_signup_limit, and all billing state changes. Rows are append-only; deletes are prohibited at the application layer.

Rate limits

  • Per-token API limits — 60 writes/min and 300 reads/min (best-effort, per-instance on Vercel Fluid Compute). Designed to catch runaway agents rather than act as a hard quota.
  • Per-user monthly signup cap — default 50/month. Breaches are logged and, in enforce mode, return HTTP 429. Ops can raise the ceiling per user via the admin API.
  • Integrator action quota — enforced atomically on dispatch for every billable action (signup / reveal / rotate / delete); overage queues per-action invoice items for monthly flush.

Observability

Sentry captures unhandled errors and rate-limit breaches; a pino structured logger writes JSON to Vercel logs. Sensitive headers (authorization, cookie) and token fields are redacted before leaving the process.

Multi-tenant isolation

Every resource row carries tenant_id and/or user_id; every authenticated route validates both before reading or writing. Cross- tenant reads are an automatic test target; we are planning Postgres row-level security as a belt-and-suspenders layer post-launch.

Vulnerability reporting

Report security issues to security@cumulush.com (PGP key on request). We acknowledge within 48 hours and patch critical issues within 7 days. See the full policy in SECURITY.md on the repo.

Compliance roadmap

We are targeting SOC 2 Type I in Q4 2026 with a Type II report to follow the subsequent audit period. GDPR and CCPA data-subject rights are honored today; contact privacy@cumulush.com. A Data Processing Agreement (DPA) is available to any paying integrator on request.

Source-availability

Relay's service code is closed source. The Cumulus creator package and generated app templates are MIT-licensed so any integrator can audit, fork, or pin the code that handles webhooks, signs requests, and brokers the Relay handshake on their side. Everything else (provider adapters, signup workflows, key storage, billing, dashboards) is proprietary and runs only on Relay's infrastructure.