In-workload exposure
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 injects the real provider key at the egress wire, so it never enters your workload. Your code holds only a short-lived, scoped, revocable KnoxCall token.
The reframe
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 variables — readable 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 execution — an 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 dependencies — the 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 agents — Claude 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.
Every pattern, same ending
Every common way to ship a third-party API key into production lands the plaintext key inside your workload. KnoxCall is the only column that breaks the pattern — the provider key is injected at the egress wire and never arrives.
| Injection pattern | Where the live bearer key ends up | What KnoxCall changes |
|---|---|---|
Hardcoded .env |
Plaintext 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 secret | Decrypted 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 Manager | Exported to an env var or file after GetSecretValue; replayable with the workload's IAM role. |
No value-GET path. Injected at egress; there is no GetSecretValue for the third-party key to replay. |
| ECS task-definition secrets | Platform 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 sidecar | Rendered 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 memory | Plaintext string in process memory — readable by RCE, ptrace, or a core dump. | The key never enters the process, even briefly. |
| SSM Parameter Store | Same as Secrets Manager — lands in an env var or file at boot. | Injected at egress; nothing to fetch or replay. |
| Doppler / Infisical | An agent injects the secrets as env vars into the child process. | The real key is never returned to your workload — it's injected at egress, not handed back. |
| Baked into image / AMI | Persists in every image layer and registry copy, effectively forever. | No bearer key in the image. |
| Terraform / IaC | Written to state (plaintext in S3), CI logs, and TF_VAR_ env vars. |
The key never flows through IaC. |
| SDK / app config file | Plaintext 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.
The federation gap
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.
AWS, 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.
Stripe, 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.
KnoxCall closes exactly that gap from the other side: we hold the static vendor key, and hand your workload a short-lived, scoped KnoxCall token in its place — the egress-side equivalent of federation, for the keys federation can't reach.
What changes
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. There is no value-GET path in the client API — your code can route a request through KnoxCall, but it can never read the underlying key. The exposure paths a secrets manager leaves open aren't mitigated; they're structurally absent, because there is nothing in your process to read.
// 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
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.
The honest part
We don't ship security copy that won't survive a sharp review. Here is the precise boundary of the claim.
The third-party bearer key never enters your workload's memory or environment. There is no value-GET path that returns it, so it can't be read from an env var, /proc, a core dump, logs, an RCE, a poisoned dependency, or a prompt-injected AI agent.
KnoxCall removes one specific, high-value residual — the long-lived third-party bearer key — not the breach itself.
Until you revoke it, it can route requests through KnoxCall. The difference is the blast radius and the clock: that token is short-lived, scoped to specific routes, per-tenant, fully audited on every use, and DPoP sender-constrained (a stolen copy without the matching private key is inert) — versus a Stripe key valid for years and usable from anywhere on earth.
We 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.
In-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.
Why storage discipline isn't enough
Leak rate among organizations that have a dedicated secrets manager — because the manager's responsibility ends the instant it hands plaintext to the workload.
GitGuardian, State of Secrets Sprawl 2025New hardcoded secrets pushed to public GitHub in 2025 — up 34% year over year, the largest single-year jump on record.
GitGuardian, State of Secrets Sprawl 2025Of compromised machines in one analysis of 6,943 were CI/CD runners, not laptops — and each live secret appeared in roughly eight places on the same machine.
GitGuardian, State of Secrets Sprawl 2025Go deeper
What happens after GetSecretValue, and the downstream re-exposure it leaves you to handle.
Even a perfect Vault Agent sidecar still renders the key into the pod. Here's the marginal gain.
Encryption, zero-trust controls, DPoP-bound tokens, and audit logging in depth.
Point your client at KnoxCall; the key swap happens at our edge, not in your code.
Put KnoxCall in front of your third-party keys — strangler-fig, consumer by consumer.
Security posture, certifications, sub-processors, and incident history.