The Trust Gap: What Confidential Computing Doesn't Cover
Speaking session at Confidential Computing Summit 2026
A three-layer evaluation framework in Java + LangChain4j for AI-agent trust testing: policy compliance, judge-based answer safety, and tool-trajectory validation, wired into CI as a build-time gate.
The Linux Foundation's Confidential Computing Summit is a room full of people who have spent a decade making sure no outsider can read your memory. I went there to argue that we've done the runtime layer well, and that there's another layer of trust, sitting on top of the runtime, that we haven't.
A short note on where I was
This week I stood next to a printed poster for four one-hour sessions over two days at the Linux Foundation's Confidential Computing Summit in Santa Clara. The poster session is the format I think most people underestimate at technical conferences. It's not a stage talk and it's not a booth pitch. It's a series of one-to-one conversations with the people who self-selected to walk over to your board. You get maybe forty stops in an hour. A handful turn into real conversations. A few of those turn into something that survives the flight home.
The poster I brought argued for a simple proposition: confidential computing protects the runtime an AI agent runs in, but it does not test whether the agent inside that runtime is making the right decisions. The two are different layers of trust and both are needed.
What follows is the long-form version of the argument I made over and over at the poster, plus the most common questions I got back and what I learned from them.
What confidential computing actually solves
Computing has always had three states of data and we historically encrypted only two of them. Data at rest, on disk, has been protected by full-disk encryption for decades. Data in transit, on the wire, has been protected by TLS for almost as long. The third state, data in use, sitting in RAM while a program actually runs, was always plaintext, readable by anyone with privileged access to the host machine. The operating system could read it. The hypervisor could read it. A cloud admin with root could read it. That was the last open seam.
Confidential computing closes that seam. The mechanism is a Trusted Execution Environment (TEE), a hardware-protected region of a CPU where code and data are isolated from everything else on the system, including a fully malicious OS. The TEE provides three simultaneous properties: confidentiality (memory is encrypted, the key never leaves the silicon), integrity (any tampering is detected), and attestability (a cryptographic proof, signed by the CPU vendor, of exactly what is running).
Without a TEE, the OS can read RAM and see plaintext. With a TEE, the CPU encrypts data on the way out of the chip, so the OS still reads the same memory but only sees ciphertext. The key never leaves the silicon.
This is real, important work. It's why workloads that used to be limited to private hardware, such as banking key handling, healthcare record processing, defense workloads, and sovereign-cloud deployments, can now live on commodity public cloud. The room I was in is the room that built this.
What confidential computing does not solve
The TEE protects a boundary. It guarantees that no outsider reads your memory and that the binary running inside is the binary you attested. It says nothing, zero, about whether the code inside is making correct decisions.
For deterministic workloads, that's fine. A confidential database serves SQL queries; the queries have well-defined semantics; ordinary integration tests catch correctness issues. A confidential key-handling service signs a payload with a key; the operation is one tested function. The TEE adds confidentiality on top of correctness that was already established by other means.
Then we started putting LLM-driven agents inside the same TEEs.
An agent is not a deterministic function. It is an LLM in a loop, picking tools, supplying parameters, deciding the order of operations, producing a final answer. The same input can produce different tool calls on different runs. The agent can hallucinate. It can pick a tool that's allowed in one workflow but forbidden in this one. It can produce a final answer that reads well and is completely ungrounded. None of those failures violates the TEE's guarantees. The TEE happily protects the bytes of a wrong decision.
The TEE secures the perimeter. The agent inside still picks which tool to call. The TEE does not grade those choices. Behavior tests do.
This is the gap I argued for at the poster: the application-layer trust gap inside the confidential runtime.
Three layers of behavioral trust
If you accept that the TEE handles the runtime layer and you want to add a layer above it that grades the agent's behavior, you find that the relevant failures cluster into three classes. Each class is large enough to deserve its own check, and small enough to define precisely.
The first class is about the tools the agent invokes. Did it call a tool that wasn't on the approved list? Did it call a tool that was explicitly forbidden? When it called an allowed tool, did it pass valid parameters, meaning required fields present, forbidden fields absent, and enum-typed values inside the declared options? These are application-level questions the TEE has no opinion on. A perfectly attested, perfectly encrypted agent can still call a forbidden tool because, from the TEE's point of view, the agent's tool registry is just one more piece of the workload.
The second class is about the final answer. Did the agent stay grounded in what its tools actually returned? Or did it invent an ID, fabricate a quoted span, claim a quantity it never read? Did the answer mention a field that was supposed to be filtered or redacted? Did the agent claim to have done something, like "successfully deleted" or "marked as resolved," when no tool capable of that action was ever called? Grounding and unsupported-claim detection are not properties of the runtime. They're properties of the natural-language output, checked against the trace of what the agent actually saw.
The third class is about the sequence. Even when each individual tool call is allowed and the final answer is well-grounded, the order the agent did things in can violate policy. In regulated workflows such as healthcare consent, banking approvals, and audit-trail-bound flows, the path matters as much as the destination. Skipping a required consent step. Running update-before-read. Issuing a response before writing the audit log. Repeating a tool that's supposed to fire once. These are sequence-level failures. They don't show up in the tool list or in the final answer. They show up only in the ordered trace.
The interesting property is that each class is detectable, and each class is detectable by a check that does not overlap with the other two. A check that tries to do all three at once produces ambiguous failures. A check that owns one class precisely tells you exactly what went wrong. That separation is what makes the framing useful.
I'm not the first person to notice any of these failure modes. The work that's specific to this poster is putting all three together as a single coherent layer of trust, sitting above the runtime layer, applicable to any agent running anywhere, TEE or not.
The conversations that taught me something
The format of a poster session is that you say roughly the same thing forty times in an hour. By the third hour you've heard every pattern of pushback that exists. Four questions came up over and over, and each one taught me something about how this audience thinks.
"Why is this poster at confidential computing?"
This was the most common question, by a noticeable margin. Multiple independent visitors asked some version of it. The honest answer is that the work isn't technically dependent on TEE primitives. The behavior-checking layer would work just as well on a normal cloud VM with no TEE involved. The connection to confidential computing is conceptual. The CC community has spent ten years on the bottom half of the trust stack. Almost nobody in that community is working on the application layer of the same stack. As LLM agents move into TEEs, such as Apple Private Cloud Compute, NVIDIA Hopper TEE confidential inference, confidential GPU services from Phala and Edgeless, and sovereign-cloud AI deployments, the runtime primitives keep working, but the workload inside is no longer deterministic. That's the new gap, and it sits naturally next to the work the room has been doing.
The single sentence that landed when I delivered it confidently:
"The TEE is necessary, not sufficient. You attested the binary. The binary's behavior still needs testing."
"How is this production sustainable?"
The honest answer here is that any behavior-testing discipline has real maintenance cost. Writing the policies down, reviewing them when workflows legitimately change, and rotating stale tests all take work. The cost profile is roughly the same as maintaining SQL test fixtures or snapshot tests in any large codebase. Sustainability is a function of team discipline, not a property of any specific framework. For high-stakes domains such as banking, healthcare, and government, the cost is obviously worth it because the alternative is finding out about a regression from a customer complaint. For low-stakes domains the calculation is genuinely different and a team might decide it's not worth the lift.
"What about dynamic flows? Yours looks like hardcoded use cases."
Fair pushback. The framing on the poster does emphasize deterministic verification, and that's accurate. Behavior tests catch regression-class failures over your known workflows. They do not catch novel failures the team never anticipated. For genuinely emergent or adversarial behavior, you need a runtime guard alongside the build-time check, the same way SAST and a WAF stack in traditional security. Build-time tests catch what you've thought of; runtime guards catch what you haven't. The two layer naturally and neither replaces the other.
"Where do you live in this picture?"
Usually a question about the integration story. Three roles: the team that builds the agent (writes the behavior tests), the CI engineer (configures the gate thresholds), and a runtime ops role (monitors the runtime guard that complements the build-time tests). The TEE community already owns the runtime side; what's underemphasized is the developer's responsibility for the behavior tests. The poster argues that responsibility deserves its own layer of trust thinking.
What I'm taking back with me
Three things stuck with me on the flight home.
First, the right audience for an idea is not always the audience that's been thinking about it. Most of the people I talked to at the summit had not been thinking about application-layer trust for LLM agents. They had been thinking about attestation, secure enclaves, memory encryption, sealing flows. The fact that none of them had been thinking about my topic doesn't mean the topic isn't relevant. It means the topic isn't yet visible in their conversation. A poster is one way of making a topic visible. A second is to write the long-form version up so it can be linked.
Second, confidential computing's next decade is going to be defined by the workloads it hosts, not by the primitives it ships. The hardware is largely solved at the engineering level, with Intel TDX, AMD SEV-SNP, ARM CCA, and NVIDIA Hopper TEE. What gets put inside those TEEs is now the open question. LLM agents are one of the biggest emerging classes, and they bring a new shape of "is this workload behaving correctly?" problem that the field has not historically dealt with.
Third, the discipline of testing what a non-deterministic system does is genuinely young. We have decades of practice testing deterministic code: unit tests, integration tests, golden-master tests, fuzz tests. We have years of practice testing model accuracy on held-out datasets. We have almost no shared vocabulary for testing whether an agent, a stochastic, tool-using, multi-step system, behaves correctly in production-realistic scenarios. The field is going to converge on patterns over the next two or three years. The patterns are not yet standardized. Anyone who shows up with a useful framing has a chance to influence what those patterns become.
The poster session is one signal. The real signal is whether the framing keeps appearing in other people's work over the next year. We'll see.
If you're thinking about this too
If you're building an LLM agent that handles sensitive data and you're already deploying it into a TEE, whether Apple PCC-style confidential inference, NVIDIA Hopper-backed GPU workloads, or a confidential-VM-hosted regulated workflow, the runtime layer is well-covered. The next question is whether you have a behavior-testing discipline alongside it. Three concrete questions you can ask of your own deployment today:
- Tool selection. What is your written list of tools this agent is allowed to call for this intent class, and how do you check at build time that the agent only ever calls them?
- Answer grounding. When the agent produces a natural-language response, what mechanism, automated rather than human-eyeball review, confirms that every claim in the response traces back to data the agent actually saw from a tool?
- Sequence ordering. For workflows where ordering is regulated (consent before action, audit before write, identity verification before any modification), what gate verifies the actual tool sequence against the policy on every build?
If the answer to any of those is "no automated check, we rely on the model behaving correctly," that's the gap the poster argues for closing. The TEE you've already deployed handles the runtime side of trust. The three checks above handle the behavior side. Stack the two and you get application-layer trust on top of runtime-layer trust, both audited, both reproducible, both running on every commit.
If any of this resonates with what you're building, I'd genuinely like to hear about it. Reach out, details below.
Sachin Gupta · linkedin.com/in/guptasachin1
Notes from the poster session at the Linux Foundation's Confidential Computing Summit, June 23 to 24, 2026, Santa Clara, California.
