The key never enters your workload.

Encryption at rest and in transit, immutable audit, and a structural difference most platforms can't offer: your third-party API keys never enter your own workload at all.

Start for free Trust Center
SOC 2 aligned HIPAA ready GDPR ready Current certification status is on the trust page.

Architecture.

Four controls, and what each one is made of.

  • AES-256 Encryption at Rest All API credentials are encrypted using AES-256-GCM before storage. Each tenant has a unique encryption key derived from a master key using HKDF. Even in the unlikely event of database compromise, credentials remain protected.
    • AES-256-GCM authenticated encryption
    • Unique initialization vectors (IVs) per credential
    • Per-tenant keys derived via HKDF from a master key
    • Master key rotation without service interruption
    • Secrets never stored or logged in plaintext
  • TLS 1.3 Encryption in Transit KnoxCall serves its dashboard and API over TLS, negotiating TLS 1.3 where the client supports it, and HSTS stops a browser falling back to plain HTTP. Calls to your upstream APIs use TLS whenever the route's target is an https URL. Certificates renew automatically.
    • TLS 1.3 wherever the client supports it
    • Forward secrecy on every TLS 1.3 connection
    • HSTS with a two-year max-age, including subdomains
    • Automated certificate management and renewal
  • Zero-Trust Architecture Every request is authenticated and authorized independently. No implicit trust based on network location. IP allowlisting, client identification, and route-level access controls ensure only authorized requests succeed.
    • Token valid & not revoked
    • Client IP in allowlist (if configured)
    • Route exists & tenant has access
    • Rate limits not exceeded
    • Request signing validated (if enabled)
  • Immutable Audit Logs Every proxied call is logged with its caller. Account and configuration changes go into a SHA-256 hash-chained audit log that is verified nightly; per-call records are attributed, not hash-chained. Retention runs from 7 days (Free and Starter) to 90 days (Enterprise).
    • Hash-chained audit of account and configuration changes
    • Request/response pairs with timestamps
    • IP address, user agent, and client identification
    • Configuration change attribution
    • SIEM-compatible log forwarding (Splunk, Datadog, ELK)
    • Real-time anomaly detection

It's not where your secret is stored. It's that it's in your process at all.

Encryption at rest protects the key in our database. But the question that decides your blast radius is different: once your app starts, where does the real Stripe, OpenAI, Twilio, or SendGrid key end up? Hardcoded in .env, injected at boot by AWS Secrets Manager or SSM, mounted as a Kubernetes Secret, or fetched just-in-time from a Vault sidecar — every path ends the same way: a live, long-lived bearer token sitting in your process memory or environment, readable by anything that runs there.

  • The key never enters your workload KnoxCall adds the real provider key at egress — as the request leaves for Stripe or OpenAI, server-side, inside our proxy. Your app, CI runner, container and function send a KnoxCall token instead, so each path below finds a revocable token, not the provider key.
    • Environment variables — printenv, ps auxeww, child-process inheritance
    • /proc/<pid>/environ — any local read of the process environment
    • Remote code execution — an RCE can't read a key that isn't there
    • Supply-chain dependency — a poisoned npm/pip package harvesting at install or runtime
    • Prompt-injected AI coding agent — an agent told to dump ANTHROPIC_API_KEY finds it absent
    • Core dumps and crash reports — no plaintext credential in the memory image
    • Verbose logs and error traces — the key was never a variable to accidentally log
  • The credential class you can't federate OIDC and workload identity were supposed to end long-lived keys — and for cloud they do. You can federate an AWS, GCP, or Azure access key away entirely. But Stripe, OpenAI, Twilio, SendGrid, and Anthropic issue static bearer tokens with no token-exchange endpoint, so that one credential class cannot be federated and is forced to live long-lived in your workload anyway. KnoxCall closes exactly that gap from the other side: we hold the static vendor key, and hand your workload a revocable token in its place.
  • What this does not do (the honest part) We don't ship security copy that won't survive a sharp review, so here is the precise boundary of the claim:
    • We don't stop your workload being compromised — we remove one high-value residual (the long-lived third-party bearer key), not the breach itself.
    • A KnoxCall token still lives in your workload; until you revoke it, it can route requests through KnoxCall.
    • The honest delta: that token is revocable, per-tenant and audited on every use. On the OAuth path it is short-lived, it can be limited to the routes you grant it, and you can bind it to its sender with DPoP, so a stolen copy is useless without the private half — versus a Stripe key valid for years and usable from anywhere on earth.
    • KnoxCall becomes a trust dependency and adds a network hop — the same tradeoff you already accepted when you federated your cloud keys. Scope is the outbound third-party bearer key; your database credentials and app encryption keys are out of scope.

Compliance checklist.

Here's what KnoxCall automatically handles for your compliance requirements. The framework names below are control mappings — the requirement each control speaks to — not attestations KnoxCall holds. Our current certification status is on the trust page.

  • Credential Blast-Radius Minimization (Maps to: SOC 2 CC6.1 / CC6.6, PCI-DSS 3.x & 8.x) Third-party provider keys are added at egress and are not handed to your application, CI or containers, so a workload compromise finds a KnoxCall token rather than a long-lived vendor credential. Those tokens can be revoked from the dashboard; on the OAuth path they are short-lived, and they can be limited to the routes you grant them and bound to their sender with DPoP.
  • Credential Encryption at Rest (Maps to: SOC 2, PCI-DSS, HIPAA) AES-256-GCM envelope encryption under a per-tenant master key. On Enterprise, bring your own key through AWS KMS, Google Cloud KMS or Azure Key Vault.
  • Access Control & Authorization (Maps to: SOC 2, HIPAA, GDPR) Role-based access control (RBAC), IP allowlisting, and client-level restrictions. Audit trail shows who accessed what and when.
  • Audit Logging (Maps to: SOC 2, PCI-DSS, HIPAA, GDPR) Every proxied call logged with its caller; account and configuration changes in a hash-chained audit log, verified nightly. Retention from 7 days (Free and Starter) to 90 days (Enterprise).
  • Data Residency (Maps to: GDPR, Some HIPAA) Hosted in a single region today; regional residency is not offered.
  • Incident Response (Maps to: SOC 2, PCI-DSS) Real-time alerts for suspicious activity, rate limit violations, and authentication failures. Multi-channel notifications (Email, SMS, Slack).
  • Right to Deletion (Maps to: GDPR) Close your account from the dashboard and request erasure of your routes, credentials and account data. Records in our security audit chain are retained.
  • Penetration Testing (Maps to: SOC 2, PCI-DSS) Dependabot, CodeQL and container scanning on every pull request. An independent third-party penetration test is scoped; the tester is not yet engaged. We will publish the assessment summary once the test completes.
  • Business Associate Agreement (Maps to: HIPAA) BAA available for healthcare customers upon request. Sensitive field masking in audit logs and encrypted credential storage for healthcare API integrations.

And the rest.

Twelve more controls, each one already in the product.
Read the AI Gateway brief →

  • Automated OAuth Token Refresh OAuth2 tokens are automatically refreshed 5 minutes before expiration. Refresh tokens are encrypted and stored separately from access tokens. Supports Google, Microsoft, Salesforce, and custom OAuth2 providers.
  • Rate Limiting & DDoS Protection Configurable rate limits per route, per client, or globally. Automatic DDoS mitigation with challenge-response for suspicious traffic patterns. Cloudflare integration for additional protection.
  • Request Signing & Verification HMAC-SHA256 request signing prevents tampering and replay attacks. Configurable signature headers and nonce validation ensure requests are fresh and authentic.
  • Per-Tenant Master Key (KCT1) Every tenant gets its own master key. Crypto Keys, Vault tokens, webhook secrets, and ephemeral payloads are envelope-encrypted under it. Bring-your-own-key (BYOK) via AWS KMS, GCP KMS, or Azure Key Vault on Enterprise. Cryptographic erasure: destroy the master key and every dependent ciphertext becomes permanently unreadable.
  • Asymmetric Crypto + JWT Crypto Keys v2 supports RSA-2048/3072/4096, ECDSA P-256/P-384, and Ed25519. Sign JWTs (RS256, ES256, EdDSA) with full alg-confusion defence: alg:none rejected unconditionally, header alg bound to key type, kid bound to verification version. Public keys exportable as PEM and JWK.
  • Format-Preserving Tokenization Vaults swap SSNs, emails, bank details, and other sensitive columns for tokens that pass the same validation as the originals — SSN tokens that always start with 9XX (never collide with real SSNs), email tokens with domain preserved for analytics, format-preserving tokens for fixed-shape columns. Drop-in replacement for sensitive columns, with no schema changes.
  • Webhook Signature Verification + Replay Protection Inbound webhooks from Stripe, GitHub, Slack, AWS-SNS, or custom HMAC schemes are verified at the edge using constant-time comparison. Formats with timestamps (Stripe, Slack) enforce a configurable replay window (default 300s, capped 86400s). Failed verifications audit with the precise reason code: replay_window_exceeded, no v1 signature matched, etc.
  • SSRF Defence on Every Egress Routes, Ephemeral Proxy, and inbound-webhook forwarding all share the same SSRF guard: hostname must resolve publicly, private (RFC1918) / link-local / loopback / metadata-IP (169.254.169.254) addresses blocked. DNS-pinning prevents TOCTOU rebinding attacks. The Ephemeral Proxy and inbound-webhook forwarding accept https targets only.
  • AI Gateway: Capability Keys, Per Agent and Per Environment Every AI Gateway agent issues kp_live_a_… capability keys, minted for that agent in one environment. Each carries a capability scope HMAC'd under your tenant master key and re-derived on every call before any upstream request, so a key whose scope has been altered is refused. Choosing what goes in that scope — provider, model, max-cost-per-day, IP CIDRs, time windows — is not shipped yet: keys mint unscoped, and the load-bearing controls today are short TTLs, the agent's own budget and model policy, DPoP binding, per-call audit and revocation. Bind a key to a keypair you hold and RFC 9449 DPoP makes a copied token inert without the matching private half. A kp_test_ key cannot reach a Live route.
  • Streaming PII Redaction (HIPAA / PCI / GDPR) Per-stream finite-state machine + 96-char sliding hold-back buffer detects PII spanning SSE chunk boundaries before any part of it leaves the gateway. The synchronous stack is a canary automaton plus regex-with-checksum rules (SSN, PAN/Luhn, IBAN/mod-97, email, E.164, JWT, and live provider API keys); name- and location-style entities use an optional Microsoft Presidio sidecar you host, which runs on the buffered path. Reversible mode swaps each value for a shape-preserving token and keeps the original AES-256-GCM envelope-encrypted under your per-tenant key — the LLM only ever sees the token; your caller sees the original PHI.
  • HIPAA / PCI / GDPR Compliance Packs One-operation installs for HIPAA Safe Harbor, PCI-DSS, GDPR and SOC 2: each pack wires that regime's alert rules and records the install as auditor-readable evidence, and the installer reports exactly what it wired, what it skipped, and that retention automation is still pending. Every redaction logs the entity type, which detector fired, the action and the direction — never the plaintext value.
  • Prompt-Injection Screening + Canary Leak Detection Heuristics screen every prompt for "ignore previous instructions"-class injection in microseconds and record each match as a firewall event. Per-tenant deterministic canary tokens injected into system prompts raise a critical ai_gateway.canary_leak audit event if the model echoes one, and the response is withheld from the cache.

Store. Proxy. Revoke.

Free for seven days. No card. Your first call in minutes.

Start for free Talk to us
All systems operational