# Confidential Computing Was Finally Working. Then Came the Agents.
Trusted Execution Environments spent about a decade being the right idea at the wrong time. The promise was elegant — hardware-isolated enclaves where code and data run invisible even to the host operating system, even to cloud providers with root access to their own machines. The reality was performance penalties measured in 10x, developer toolchains that punished you for using them, and attestation workflows so brittle that security teams gave up before deployment.
That story was quietly changing. Intel SGX matured. AMD SEV-SNP made whole-VM confidential computing viable without the application-layer gymnastics SGX demanded. NVIDIA shipped H100s with confidential computing support, unlocking GPU-accelerated workloads inside hardware trust boundaries. The Confidential Computing Consortium grew into a real industry body with real adoption behind it. Financial services firms started running sensitive workloads — not pilots, actual production — inside confidential VMs. The cloud providers built it into their standard offerings. The hard problems were becoming engineering problems instead of research problems.
Then someone decided to put an AI agent inside the enclave. Or outside it. Or maybe both. Nobody's entirely sure yet, and that uncertainty is the actual story.
## The Three-States Problem Had a Fourth State All Along
Classical confidential computing addressed data in three states: at rest (encryption), in transit (TLS), and in use (the TEE). The insight was that protecting the first two while leaving data plaintext in RAM during processing was leaving the door open. Enclaves closed that door.
Agentic AI introduces what you might call a fourth state: data *in reasoning*. An LLM agent doesn't retrieve data and return an answer in a single transaction. It holds context across dozens or hundreds of reasoning steps, makes tool calls to external APIs, receives results from those calls, updates its internal state, calls other agents, and persists memory to external stores for retrieval later. Each of those transitions is a potential trust boundary crossing — and TEEs weren't designed for trust boundaries that move.
The attestation problem is the concrete version of this. Attestation is how you verify that the code running inside an enclave is the code you think it is, cryptographically. That works well for a single enclave running a defined workload. Multi-agent architectures chain attestation across multiple enclaves, potentially across different cloud providers, potentially with open-ended tool use in between. Who attests the orchestrator? Does the orchestrator's attestation cover the tools it calls? When agent A passes context to agent B, the data left agent A's trust boundary and entered agent B's — but neither enclave attests the communication channel in any standard way.
There are proposals for cross-enclave attestation. There are research papers. There is not yet a production-grade solution that most organizations could deploy this year.
## The Prompt Injection Angle Nobody Wants to Admit
Here is the part of confidential computing's agentic AI problem that the vendor briefings tend to skip: the TEE cannot protect you from prompt injection.
This matters more than it sounds. A TEE provides cryptographic guarantees that the code inside it runs correctly and that its memory is protected. What it cannot verify is whether the *inputs* to that code have been manipulated by a malicious party. An agent browsing the web, reading emails, processing documents — any of those inputs could carry injected instructions designed to redirect the agent's behavior. The enclave faithfully executes the manipulated reasoning. The attestation is clean. The outcome is exactly what an attacker wanted.
Defenders working on confidential AI deployments are sometimes solving a hardware-layer problem when they have an application-layer vulnerability. The silicon is doing its job. The logic above it is not.
## The Memory Problem Gets Worse at Scale
Long-running agents need persistent memory. That memory has to exist somewhere outside the enclave — vector databases, key-value stores, retrieval systems — because enclaves aren't designed to hold state across restarts or across agents. Every time sensitive data transits from an enclave into an external memory store, you need an answer for how that data is protected at rest and who controls the keys.
This isn't unsolvable, but it requires combining confidential computing with serious key management infrastructure, and the two communities haven't always been talking to each other. The teams building agent memory systems are largely thinking about retrieval quality and latency. The teams building confidential infrastructure are thinking about attestation and isolation. The Venn diagram of people thinking hard about both simultaneously is smaller than it should be.
## What Defenders Can Actually Do Right Now
The gap between where confidential computing for AI is today and where organizations need it to be creates real exposure, particularly in regulated industries. The practical response isn't to wait for the standards bodies.
Restrict agent tool scope aggressively. Every external API, database, or service an agent can reach is a potential injection vector and a potential data egress path. Minimum necessary access applies to agents just as it does to service accounts.
Treat agent context as sensitive by default. If your agent is reasoning over customer data, assume the entire context window — including the reasoning steps, not just the raw data — is a sensitive artifact. Log it, protect it, retain it only as long as necessary.
Separate orchestration from sensitive processing. Where confidential VMs are in use, push the actual data-touching computation into the TEE and keep orchestration logic outside. Don't let the orchestrator see the payload.
Audit your attestation chain before you need it. When a multi-agent system processes sensitive data, can you actually prove what code ran and what it saw? If the answer is "we trust the provider," you don't have confidential computing — you have a vendor promise.
---
## HackWire Analysis
The confidential computing story from 2015 to 2023 was essentially one of adoption friction: good idea, hard to use, slowly getting easier. The agentic AI story starting now is structurally different — it's not friction, it's misalignment. The threat model for confidential computing was designed around a different kind of workload.
Classic secure enclave use cases — private set intersection, multi-party computation, sealed bid auctions, encrypted database queries — are bounded, well-defined, and stateless between transactions. An agent is none of those things. It's stateful by design, externally connected by design, and its "correct behavior" is defined by natural language instructions that can be subverted without touching a line of code.
What makes this moment interesting is that the industry that most needs this solved — financial services, specifically the firms doing AI-assisted fraud detection, KYC automation, and trading intelligence — is the same industry that was the first real confidential computing adopter. They understand the stack. They have the teams. And several of them are quietly finding that their confidential AI architecture has attack surfaces their security teams haven't fully modeled.
The research community is ahead of the vendors on this, which is unusual. The papers on TEE-based LLM deployment, on cross-enclave attestation for agent systems, on hardware-enforced prompt injection mitigations — they exist, and they're serious. The gap is that none of it has hardened into standards and none of the standards have hardened into products. Until they do, organizations deploying agentic AI on sensitive workloads are making architectural bets that outrun their guarantees.
The vendors will catch up. They always do. The question is what gets compromised in the gap.
— HackWire Editorial
---
## Related Coverage