Security & Compliance

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.

All API communication uses TLS 1.3 with perfect forward secrecy. Credentials are never transmitted in plaintext. Automatic certificate rotation and HSTS enforcement prevent downgrade attacks.

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.

// Every request requires multi-layer authentication
const request = {
  headers: {
    'X-KnoxCall-API-Key': 'kc_...',        // API key auth
    'X-KnoxCall-Client-ID': 'device-123', // Client tracking
    'X-KnoxCall-Route': 'stripe-charge'  // Route authorization
  }
};

// Automatic checks before proxying:
// 1. API key valid & not revoked
// 2. Client IP in allowlist (if configured)
// 3. Route exists & tenant has access
// 4. Rate limits not exceeded
// 5. Request signing validated (if enabled)

Every API request, credential access, and configuration change is logged with cryptographic integrity protection. Logs are append-only and retained for compliance requirements (30-365 days configurable).

KnoxCall injects the real provider credential at the egress wire — the moment the request leaves for Stripe or OpenAI, server-side, inside our proxy. Your app, CI runner, container, and function never receive it, and there is no value-GET path: nothing your workload can call returns the plaintext key. So the exposure paths every secrets manager leaves open are not mitigated — they are structurally absent, because there is nothing in your process to read.

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 short-lived token in its place.

// Secrets manager / .env / K8s Secret / Vault sidecar:
// the real key ends up live in your env, valid for years, usable from anywhere
process.env.STRIPE_SECRET_KEY = 'sk_live_51H...AbCdEf';  // readable by any code here

// With KnoxCall, the same process holds only this:
process.env.KNOXCALL_TOKEN     = 'kc_live_a_...';  // short-lived, scoped, DPoP-bound, revocable
process.env.STRIPE_SECRET_KEY = undefined;       // the real key never arrives

We don't ship security copy that won't survive a sharp review, so here is the precise boundary of the claim: