A case study on using Phala's confidential compute substrate as the foundation for a verifiable evidence layer in production agent systems.
Why this matters now
AI agents are no longer experiments. They read production code, call APIs with live credentials, and act on customer data. Once an agent makes that call, the prompt containing the proprietary code, the API key, and the customer data leaves the user's machine. It travels to a model API in plaintext. The model provider sees it. The hosting provider sees it. The network sees it.
Most teams respond to this with policy. "We trust our cloud provider." "We trust the model host." "Our NDAs cover this." Those answers worked when AI was answering questions in a sandbox. They stop working the moment an agent can deploy to production, transfer money, or read medical records. Regulators now ask who could access data during processing. Enterprise customers ask the same. The honest answer in most deployments is: we don't know, and we can't prove it either way.
That gap is what NEUS set out to close. And the foundation they chose to build on is Phala's TEE infrastructure.
The missing layer
Anyone trying to build a "trust layer" or "evidence layer" for AI agents hits the same wall. They need to prove three things for every action:
- The data was sealed during processing. Not "encrypted at rest and in transit." Actually sealed inside the compute, where neither the host operator nor the model operator can read it.
- The runtime was genuine. The code that processed the data was the expected code, unmodified, on real hardware. Not "we ran it on AWS" but a cryptographic receipt saying exactly what ran.
- The agent was authorized. A specific human delegated a specific scope of authority to a specific agent, and the action fell within that scope.
Most of the industry focuses on (3). Identity, scopes, receipts, audit logs. That part is solvable in software. (1) and (2) require hardware-enforced compute, and most teams either don't have access to it or underestimate how much work it is to build.
This is the gap Phala fills. We are not building an evidence layer ourselves. We are the substrate that makes any evidence layer provable.
Why we built Phala the way we did
Phala has spent six years on one problem: how do you give a workload a sealed runtime, attested by hardware, with keys that never leave a TEE, in a way that any third party can verify?
The answer is built on two pieces:
- dstack is the open-source TEE framework. Apache 2.0, hosted by the Linux Foundation. Anyone can audit it, fork it, run it themselves. It handles hardware attestation, key provisioning, encrypted storage, and the Docker Compose-native deployment model.
- Phala Cloud is the managed layer on top. Provisioning, scaling, monitoring, billing. Operationally necessary, but cryptographically excluded from the data path. Phala's control plane cannot read your workload's memory or storage keys.
This separation matters. When you build a trust layer on Phala, you are not taking Phala's word that your data is safe. You can verify it. The attestation quote is signed by Intel TDX hardware. The OS measurements match the open-source build. The compose hash binds the attestation to the exact containers you deployed. KMS keys are derived inside another TEE and released only after verification passes.
No trust in vendor. No trust in operator. No trust in host admin. Verifiable from the silicon up.
How NEUS built on Phala
NEUS is one of the teams using Phala's substrate to ship a real product. What they built is called the Trust Harness, and it is worth understanding in detail because it shows the pattern.
When an AI agent reads your production code, calls your APIs with live credentials, or accesses customer data, the prompt containing that information travels to a model API in plaintext. The model provider sees it. The hosting provider sees it. The network sees it. You get an audit log entry saying a request happened. You do not get proof that the data was sealed during inference, or that the agent who made the call was authorized to do so.
NEUS and Phala built the trust harness to close that gap. It is a cloud agent runtime where inference runs inside sealed hardware, the runtime is cryptographically attested, and every agent action is governed by signed receipts from delegation through execution to verification.
The three layers
The trust harness combines three layers into one pipeline.
Sealed inference. Phala provides the confidential compute substrate. Model calls execute inside Trusted Execution Environments: NVIDIA H100 and H200 GPU enclaves for model execution, Intel TDX confidential VMs for orchestration and pre/post-processing. Prompts, keys, tools, and agent memory are encrypted in memory and decrypted only inside the enclave's protected boundary. The host OS, the cloud provider, and the model operator cannot read the plaintext. Phala's confidential inference API routes every inference request through this confidential layer, so no agent call passes through a standard API endpoint where inputs are visible.
Attested runtime. Before data enters the enclave, Phala's attestation system generates a hardware-backed proof that the runtime environment is genuine, unmodified, and running the expected code. The attestation document binds the enclave's measurement to a specific hardware platform and software hash. Any third party can verify, without trusting Phala or the cloud provider, that inference ran in the exact environment claimed, on the exact code expected, at the time the request was processed. This is cryptographic proof of runtime integrity.
Governed action. NEUS sits on top of the inference pipeline and governs who can call it, under what authority, and within what scope. When a team deploys an agent, NEUS issues a trust receipt: a cryptographically signed record that binds the agent's identity to a delegated authority, a scope of permitted actions, and a set of constraints. Every inference call the agent makes through the pipeline is logged against that receipt. Each action carries a verifiable chain of authority from the person who delegated it, through the agent that executed it, to the sealed runtime that processed it.
You can take a receipt, verify the signature against the issuing identity, confirm the scope constraints, and match it to the corresponding attestation from Phala. Two halves of one proof: the data was never exposed, and the action was authorized.
What one agent action looks like end to end
The trust harness is the runtime: the environment where agents live, receive tasks, call models, execute actions, and produce verifiable outputs. Here is how a single agent action flows through it.
- Delegation. A user delegates authority to an agent by issuing a NEUS trust receipt, signed, scoped, and tied to the agent's identity. The receipt defines what the agent can do, which resources it can access, and how long the authority is valid.
- Task execution. The agent receives a task, constructs a prompt, and calls a model through Phala's confidential inference API, which routes the request into a Phala TEE enclave.
- Sealed inference. Inside the enclave, the prompt is decrypted, inference runs on isolated NVIDIA H100/H200 GPU or Intel TDX hardware, and the output is returned. The model operator cannot see the input. The cloud provider cannot see the input. Enclave memory is cleared after the call.
- Attestation. Phala generates a hardware-backed attestation proving the runtime environment was genuine and the code was unmodified for that specific call.
- Receipt. NEUS logs a signed receipt recording that this agent, under this delegated authority, executed this inference through an attested confidential runtime.
You now have two artifacts for every agent action: an attestation proving the compute was sealed, and a receipt proving the agent was authorized and scoped. Both are independently verifiable. Neither depends on trusting the model provider, the cloud host, or the agent developer.
What Phala gives you underneath your own product
The layer above (governance, receipts, delegation, agent orchestration) is yours to build. That is the product you sell. The layer underneath (sealed compute, attested runtime, key management) is what we provide, and it is the part most teams underestimate.
Concretely, when you build on Phala you get:
Hardware-enforced memory isolation. Every workload runs inside an Intel TDX confidential VM or an NVIDIA H100/H200 GPU in confidential-computing mode. The CPU and GPU encrypt data in memory. The host OS, the hypervisor, the cloud operator, and any admin with root access to the physical machine cannot read it. The protection is at the silicon level, not a software policy.
Cryptographic attestation of every call.. Before any workload receives keys or processes sensitive data, the platform generates a signed attestation quote proving the runtime is genuine and the code is unmodified. The quote includes measurements of hardware, firmware, OS, and the exact Docker Compose file that was deployed. Any third party can verify it without trusting Phala.
Keys that live inside a TEE.. Disk encryption keys, API credentials, model provider tokens. All derived inside a separate KMS that runs in its own TEE, released only after the workload's attestation is verified, and never exposed to Phala or the operator. The key keeper is cryptographically verifiable, not trusted on faith.
Open-source stack you can audit.. dstack is Apache 2.0, hosted by the Linux Foundation. The OS image, attestation stack, KMS logic, and key derivation are all in the public repository. You do not take Phala's word that the stack is sound. You can rebuild it from source and compare measurements.
GPU TEE for real AI workloads.. For LLM inference, fine-tuning, or any GPU-accelerated workload, Phala runs NVIDIA Hopper and Blackwell GPUs in confidential-computing mode. Both CPU attestation and GPU attestation must pass before keys release. Model weights, prompts, and intermediate activations stay encrypted in GPU memory.
Deploy your way.. Use Phala Cloud for managed infrastructure, or run dstack yourself on your own TDX-capable hardware, on GCP, or on AWS Nitro Enclaves. The trust model is identical. You are not locked in.
Where this wins first
Teams are shipping AI agents into production workflows that touch proprietary code, customer data, and live infrastructure credentials. The infrastructure these agents run on was built for throughput and cost optimization, not for proving what happened. Standard cloud inference exposes sensitive data to every layer of the stack. Audit logs record that requests happened but do not prove they were sealed or authorized. Teams manage the gap through policy and hope.
If you are building a product that needs to close that gap, here are the use cases where this architecture pays for itself fastest.
Agent teams with production access. An engineering team deploys a multi-agent system where one agent writes code, another reviews pull requests, and a third deploys to production. Each agent has different permissions: the coder can read the repo, the reviewer can comment but not merge, the deployer can push to staging but not production without approval.
The team delegates authority to each agent through NEUS, issuing trust receipts that scope each agent to its specific role and permitted actions. Every model call flows through Phala's confidential inference API into a TEE enclave, so proprietary code, internal docs, and API keys are sealed during inference. The model provider never sees them.
When something goes wrong, the team can trace exactly which agent made which call, under whose authority, and prove the runtime was sealed. The receipts show the chain of delegation. The attestations show the compute was genuine. No guessing, no log archaeology.
Agents handling customer data. A startup ships an AI agent that reads customer support tickets, analyzes usage patterns, and drafts responses. The agent has access to customer PII, conversation history, and product telemetry. Standard cloud inference exposes all of that to the model provider's infrastructure.
The founder delegates authority to the agent through NEUS, scoping it to specific data sources and permitted actions. The agent calls the model through Phala's confidential inference API into a TEE enclave. Customer data is sealed in the enclave during inference. The model operator sees none of it.
The startup can show customers that their data was never exposed in plaintext outside a verified enclave, and that the agent acted under explicit, scoped authority. Both proofs are independently verifiable. No vendor assurances required.
Multi-agent systems with shared credentials. A platform team runs a fleet of agents that each need access to different internal APIs, databases, and third-party services. Today they share API keys through environment variables and hope nothing leaks. If an agent goes rogue or a key gets exposed, the blast radius is the entire credential set.
With the trust harness, each agent gets a scoped NEUS receipt that defines exactly which resources it can access. API keys are sealed inside the enclave and decrypted only during inference. The team can revoke an agent's authority instantly by revoking its receipt. Every call is logged against the specific agent and the specific delegation that authorized it.
Why build on Phala instead of building your own TEE stack
Building a confidential compute platform from scratch means years of work on infrastructure that is not your product. The TEE stack alone includes attestation primitives, KMS logic, key derivation chains, GPU CC mode integration, encrypted storage, encrypted networking, multi-tenant resource management, and the open-source OS image that goes into every VM. Most teams who try this end up rebuilding the same things, slower, with less rigor, and without the open-source scrutiny that makes the result trustworthy.
Phala has done this work. It is running in production for teams like NEUS, OpenRouter, Z.AI, OPPO, Venice AI, NEAR AI, and Uniswap. The stack is open-source and auditable. The hardware is real and attested. The proof is cryptographic, not promised.
When you build your trust layer on Phala, you spend your time on the part that is actually your product: governance, delegation, receipts, agent orchestration, the user experience of trust. You do not spend it on TDX attestation chains. You do not run KMS hardware. You do not chase NVIDIA confidential-computing mode integration. You compose your layer on top of a substrate that already produces the proof you need.
Start building
The trust harness replaces policy with proof. Sealed inference from Phala, governed action from your layer, attestation throughout. One pipeline producing two independent cryptographic artifacts per action, with zero dependence on trusting any single party.
If you are building a trust layer, evidence layer, or audit infrastructure for AI agents, you do not need to build the substrate. It exists.
- dstack (open source): github.com/Dstack-TEE/dstack
- Phala Cloud (managed): phala.com
- NEUS (governance layer partner): neus.network
