How RelayKey protects your master keys.
RelayKey is built so that the people who use your master API keys never see them. We handle that transition with the same trust model Stripe uses for your card numbers and Doppler uses for your secrets — encrypted at rest, decrypted only at the moment of use, with strict scope and full audit. We don’t claim zero-knowledge. We claim something more useful: a tightly bounded, auditable, revocable layer between your keys and the people who need to use them.
Our trust model, in plain English.
What we hold.
Your upstream API keys, encrypted at rest. We hold these because we have to — to forward a request to ElevenLabs (or HubSpot, or Salesforce), our proxy must decrypt the key in memory at the moment of forwarding.
What we never see.
Your request and response bodies. Your query strings (unless you opt-in per connection). Your delegated credentials in plaintext after creation — we store only their SHA-256 hash and verify by hash on every request.
What your vendors and contractors see.
A short-lived, scoped proxy token (rk_proxy_…). They can call the upstream API only via the methods, paths, and IPs you've allowed. They never see your master key, never receive a refresh token, and lose all access the moment you click revoke.
Threats we explicitly defend against, and how.
| Threat | Mitigation |
|---|---|
| Master key leak from our database | Master keys for upstream APIs are encrypted with AES-256-GCM using a master key (RELAYKEY_MASTER_KEY) that lives outside the database. In production this key is provided by the platform secrets store (Fly secrets at v0; AWS KMS / GCP KMS at v1). A SQL dump alone is not sufficient to decrypt customer keys. |
| Server compromise (RCE) | RelayKey’s proxy intentionally has minimal attack surface. We do not parse JSON bodies. We do not render user-supplied HTML. We do not execute customer plugins. We pin all dependencies via lockfile and avoid post-install scripts. SAST runs on every change. |
| Stolen audit logs | Audit logs are encrypted at rest using the same envelope encryption pattern. By default we record paths only — not query strings, not request bodies, not response bodies. Customers can opt into query string logging per connection with a written warning that query strings can carry sensitive data. |
| Insider threat (RelayKey employee) | Production database access is break-glass-only and itself audited. For enterprise customers we offer customer-managed master keys (BYOK) so even a compromised RelayKey employee cannot decrypt your upstream keys without your KMS approval. |
| Supply chain (malicious dependency) | We use a strict lockfile, ignore post-install scripts, run dependency audits on every commit, and minimize transitive dependencies. The proxy data plane has fewer than 30 direct dependencies. |
| Token theft (vendor leaks rk_proxy_…) | Delegated credentials default to GET-only, 24-hour expiration, and an explicit path allowlist. Customers can additionally pin credentials to specific vendor IPs. A leaked token is therefore narrow in time, narrow in scope, narrow in reach — and revocable in a single click. |
| Side-channel timing attacks on tokens | Token lookups are by SHA-256 hash, not by token equality. We never compare plaintext tokens. |
| Replay attacks | All requests are forwarded with HTTPS to the upstream. The proxy does not store request bodies or response bodies, so there is nothing to replay from our side. Upstream vendors’ replay protections (e.g. Stripe’s idempotency keys) continue to work normally. |
What we don’t yet defend against.
- Compromise of the upstream vendor. If ElevenLabs is breached, RelayKey doesn't help. We're a layer in front of the vendor, not a replacement for the vendor's security.
- Compromise of your own client. If your application server is compromised, the attacker has access to whatever credentials your app holds, including the rk_proxy_… token your code is using.
- OAuth refresh flows. RelayKey v1 proxies bearer-token and x-api-key REST APIs. We do not yet proxy OAuth refresh — your app refreshing tokens directly with the IdP bypasses our audit. On the roadmap.
- Inbound webhooks. RelayKey is outbound-only. Webhooks from your vendors continue to hit your endpoints directly. On the roadmap.
- Request signing (e.g. AWS SigV4). Re-signing requests on the way out is on the roadmap.
- Streaming / long-lived SSE responses. The proxy buffers responses up to 10MB. Long-lived streams need a different code path. On the roadmap.
What we log.
By default, RelayKey logs request paths but not full query strings, request bodies, or response bodies. You can enable query string logging per connection if needed, with a warning that query strings may contain sensitive data.
For every proxied request, the audit log records:
- timestamp
- organization ID
- connection ID
- delegated credential ID
- method
- path
- allowed/blocked decision
- block reason
- status code
- IP
- user agent
RelayKey is built on RelayKey.
The simplest way to know we take this seriously: RelayKey’s own developer doesn’t have a master Cloudflare token, master Stripe key, or master Resend key. They have RelayKey credentials.
When we needed to wire up our DNS, our developer received a Cloudflare credential scoped to a single zone, with dns_records paths only, expiring every seven days, IP-pinned to our deploy runner. The master Cloudflare token never left our dashboard. Every API call our developer makes is auditable in our own RelayKey audit log. The master token can be revoked at any time without touching Cloudflare.
We use this same pattern for every contractor, agent, and external service we work with. The day we have to break that pattern is the day we have a real bug to fix.
| Service | Master key holder | Access pattern for collaborators |
|---|---|---|
| Cloudflare | Founder, in RelayKey | rk_proxy_… to cloudflare/zones/{zone}/dns_records, 7d TTL, IP-pinned |
| Resend | Founder, in RelayKey | rk_proxy_… to resend/emails, 24h TTL, send-only |
| Stripe | Founder, in RelayKey | rk_proxy_… to read-only Stripe endpoints, 24h TTL |
| Production database | KMS-managed, app-only | No human direct access |
Compliance.
RelayKey is a young company. We are not yet SOC 2 Type II certified. We have built RelayKey from day one in line with SOC 2-relevant controls — encrypted at rest, audit logging, access controls, least-privilege secrets management — and intend to pursue formal certification once we have the operational history to support it.
Customers in regulated industries can request a security questionnaire response and a DPA. If you need a signed DPA, BAA, or SOC 2 questionnaire response, email security@relaykey.ai.
Report a vulnerability.
Email security@relaykey.ai. Standard 90-day disclosure window. We will respond within two business days. We do not currently run a paid bounty.