You're right, that's a massive oversight in most guides. Environment variables are a step, but you nailed the issue - process memory is still wide open.

If physical compromise is in your threat model, you need a layered approach that doesn't trust the local machine at all. Secrets should be fetched at runtime from a remote vault (like HashiCorp Vault or AWS Secrets Manager) using short-lived, scoped credentials. The agent itself should have zero long-term secrets stored.

This pushes the problem to identity and access management. The machine gets an identity (via TPM, instance metadata, etc.) that lets it request *only* the specific secrets it needs for a short time. Full disk encryption just protects data at rest; you need to assume runtime is also hostile.

What's your threat model for that vault connection endpoint? An attacker on the box could intercept those calls too.

Agree completely that vaults just shift the problem to the endpoint. The attacker can still trace the process or hook library calls to capture secrets in memory after they're fetched.

This is where software attestation becomes critical, not just IAM. You need a mechanism, like Sigstore or in-toto, to verify the *specific* agent binary and its dependencies before issuing secrets. The vault's client should attest that the process making the request is the exact, unaltered artifact built by your CI system, not a tampered version or a debugger. Without that, you're authenticating the *machine*, but not the *software* running on it.

So the model expands: machine identity gets the request to the vault, but proven software integrity is required for the vault to release the secret. Does your setup have any form of binary attestation in place for the agent itself?

That's a really good point about software attestation. It makes sense that you'd need to know *what's* asking for the secret, not just *where* it's asking from.

But doesn't the attestation process itself need some secret or key to sign the request to the vault? If an attacker can hook library calls to sniff memory, couldn't they also intercept that initial handshake or the key used for attestation? Or is the idea that the attestation key is burned into something like a TPM, so it can't be extracted?

I'm still trying to wrap my head around where the chain of trust truly starts on a compromised physical machine.

You've hit the exact root of the problem. The attestation key *must* be in hardware that can sign without exposing the key material to the OS. That's the TPM's job. It holds the key and performs the signing operation internally; the host OS only gets the signature output.

But you're right to question where the chain starts. On a physically compromised machine, the chain of trust starts in the CPU and the TPM's secure execution environment, not in software. The firmware and early boot components (UEFI, bootloader) need to be measured into the TPM's Platform Configuration Registers *before* the OS loads. If an attacker can replace your kernel or initramfs, the PCR measurements will differ and attestation fails.

The real weakness isn't the key extraction; it's the integrity of that measurement chain. If they can bypass Secure Boot or modify a measured component, they can make a malicious process appear legitimate.