How controlled API access stays safe.
RelayKey exists because the business needs access to real systems, and engineering owns the risk when production keys spread. The real upstream key stays encrypted behind RelayKey; managers, analysts, applications, agents, vendors, and contractors get scoped RelayKeys you can audit, limit, expire, and revoke. We don’t claim zero-knowledge. We claim something more useful: an enforcement and containment layer between your real keys and every workflow that needs to use them.
Our trust model, in plain English.
What we hold.
Your real upstream API keys, encrypted at rest. We hold these because we have to: to forward a request to OpenAI, Anthropic, Grafana, Stripe, or an internal API, our proxy must decrypt the key in memory at the moment of forwarding.
What we do not store or inspect.
Request and response bodies are forwarded without being retained or inspected. Query strings are not logged unless you opt in per integration. Scoped RelayKeys are never stored in plaintext after creation: we store only their SHA-256 hash and verify by hash on every request.
What teams, tools, and agents see.
A short-lived, scoped RelayKey (rk_proxy_...). They can call the upstream API only via the methods, paths, and IPs you've allowed. They never see the real upstream key, never receive a refresh token, and lose access the moment you click revoke.
Composes with what you have. Replaces nothing you trust.
Most teams that look at RelayKey already use a secrets manager, an identity provider, and some form of access tooling. RelayKey is not a substitute for any of those — it’s the missing layer between them and the actual upstream API call.
| Tool / category | How it relates |
|---|---|
| HashiCorp Vault, Doppler, Infisical, AWS Secrets Manager | RelayKey composes with these — it does not replace them. Secrets managers answer “where does the production key live.” RelayKey answers “how does a tool, dev, or agent get scoped access without ever seeing that production key.” Keep your secret in Vault. Add it to RelayKey once. Mint downstream tokens for every consumer from there. |
| Keeper, 1Password Secrets, Bitwarden Secrets | Same pattern. These store credentials securely; RelayKey issues short-lived, scoped, revocable tokens against those credentials so you do not have to share the underlying secret with each consumer. They sit at different layers of the same stack. |
| Workload Identity Federation, OIDC short-lived tokens, OAuth scoped tokens | Use them where the upstream supports them. Anthropic, AWS, Google, and Stripe (via restricted keys) all offer versions of this and that is the right primitive when both ends support it. RelayKey is the bridge layer for the long tail of APIs that do not yet — HR, payroll, EHR, WFM, telephony, vertical SaaS, internal services — plus contractor and AI-tool access across fragmented systems where one workflow touches many APIs of mixed maturity. We’re not trying to replace native identity. We’re the compensating control where native identity is absent. |
| API gateways (Kong, Mulesoft, Apigee, Cloudflare) | Gateways front your own APIs to manage inbound traffic. RelayKey fronts outbound calls to upstream vendors and internal services on behalf of tools, agents, and people. Different direction, different job. They run side-by-side cleanly. |
| Privileged access proxies (Teleport, StrongDM, HashiCorp Boundary) | These broker infrastructure access — SSH, database, kube. RelayKey brokers HTTP API access. The mental model is similar; the surface area is different. Teams running Teleport for infra often want RelayKey for SaaS APIs. |
Threats we explicitly defend against, and how.
| Threat | Mitigation |
|---|---|
| Real API key leak from our database | Real upstream API keys are encrypted with AES-256-GCM using a separate encryption 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 integration 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 encryption 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. |
| RelayKey theft (rk_proxy_... leaks) | Human-held RelayKeys use new-IP confirmation: a stolen token used from an untrusted network returns 423 Locked before the upstream is reached. Application and service RelayKeys can be pinned to fixed IPs. If the attacker is already inside a trusted environment, method/path scope, expiry, rate policy, audit, and one-click revoke contain the damage without rotating the real upstream key. |
| 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. |
The controls behind approved access.
A snapshot of the controls in production, as of today. We update this list when behavior changes, not when we plan to change it. If a workflow needs stronger constraints before IT can approve it, ask us. We will tell you whether it’s weeks or quarters away.
| Control | Today |
|---|---|
| Encryption at rest | AES-256-GCM via a local-key envelope scheme (web/lib/crypto.ts). The encryption key (RELAYKEY_MASTER_KEY) lives outside the database in the platform secrets store. A KMS-backed envelope scheme stub exists for v1.1. |
| Encryption in transit | TLS 1.2+ at the Fly edge for every public hostname (relaykey.ai, app.relaykey.ai, proxy.relaykey.ai). Internally Caddy talks to Fastify over loopback only. |
| Failure mode (hosted proxy outage) | Hosted RelayKey is inline for proxied calls. If the hosted proxy is unavailable, RelayKeys fail closed: traffic does not bypass RelayKey and upstream keys are not exposed as a fallback. Critical workflows can run RelayKey self-hosted in your VPC, and teams should keep a break-glass upstream credential under their existing incident process. |
| Audit log scope | Every proxy call is logged with method, path, decision, status, duration, and source IP (IP normalized for shared egress). Every admin action is logged with actor, subject, and metadata in a separate admin_audit_events table. |
| Audit log retention | Plan-based: 7 days (Free), 30 days (Builder), 90 days (Team), 1 year (Business). Older rows are pruned by a scheduled job. |
| Authentication (dashboard) | Magic link with a 15-minute TTL and a click-through confirm step to defeat email-scanner prefetch. Sessions last 30 days. |
| Self-hosted deployment (data stays in your VPC) | Available. Same dashboard, audit log, and scoped-RelayKey model. The proxy and database run in your environment. RelayKey's cloud is contacted only for license validation; never for API traffic, vendor API keys, audit logs, paths, or request/response bodies. More on /self-hosted → |
| 2FA for API access (step-up auth on new IPs) | Default-on for human-held RelayKeys. The first IP that calls the proxy is auto-trusted (TOFU, like SSH known_hosts) so setup never friction-blocks; every new IP after that triggers an emailed confirmation link to the key holder. Until they click it, the proxy returns 423 Locked. The upstream is never reached. Confirmed IPs are stored per key holder and admins can revoke individual entries any time. Application and service RelayKeys can use fixed IP allowlists instead. |
| Authentication (management API) | rk_mgmt_... Bearer tokens with optional self-expiry, optional IP allowlist, and optional per-token method/path scope. |
| Role model | admin / viewer per workspace; mutations require admin. Provisioner-role management tokens get a tighter scope subset (mint scoped RelayKeys within fixed bounds, never read the upstream key). |
| Domain claim | Business email domains bind to one organization on first sign-up. Subsequent sign-ups on a claimed domain must be invited by an existing admin. |
| Data residency | Primary in ord (Chicago). Single region today; multi-region is a roadmap item. |
| Sub-processors | Fly.io (hosting), Resend (transactional email), Cloudflare (DNS only), Stripe (billing, when live), Google Analytics 4 (marketing site only). |
| Vulnerability disclosure | /.well-known/security.txt; contact [email protected]. |
Need to fill out a security questionnaire?
We will respond to a CAIQ, SIG, or your own custom security questionnaire within five business days. Send it to [email protected]. We do not currently hold SOC 2, ISO 27001, or HIPAA attestations. See the Compliance section below for where we are on that.
Where RelayKey is not the control.
- 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 that application holds, including the rk_proxy_... token your code is using. RelayKey limits what that token can do and lets you kill it without rotating the real upstream key.
- Inbound webhooks. RelayKey is outbound-only. Webhooks from your vendors continue to hit your endpoints directly. On the roadmap.
What every access grant logs.
By default, RelayKey logs request paths but not full query strings, request bodies, or response bodies. You can enable query string logging per integration if needed, with a warning that query strings may contain sensitive data.
For every proxied request, the audit log records:
- timestamp
- organization ID
- integration ID
- RelayKey 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 use real Cloudflare, Stripe, or Resend production keys day to day. They use scoped RelayKeys.
When we needed to wire up our DNS, our developer received a Cloudflare RelayKey scoped to a single zone, with dns_records paths only, expiring every seven days, IP-pinned to our deploy runner. The real Cloudflare token never left our dashboard. Every API call our developer makes is auditable in our own RelayKey audit log. The scoped key can be revoked at any time without touching Cloudflare.
We use this same pattern for every contractor, agent, internal workflow, 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 | Real key location | 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, and least-privilege secrets management. We 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 [email protected].
Report a vulnerability.
Email [email protected]. Standard 90-day disclosure window. We will respond within two business days. We do not currently run a paid bounty.