KnoxCall vs Google Secret Manager

Be honest with yourself about the shape of your stack. If everything you run lives in GCP — GKE, Cloud Run, Cloud Functions — and your threat model is well served by IAM-gated, versioned, CMEK-encrypted storage, Google Secret Manager is an excellent, boring, correct choice, and it is remarkably cheap. At $0.06 per active secret version per month and $0.03 per 10K access operations, with a free tier covering 6 versions and 10K operations, most small projects pay almost nothing.

It is a first-party Google service, so auditors trust it on sight, Cloud Audit Logs are built in, and it inherits GCP’s residency and CMEK story for free. Its native IAM binding means there is no extra token, no extra hop, and no extra vendor in your trust chain — the workload identity you already run is the auth. If that describes you and you don’t need proxying, tokenization, custodial vendor-key rotation, or an AI egress layer, you may not need KnoxCall at all. We would rather tell you that than oversell.

Concede the strong version first: TLS in transit, CMEK at rest, tight IAM bindings, short-lived access via workload identity, and Cloud Audit Logs on every read. That is a solid posture and for a purely GCP-internal secret it is close to ideal — the IAM boundary is real and rotating access is cheap.

But trace the pipeline for a static third-party bearer key. However tight the IAM policy, the flow still ends with AccessSecretVersion returning the real vendor key into your running process, because that is the only thing the vendor’s API will accept. Once it is in memory or the environment, IAM no longer helps — it gated who could fetch it, not who can read it now that it’s resident. And in that window the readers are not exotic:

• An RCE or SSRF that reads process memory or walks /proc/<pid>/environ.
• A poisoned dependency in your own supply chain — the Shai-Hulud npm worm did exactly this, and GitGuardian’s 2025 research found compromised packages harvesting credentials from roughly 8 locations, hitting 59% of CI runners they observed.
• A prompt-injected AI agent that simply runs printenv and exfiltrates its own ANTHROPIC_API_KEY.
• A core dump, an APM agent, or a debug log that captures the value in passing.

None of these are GSM flaws — it faithfully returned a secret the vendor never designed to be exchanged. KnoxCall’s only structural move is to take the plaintext handoff off your machine entirely: the bearer key is injected at the egress wire and never enters your workload’s memory or environment. It is worth doing even if you already run a secrets manager — in GitGuardian’s 2025 data, 5.1% of leaked secrets came from organizations that had one. (GitGuardian, State of Secrets Sprawl 2025: gitguardian.com/state-of-secrets-sprawl-report-2025.)

The honest residual. This is not zero-residual. A KnoxCall token still lives in your workload and can route requests through the proxy until it is revoked. The difference is what that token is: short-lived, scoped to specific routes, audited on every call, DPoP-bindable, and revocable on demand — versus a static vendor key that is valid for years. KnoxCall does not stop a compromise; it is a trust dependency and an extra network hop, the same tradeoff you accept with any federation or token-exchange layer. And the scope is deliberately narrow: third-party outbound bearer keys only. Your GCP-native workload identity and your application’s own encryption keys are out of scope — GSM and Cloud KMS still have a real job there.