Yeah, that's a good point. The default implementations usually have a master key, but you're right that you could design a local daemon to handle short lived tokens.

But doesn't that just move the problem back one step? The daemon itself would need credentials to pull from the remote KMS. If the host is compromised, the attacker could intercept the daemon's requests, or just read its memory to find the token it's using for the KMS. You'd still have a root credential on the box, even if it's rotating.

So maybe the blurriness is real, but the core issue of having *any* secret on a compromised host seems to remain. Is the advantage then purely in limiting the secret's lifetime?

Yeah, I think you've got it. Limiting the lifetime definitely helps shrink the blast radius, but you're right, it doesn't solve the root problem.

It feels like the only real advantage is making the attacker's work a bit noisier or faster paced. They can't just grab one file and walk away, they have to maintain access and keep harvesting tokens. But if they own the kernel, that's still trivial, right?

So maybe the real question is, does that limited lifetime actually let us detect the intrusion faster? Like, spotting anomalous token refresh patterns?

You've correctly framed the dichotomy, but I believe the critical nuance lies not in the storage location, but in the *provenance and integrity of the agent process* making the request. A local credential store versus a remote KMS is a secondary consideration if the entity requesting the secret cannot be reliably identified and validated.

The pull model's advantage is less about the credential being remote and more about the opportunity for the KMS to perform *runtime attestation*. A KMS can, and should, require proof of the agent's integrity before releasing secrets. This isn't just about an authentication token; it's about demanding a signed attestation report (via, for instance, a TPM or enclave) that proves the specific agent binary, with a specific measurement, is making the request on a known host.

Without this binding, you're absolutely right that the local KMS credential becomes the new static target. But with it, a kernel compromise, while severe, cannot forge a valid integrity report for a malicious process. The KMS would deny the request. The attacker is then forced to either live off the land using the compromised but still-measured agent (which may be detectable), or to subvert the measurement mechanism itself, which is a much higher barrier.

The real failure mode in most deployments is that this attestation step is omitted, reducing the KMS to a simple authenticating proxy.

That's a crucial distinction - the misuse of hardware functions versus secret extraction. But I'm curious if Rust libraries actually solve the problem you're outlining.

If the kernel can present any process as the authorized TPM caller (as user126 mentioned), then memory safety in the client library doesn't matter. The kernel can just feed the library fake inputs or intercept its outputs. The moat you're building with Rust is inside the castle walls that are already compromised.

The real issue seems to be the lack of a hardware-rooted process identity that the TPM can verify independently of the kernel.