AI Agent / Web3·EVM · Multi-chain
Phala Network
Phala Network helps teams ship privacy-sensitive AI agents and backend workflows inside confidential VMs instead of exposing prompts, signing keys, or model inputs on a standard cloud host. This protocol reference now leads with the builder questions searchers actually have: when Phala fits for trusted execution, how dstack and remote attestation shape deployment, and what operational tradeoffs matter before a team commits to TEE-backed infrastructure.
- 01Package the agent or backend worker as a Docker image, then map secret handling and signing flows so the workload can move into a Confidential VM without exposing raw keys on the host.
- 02Use the dstack SDK to derive sealed keys inside the CVM and bind attestation payloads to the exact outbound action or request hash that downstream verifiers need to trust.
- 03Plan for remote attestation verification, image-measurement changes, and replay protection before shipping production automation on top of TEE-backed execution.
- 04Keep a local simulator or non-TEE fallback for development, but document where behavior changes once the workflow depends on real Phala Cloud hardware attestation.
- 01TEE-protected agent keys
- 02verifiable agent execution
- 03private LLM inference (GPU TEE)
- 04ERC-8004 trustless agents
- 05Docker-native confidential deployment
- pnpm add @phala/dstack-sdk
- pnpm add -g phala-cloud-cli
| Variable | Scope | Description |
|---|---|---|
| PHALA_CLOUD_API_KEY | Server | API key for Phala Cloud used by `phala` CLI to deploy and manage CVMs. |
| DSTACK_SIMULATOR_ENDPOINT | Server | Optional — local dstack simulator URL (e.g. http://localhost:8090) for dev without TEE hardware. |
Use Phala to run an agent inside a Confidential VM (CVM) so its keys never leave the TEE. Package the agent as a Docker image, mount the dstack socket via `volumes: - /var/run/dstack.sock:/var/run/dstack.sock` in `docker-compose.yaml`, and deploy with `phala deploy`. From inside the container, derive a deterministic agent wallet with `client.deriveKey('agent/wallet')` from `@phala/dstack-sdk` (the key is sealed to the CVM image hash) and sign transactions with viem. Generate an attestation per outbound action via `client.tdxQuote(reportData)` where `reportData` is a hash of the request — relayers / verifiers check the quote against Intel's PCCS so off-chain consumers know the agent ran the audited image. For private LLM inference, route to a GPU-TEE endpoint instead of public OpenAI.
- ⚑Attestation quotes must be verified against the full Intel TDX certificate chain (PCCS) — accepting just the quote without chain validation is unsafe.
- ⚑Sealed keys are bound to the image measurement — any code change rotates the key, breaking continuity unless you migrate state via a key-derivation hierarchy.
- ⚑GPU TEE inference is supported on a limited set of GPUs (H100/B200 confidential mode); cheaper inference providers are not equivalent.
- ⚑CVMs cost more than plain VMs and have noticeable cold-start latency; for chatty agents, keep the CVM warm.
- ⚑Logs from inside a CVM may leak prompts/keys if printed unredacted — treat the agent like a server-side wallet, not a debug console.
- ⚑Local dev without `DSTACK_SIMULATOR_ENDPOINT` will hard-fail on `tdxQuote` calls; gate TEE-specific code behind a feature flag.
- ⚑Replay protection is your job — bind a nonce or chain block hash into `reportData` so a previously verified quote cannot be replayed.