Confidential AI: When the Host Can’t Be Trusted
•
•
4 min read
Most systems quietly assume something that stops being safe the moment you care about security:
the host can see everything.
Secrets live on servers. Data is processed in memory. Tool calls run inside processes your infrastructure controls — which also means a compromised host can observe, tamper, or siphon off what matters.
Back in 2021 I attended a confidential computing conference and kept coming back to the same idea from two very different angles:
- AI systems that need to call tools safely
- Game anti-cheat systems that run in adversarial environments
Different domains, same underlying question:
How do you reduce what you have to trust?
When enclaves start to matter
As soon as you move from “LLM answers questions” to “LLM does things,” the integration layer becomes the high-value surface area:
- tool calls need credentials
- actions can mutate real systems
- approvals and policy become part of the product
You’re no longer defending a prompt. You’re defending an execution path.
That’s where enclaves — more broadly, Trusted Execution Environments (TEEs) — start to matter.
What TEEs give you
A TEE is a protected execution environment designed to isolate code and memory from the surrounding host (within a defined threat model).
The reason TEEs are useful in real systems is remote attestation: a way for the platform to produce verifiable evidence about what workload is running inside the protected environment.
Attestation, in practice
Attestation is best thought of as hardware-backed evidence.
It’s designed for a remote verifier (your secret store, policy service, backend) to answer a practical question:
Am I talking to the exact workload I expect, running inside a genuine TEE?
A typical attestation flow looks like this:
- The protected environment measures the workload (commonly a cryptographic “measurement” derived from code + initial state)
- The platform produces an attestation report/quote that includes that measurement
- A verifier checks the report/quote and its certificate chain
- Your policy decides what happens next (release secrets, allow an action, or deny)
Once you have that, you can gate secrets and high-trust actions on something stronger than “the host says it’s fine.”
Hardware roots of trust: Intel vs AMD
Different vendors implement this differently, but the idea is consistent: root the trust in hardware, not the OS.
Intel: SGX / TDX
- With SGX, enclaves can be measured and attested. In common remote attestation flows, the platform produces a quote containing measurements that a verifier can validate.
- With TDX (VM-focused), the guest can generate a TD report, and the platform can produce a quote suitable for third-party verification.
AMD: SEV-SNP
- With SEV-SNP, the protected environment can produce an attestation report tied to the CPU’s secure subsystem.
- Verifiers check this using AMD-provided endorsement keys/certificates (you’ll see terms like VCEK/VLEK depending on environment and provider).
If you remember one thing: the output is the same kind of artifact — a signed, verifiable statement about workload identity — and your verifier policy decides what gets access to secrets.
Applying TEEs to AI tool calls
If MCP is about standardizing how tools are described and requested, TEEs can harden where sensitive execution happens.
The attested tool broker
Instead of letting your main application hold credentials and call tools directly, put a small broker behind an attested boundary.
The broker:
- retrieves/unwraps secrets only after attestation
- executes high-trust calls (internal APIs, ticketing, deployments, payments, etc.)
- returns structured results
The host:
- doesn’t see raw credentials
- still controls when actions happen (approval UI, rate limits, policy)
- gets a single boundary to log and audit
This pairs naturally with routing too: cheaper models can classify and propose actions, while the “keys-to-the-kingdom” execution path stays behind a hardened boundary.
Where TEEs help in anti-cheat
Anti-cheat is the purest “assume the environment is hostile” problem. Attackers can patch code, hook functions, fake signals, and replay telemetry.
Modern approaches increasingly lean on signals that don’t require trusting the client. Valve has talked publicly about VACnet (deep-learning based cheat detection) and the benefits of robust, server-side oriented detection.
So where do TEEs fit?
They can tighten specific trust boundaries where client integrity still matters.
Attested client modules
If a client can produce credible evidence about a specific module running as expected, certain telemetry can be treated as higher-confidence than generic client reports.
That won’t stop cheating outright, but it can raise the cost of tampering and reduce ambiguity around what you’re trusting.
Protected verification steps
In some designs, the vulnerable part isn’t the ML model — it’s the pipeline around it:
- feature extraction
- integrity checks
- enforcement thresholds
A hardened boundary can make that pipeline harder to modify silently in high-stakes environments (competitive play, tournaments, multi-party trust).
Same theme as AI tool execution:
Once a system can take meaningful action, the action boundary becomes worth defending.
Tradeoffs
TEEs can improve a security posture, but they come with real costs:
- operational complexity (deployment, upgrades, key management, failure modes)
- reduced observability (by design)
- performance overhead (workload dependent)
The best results usually come from keeping the trusted component small and purpose-built: credential handling, policy evaluation, sensitive transformations — not your entire application.
When it’s worth the complexity
Worth considering when:
- secrets must be used, but the host shouldn’t see them
- you need stronger guarantees around high-trust actions
- trust is part of the product (regulated data, enterprise posture, multi-party workflows)
Usually not the first move when:
- you’re still prototyping rapidly
- the workflow doesn’t truly require tool power + secrets
- you don’t yet have a clean “sensitive execution” boundary
Closing thought
MCP helps standardize how AI applications discover and request tools.
TEEs help harden where secrets live and where sensitive actions execute.
AI tool workflows and anti-cheat look unrelated on the surface, but they rhyme: both are about building systems that still behave when parts of the environment can’t be trusted.