The key was never in the vault. It was in your process.

Hardcoded .env, AWS Secrets Manager at boot, a Kubernetes Secret, a Vault sidecar — every path ends with the same live third-party key sitting in your running process, where an RCE, a poisoned npm install, or a prompt-injected AI agent can read it. KnoxCall adds the real provider key at egress, as each call leaves, outside your workload. Your code holds only a revocable KnoxCall token, short-lived on the OAuth path.

A secrets manager picks a safer place to keep the key. It still hands it to your code.

The industry has spent a decade arguing about where to keep API keys — out of git, into a vault, injected at boot. But the storage location was never the exposure. The moment your app starts, the real Stripe, OpenAI, Twilio, or SendGrid key ends up live in your process memory or an environment variable, because that's the only way your code can read it to make the call. A secrets manager's job ends the instant it hands you that plaintext. From there, anything running in the process can read it:

  • Environment variablesReadable via printenv, ps auxeww, child-process inheritance, and /proc/<pid>/environ. OWASP's Secrets Management Cheat Sheet and the CNCF Cloud Native Security Whitepaper both explicitly recommend against env vars for secrets.
  • Remote code executionAn RCE foothold reads the env, the mounted secret file, or a core dump directly. The key being “encrypted at rest” in your vault does nothing once it's plaintext in the process.
  • Poisoned dependenciesThe 2025 Shai-Hulud npm worm harvested credentials at install time. One compromised package in your tree, and every key in that process walks out.
  • Prompt-injected AI agentsClaude Code, Gemini CLI, and Copilot have all been shown dumping ANTHROPIC_API_KEY and GITHUB_TOKEN straight from process env after a single prompt injection. An AI coding agent runs with your environment; if your provider key lives there, a malicious doc can make the agent read it out.

Where the live key actually ends up.

Every common way to ship a third-party API key into production lands the plaintext key inside your workload. The right-hand column is what changes with KnoxCall: the provider key is added at egress, as each call leaves, and your workload holds a revocable token instead.

  • Injection patternWhere the live bearer key ends upWhat KnoxCall changes
  • Hardcoded .envPlaintext on disk and in process.env for the life of the process.Never written into your workload. Routes reference the key by name; KnoxCall holds the value.
  • GitHub Actions secretDecrypted into the runner's env for the job — readable by every step, action, and dependency.OIDC workload identity → short-lived token; no provider key stored in the repo or job.
  • AWS Secrets ManagerExported to an env var or file after GetSecretValue; replayable with the workload's IAM role.Injected at egress. Your workload never calls GetSecretValue for the third-party key.
  • ECS task-definition secretsPlatform injects plaintext env vars into the container at boot — AWS's own docs warn of this.No plaintext in the task def or the container environment.
  • Kubernetes Secret (env)base64-encoded in etcd (not encrypted; etcd encryption-at-rest is off by default); plaintext env at pod start.Not stored as a K8s Secret at all.
  • Vault Agent sidecarRendered to a tmpfs file the app reads; the Vault token is replayable until its TTL.The bearer key never renders into the pod — only a KnoxCall token does.
  • JIT fetch into memoryPlaintext string in process memory — readable by RCE, ptrace, or a core dump.The key is added at egress; the process holds a KnoxCall token instead.
  • SSM Parameter StoreSame as Secrets Manager — lands in an env var or file at boot.Injected at egress; nothing to fetch or replay.
  • Doppler / InfisicalAn agent injects the secrets as env vars into the child process.The real key is injected at egress, not into the child process's environment.
  • Baked into image / AMIPersists in every image layer and registry copy, effectively forever.No bearer key in the image.
  • Terraform / IaCWritten to state (plaintext in S3), CI logs, and TF_VAR_ env vars.The key never flows through IaC.
  • SDK / app config filePlaintext file on disk, exposed by path-traversal CVEs and backups left in the web root.Config holds a route reference, not the key.

What KnoxCall does not change in any row: your workload still holds a KnoxCall token, and a compromise can abuse it to route requests through KnoxCall until you revoke it. KnoxCall doesn't stop the breach — it removes the long-lived third-party bearer key as the thing a breach can steal. The honest tradeoff is detailed below.

You federated your cloud keys. You can't federate your Stripe key.

OIDC and workload identity were supposed to end long-lived keys — and for cloud, they did. Federation works because AWS, GCP, and Azure each run a token-exchange endpoint that trusts your OIDC issuer, so your workload can hold a short-lived federated identity instead of a static access key. But that mechanism needs the vendor on the other end.

  • Solved by federationCloud provider keysAWS, GCP, Azure. They run an STS / token-exchange endpoint, so you can federate the access key away entirely — the workload holds a short-lived identity, never a static cloud key.
  • No way to federateThird-party SaaS bearer keysStripe, OpenAI, Twilio, SendGrid, Anthropic. They issue static bearer tokens with no token-exchange endpoint — there is nothing to federate to. So this entire credential class is forced to live long-lived in your workload, no matter how good your secrets hygiene is.
  • What changesThe key never enters your workloadKnoxCall closes exactly that gap from the other side: we hold the static vendor key, and hand your workload a revocable KnoxCall token in its place — the egress-side equivalent of federation, for the keys federation can't reach. Your client calls KnoxCall instead of calling Stripe directly. KnoxCall injects the real provider key into the outbound request server-side, at the egress wire, so the request your code sends carries the KnoxCall token, not the provider key.For providers where KnoxCall mints the key through the provider's own admin API, rotation can retire the original entirely. For a key you paste in yourself, rotate it once through KnoxCall and revoke the original at the vendor — after that, only KnoxCall holds a live copy.

What this does — and doesn't — do.

We don't ship security copy that won't survive a sharp review. Here is the precise boundary of the claim.

  • What's trueThe third-party bearer key is added at egress, outside your workload, so it is not in an env var, /proc, a core dump or your logs for an RCE, a poisoned dependency or a prompt-injected AI agent to read.
  • We don't stop your workload being compromisedKnoxCall removes one specific, high-value residual — the long-lived third-party bearer key — not the breach itself.
  • A KnoxCall token still lives in your workloadUntil you revoke it, it can route requests through KnoxCall. The difference is the blast radius and the clock: 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 matching private key — versus a Stripe key valid for years and usable from anywhere on earth.
  • KnoxCall is a trust dependency, and adds a hopWe become a point in your request path and a high-value target. We acknowledge that rather than hide it — it's the same architectural tradeoff you already accepted when you put a secrets manager, an IdP, or an OIDC issuer on your critical path. We just extend it to the keys federation can't reach.
  • Scope is the outbound third-party bearer keyIn-process database credentials and your application's own encryption keys are out of scope — a secrets manager still has a job. KnoxCall's wire injection targets the static SaaS keys you call out to.

The numbers.

Why storage discipline isn't enough. Each figure is the source's, linked.

Store. Proxy. Revoke.

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

All systems operational