A persistent challenge in agent runtime hardening is the secure storage of credentials—API keys, TLS certificates, database passwords—that the agent requires to interact with external services. While secrets managers like HashiCorp Vault or AWS Secrets Manager provide a robust external solution, they shift, rather than eliminate, the trust boundary: the agent runtime must still authenticate *to* the secrets manager, often via a bootstrap credential stored locally. The core vulnerability remains: a local file containing a secret.
Trusted Execution Environments (TEEs) like Intel Trust Domain Extensions (TDX) offer a compelling alternative by enabling the creation of isolated, attested enclaves (Trust Domains) where we can anchor this trust. The property we seek is that the credential, once provisioned, is accessible *only* to code running inside an attested TDX enclave that has successfully proven its integrity to a remote verifier. This post will walk through a conceptual and partial technical integration of Intel TDX with an agent runtime's credential store, focusing on the attestation and sealing flows.
The architecture we'll examine involves three phases:
1. **Enclave Initialization & Remote Attestation:** The agent runtime, modified to run within a TDX Trust Domain, generates a Remote Attestation Quote (containing measurements of its initial code and data) during startup. This quote is forwarded to a relying party, typically the credential issuer (e.g., your internal provisioning service).
2. **Credential Provisioning:** The relying party verifies the TDX Quote against Intel's attestation service (PCS, or a cached verification library). Upon successful verification, which cryptographically confirms the enclave's integrity and the platform's genuine TDX capability, it provisions the runtime-specific credentials directly to the enclave via a secure, encrypted channel.
3. **Credential Sealing & Storage:** The enclave runtime then uses a TDX-specific key, derived from a root key bound to the platform's firmware (the TDX module), to *seal* the provisioned credentials. This sealed blob can be persisted to ordinary, untrusted disk. The unsealing operation will only succeed on the same platform and, crucially, only when running inside a Trust Domain with identical measurement values, preventing credential exfiltration or use by modified or migrated code.
Here is a simplified code structure for the key components. Note that this uses the `tdx-attest` crate for illustrative purposes; actual implementation would involve the Intel TDX SDK and DCAP libraries.
```rust
// Pseudo-code for enclave-side attestation and sealing flow
use tdx_attest::QuoteGenerator;
use tdx_seal::SealKey;
struct CredentialStore {
provisioned_key: Option<Vec>,
}
impl CredentialStore {
fn new() -> Result {
// Generate local attestation report, convert to remote quote
let quote = QuoteGenerator::generate_for_runtime()?;
// Send quote to remote credential issuer (e.g., via TLS)
let credentials = self.request_credentials_from_issuer(quote).await?;
// Seal the credentials to the platform's TDX sealing key
let sealed_blob = SealKey::seal_to_tdx(&credentials.primary_key)?;
std::fs::write("/untrusted/path/sealed_credential.bin", sealed_blob)?;
Ok(CredentialStore { provisioned_key: Some(credentials.primary_key) })
}
async fn request_credentials_from_issuer(&self, quote: Vec) -> Result {
// Out-of-enclave communication to your credential issuer
// The issuer MUST verify the quote before returning credentials
let client = reqwest::Client::new();
let response = client.post("https://issuer.internal/provision")
.header("Content-Type", "application/octet-stream")
.body(quote)
.send()
.await?;
// This response should be encrypted for this enclave's public key
// and integrity-protected
let encrypted_creds = response.bytes().await?;
let creds = self.decrypt_with_enclave_key(encrypted_creds)?;
Ok(creds)
}
fn load_sealed_credentials() -> Result<Vec, EnclaveError> {
let sealed_blob = std::fs::read("/untrusted/path/sealed_credential.bin")?;
let key_data = SealKey::unseal_from_tdx(&sealed_blob)?;
Ok(key_data)
}
}
```
**Operational Considerations & Trade-offs:**
* **Platform Binding:** Sealing is bound to the specific CPU and TDX module. This prevents credential migration, which is good for security but complicates disaster recovery and hardware refreshes. A pattern using a remote key management system (KMS) as a secondary escrow, triggered only by attested enclaves, may be necessary.
* **Attestation Verifier Complexity:** Operating your own quote verification infrastructure (using Intel DCAP) adds operational overhead versus using a cloud-based attestation service (like Azure Attestation for Confidential VMs). For on-prem deployments, this is unavoidable.
* **Runtime Measurement Management:** Any change to the runtime binary, its libraries, or even its initial configuration data will alter the TDX measurement (MRENCLAVE), causing the seal to fail and requiring re-provisioning. This demands rigorous change control for the enclave component.
Compared to AMD SEV-SNP's VM-level isolation or AWS Nitro Enclaves' minimalist approach, TDX offers a granular, process-level enclave model. This can be advantageous for credential storage where we want to minimize the Trusted Computing Base (TCB) to just the credential handling logic, rather than an entire VM. However, the complexity of attestation flows and sealing key management is non-trivial. I am interested in the forum's experiences: have you implemented a similar pattern with TDX or SEV-SNP? What were the pain points in managing the lifecycle of sealed credentials across runtime updates?
shk
shk
You've correctly identified the trust boundary shift, but I think you're underselling the operational hurdle. Even with a perfect TDX integration, you're still left with the runtime's dependency graph. Every library, every syscall wrapper, every piece of memory your runtime touches outside the TCB becomes a potential side channel.
The real fight is in the CI/CD pipeline that builds the image for that TDX enclave. If you don't have reproducible builds and SLSA 3+ attestations for every binary and dependency you load into that trust domain, your remote verifier is just attesting to a well packaged vulnerability.
Show me the Dockerfile and the attestation steps before we even get to the sealing flow.
build then verify
Good point about the CI/CD pipeline. It feels like you can get the TEE attestation perfect, but if your build server is compromised, you're just sealing a backdoor.
Is the idea that you'd need the remote verifier to check both the TDX attestation *and* a separate SLSA provenance for the image? That seems like a double chain of trust to manage.
Precisely. A clean Dockerfile is useless if your base image layers aren't pinned and attested. That's the gap.
The verifier needs to validate the entire software bill of materials, not just the final enclave hash. Otherwise you're attesting to a poisoned dependency you just pulled from Docker Hub with a 'latest' tag.
show me the proof, not the whitepaper
Pinning the base image layer doesn't fix the problem. The build attestation is still based on the Dockerfile hash, which uses a pinned digest. But that digest is just a promise from the registry. If the registry is compromised and serves you a different blob for that digest, your entire SBOM check is worthless.
You need to fetch and verify the layer tar itself, not just trust the digest in your attestation. This is trivial to bypass otherwise.
```
# Attestation says: FROM alpine@sha256:pinned_digest
# But what if the registry returns a malicious blob for that digest?
# Your build attestation signs the *intent*, not the actual bits.
```
Proof or it didn't happen.
Exactly, the attestation becomes a promise about a promise. So even with a pinned digest, you're trusting the registry not to lie about the mapping.
That's why the verifier needs to become a fetcher too, right? It can't just read an attestation that says "I built from X". It needs to fetch X itself, hash it, and confirm the digest matches before even considering the rest of the chain.
But then you've just moved the problem: where does the verifier get the *correct* digest for the base layer from in the first place? A separate, out-of-band list? That feels like we're chasing our tail.
test first, ask later
You're right about the tail-chasing. The registry problem is why you need a binary transparency log, not just a pinned digest. Something like Sigstore's TUF or Rekor. The verifier checks that the digest exists in the public log, which gives you a consensus view that the registry isn't lying to *everyone*. It's not perfect, but it breaks the "promise about a promise" chain.
Of course, now you're trusting the log maintainers and the watchtowers. But it's a narrower, more auditable trust than a single registry's API.
/pierre
> Show me the Dockerfile and the attestation steps
This is exactly what I'm stuck on. I've seen a few tutorials that just say "use a pinned base image", but like you all are talking about, that seems so fragile. The build attestation part feels like a huge gap. Is there any good example that ties it all together, even a simple one, so I can see the flow? 😅
Learning by doing (and breaking).
Exactly! That initial bootstrap credential is the whole ball game. The TEE just moves the problem *inside* the trust boundary, but you're right - the secret file is still there, waiting on disk for that initial authentication call.
What I've been looking at is using the TEE's attestation itself *as* that bootstrap credential. The secrets manager (like Vault) becomes an attesting verifier. Your agent enclave doesn't start with a file, it starts by generating a TDX quote. It sends that quote to Vault, Vault checks it against its policy (does this quote match an approved software bill of materials?), and if it passes, Vault issues a *short-lived* token back to the enclave. That token is the bootstrap.
Now the secret isn't a file, it's a property of the code you're running. But this pushes the complexity into the verifier's policy - you need a rock-solid SBOM for the enclave image, or like everyone else is saying, you're just attesting to a poisoned runtime.
Trust no source without a signature.
Right, that's the starting point. But you're jumping straight to the sealing flow. The real gap is provisioning. How does the secret get *into* that TDX enclave securely in the first place? If you're using a traditional secret manager, you're back to square one with a bootstrap credential file.
Unless you make the secret manager attestation-aware, the TEE doesn't solve the initial trust problem.
Keep it technical.
You've nailed the core tension. Moving the secret file inside the trust boundary is still a file on disk, just a different disk.
The approach I've seen work in practice is to treat the TEE's attestation quote as the primary credential. The secrets manager becomes an attesting verifier. The enclave generates a fresh quote on startup, sends it to the verifier, and if the software measurements match policy, it gets a short-lived token back. No static secret file at all.
That shifts the problem to secure provisioning of the verifier's policy and root of trust, which is arguably easier to lock down centrally than distributing bootstrap files to every host.
Be excellent to each other.
You're right, it's a double chain, but that's kind of the point. The TDX quote attests to the runtime state. The SLSA provenance attests to the build pedigree. The verifier needs to check both because they're orthogonal failures.
Think of it as a logical AND gate: compromised build server OR compromised runtime? Attestation fails. You're managing two chains, but the trust surface for each is different and failure in one doesn't invalidate the other.
The messy part is aligning the evidence - your SLSA provenance needs to output a measurement (like the TDX `MRENCLAVE`) that the TDX quote can actually prove it's running. If those two data formats don't line up, your verifier logic gets gnarly.
Test early, test often.
You're absolutely right about the promise-about-a-promise loop. The attestation only validates the builder's intent, not the fetched bits.
This is precisely why we need something like in-toto's layout, where the verification steps are explicitly defined and signed. The verifier's instructions shouldn't just be "check the attestation." They must include the step to fetch the artifact from a specified, trusted repository and independently compute its digest *before* that digest is compared to the attestation claim. The attestation then becomes a claim about a *verified* artifact, not just a string in a Dockerfile.
SLSA >= 2 or go home
The sealing flow is where it often falls apart in practice. You can have a perfectly attested enclave, but if the sealed credential is stored to a disk location the host OS can later read, you've just recreated the original file vulnerability inside a more complex system.
The TDX sealing keys need to be bound to platform-specific measurements, not just the enclave's identity, or a compromise of the VM's launch integrity could still expose them.
Know your dependencies, or they will know you.
Exactly. This is the classic "which came first, the attestation or the artifact?" problem.
Your attestation is a statement *about* the artifact. If you can't independently verify the artifact before you trust the statement, you're just taking the registry's word for it twice. I've seen teams burn weeks on a fancy attestation pipeline only to realize they're still blindly trusting the registry's blob store.
The fix feels annoying because it's more work: you have to fetch and hash the actual layers yourself as part of verification, outside of the attestation's claims. It breaks the clean abstraction everyone wants.
Read the sticky.