An agent pays for a private inference job and receives a fluent answer. The answer looks fine, but the agent still has two unanswered questions.
Did the service run the approved model, or did the service provider substitute a cheaper one? Could the service provider read the prompt and model weights while the job was running?
An x402 payment is an HTTP payment flow that can answer the first question in a narrow financial sense: the client authorized a transfer under specified terms. A trusted execution environment can provide evidence about the code and hardware boundary where the job ran. Neither mechanism, alone or together, proves that an AI answer is correct.
For an AI agent that must keep code and data inside a defined security boundary, use a TEE, a trusted execution environment, signed platform evidence (attestation), sealed-secret delivery, and a separate result check. The system makes several smaller claims, and each claim has its own evidence and failure mode.
Separate payment, runtime, and result checks
Use x402 to decide whether a paid request is authorized. Use a TEE when the service provider should be blocked from ordinary access to sensitive code or data while the job runs. Use attestation to let a client check that the intended workload started inside the intended protected environment. Use a separate evaluation or verification method to judge whether the result is correct.
In a production Blueprint, fail closed when a required gate is missing. Do not silently run an unattested or differently measured workload because payment has already settled. If payment settles before execution, your recovery policy must explain what happens when the TEE cannot start.
Define the trust boundary
A Blueprint is a public Tangle service definition that describes jobs a service provider can run and the rules around the service.
An operator is the person or team that supplies infrastructure and runs a service instance.
A runtime is the process, dependencies, model, and permissions that execute a job.
A trusted execution environment, or TEE, is a hardware-backed area intended to isolate a workload from the ordinary host operating system. Isolation is the boundary; attestation is the evidence about what started inside it.
An attestation is a signed statement from a platform or protected workload about its environment and measurement. A measurement is a cryptographic fingerprint of selected code, image, configuration, or boot state.
An attestation checker is the component that authenticates an attestation and applies a policy to its claims. The Remote Attestation Procedures, Architecture and Application (RATS) architecture in RFC 9334 separates the system that produces evidence, the component that evaluates it, and the party that decides whether the evidence is sufficient.
An evaluation is a test against an expected condition, such as “the output matches the schema.” Verification asks whether evidence satisfies a rule. An evaluation of the answer and an attestation of the runtime are different checks.
An x402 payment is an HTTP payment exchange built around a 402 response and payment authorization headers. It says who authorized what payment, not what code ran.
A trace joins the payment, attestation, job, runtime attempt, and result with timestamps and identifiers. It is an audit trail for one request, not proof by itself.
Start with the claim, not the hardware
Suppose an agent sends a confidential document to a summarization service. The service promises three things:
- The client pays only the quoted amount on the approved network and token.
- The document is processed by a particular released workload inside an acceptable protected environment.
- The returned summary has the promised shape and finishes before the deadline.
Those promises need different evidence.
| Promise | Useful check | What remains outside the claim |
|---|---|---|
| Payment authorization | x402 verification and settlement record | Correctness, availability, and confidentiality of the job |
| Approved workload | Attestation signature, measurement, provider, freshness, and policy | Whether the approved code itself is bug-free |
| Confidential execution | TEE isolation and sealed-secret exchange | Side channels, application logging, provider-specific limits |
| Valid result | Schema, deterministic check, proof, or task-specific evaluation | Whether the check captures the user’s real notion of quality |
| Timely service | Trace, queue state, runtime deadline, and health signals | Future availability after this request |
Payment settlement does not prove workload identity, secrecy, correctness, or future availability.
Where the TEE sits in the paid path
The execution order should make the dependency visible.
agent profile
|
| request + private input reference
v
x402 gateway
|
| verify payment, then settle according to policy
v
Blueprint job admission
|
| require an acceptable attestation before releasing secrets
v
TEE runtime ---- attestation report ----> attestation checker
|
| execute approved handler
v
result + runtime evidence + traceThe agent profile is the client’s policy for accepted networks, tokens, prices, workload identity, and result checks. The client may reject a payment requirement or attestation that falls outside that profile.
The protected workload should not receive a private secret merely because a process claims to be in a TEE. The client or a key-exchange service should verify the report, measurement, provider, freshness, and policy first.
The public Blueprint TEE README describes this general architecture, including attestation reports, claims, attestation checkers, provider integrations, exchange sessions, middleware, and direct, remote, and hybrid deployment modes.
Choose where protected work runs
The public software development kit (SDK) describes three ways to place protected work.
| Mode | Protected component | Useful when |
|---|---|---|
| Direct | The Blueprint runner itself | The service boundary should include most of the process |
| Remote | A separate protected cloud workload | The runner manages a provider-specific confidential instance |
| Hybrid | Only selected jobs or components | Public work and sensitive work need different boundaries |
Direct mode can reduce the number of network hops between the runner and the protected handler. It can also make accelerator, device, and host compatibility the operator’s problem.
Remote mode can use a provider-specific protected workload while an ordinary runner handles orchestration. That can simplify provisioning and isolate secrets, but the control-plane connection becomes part of the threat model.
Use hybrid mode when pricing, queueing, and public health endpoints can remain public while private inputs, model weights, and inference must run inside the TEE. The boundary must be documented because a private input sent through an ordinary preprocessing step is no longer protected by the inference enclave.
The repository currently lists provider feature families including AWS Nitro, Azure SNP, Google confidential computing, Intel TDX, and AMD SEV-SNP. Availability and claims differ by provider and hardware, so the public TEE package and provider documentation are the authority for a particular release.
A production gate in plain language
The public software development kit (SDK) exposes a builder shape for requiring TEE execution. The following is a condensed example based on that public interface, with the surrounding application configuration omitted.
let tee = TeeConfig::builder()
.requirement(TeeRequirement::Required)
.mode(TeeMode::Direct)
.build()?;Required means the service should not silently continue without an acceptable TEE.
That is a policy choice, not a magic hardware guarantee.
A complete production check should answer:
| Check | Question | Failure action |
|---|---|---|
| Provider identity | Is the report from a supported platform? | Reject the workload |
| Signature | Can the report be authenticated? | Reject the workload |
| Measurement | Is the approved code or image represented? | Do not release secrets |
| Debug or development mode | Is the platform running with weakened protections? | Reject or explicitly downgrade policy |
| Freshness | Is the evidence within its accepted age? | Re-attest or stop |
| Policy binding | Does the report bind to this service and session? | Reject the exchange |
| Deployment record | Does an optional on-chain digest match the report? | Stop and investigate |
| Secret path | Are secrets delivered only after checks? | Never fall back to ordinary environment injection |
The “deployment record” row is optional only if your trust model does not require an on-chain commitment. The public SDK documents local evidence checks and an optional comparison with an on-chain attestation hash. Do not enable a comparison before the expected record has been provisioned and tested.
What attestation says
An attestation report normally contains claims about the platform and workload. A policy checker authenticates the signature, extracts the claims, and applies a policy. The relying party then decides whether those claims are enough for the particular secret or job.
That final decision matters. An attestation can say “this measurement ran on this class of hardware” while the measurement identifies a vulnerable application. It can say “the enclave image is approved” while the application returns an incorrect summary. It can be fresh and authentic while the service leaks data through logs or a network call outside the protected boundary.
Treat attestation as evidence with a scope, not as a synonym for trust.
AWS’s Nitro Enclaves attestation documentation is a useful example of this boundary. The platform exposes platform configuration register (PCR) measurements that identify enclave image and configuration choices, and debug-mode behavior changes the security meaning of those measurements. The application still needs to define which PCR values it accepts and what secret release follows.
Sealed secrets and exchange sessions
An ordinary container often receives a secret as an environment variable. That is convenient and easy to inspect from the host. It is the wrong default when the purpose of a TEE is to keep the secret away from the host operator.
A sealed-secret flow binds encryption to an attested workload. The protected workload creates an ephemeral key pair. Its public key is associated with the attestation evidence. After the attestation checker accepts the evidence, the client encrypts the secret to that key. Only the workload holding the private key can decrypt it.
The exchange should have a short lifetime and a one-time-use policy where possible. The public SDK describes ephemeral exchange sessions and sealed-secret handling as part of its TEE support.
The sequence is:
- Start the protected workload.
- Obtain an attestation report that binds to its ephemeral exchange key.
- Verify provider, signature, measurement, debug state, freshness, and service policy.
- Encrypt the secret to the reported public key.
- Deliver it through the protected exchange channel.
- Expire the session and destroy temporary key material.
If step three fails, do not fall back to an ordinary environment variable to keep a paid request moving. Return a controlled execution failure and apply the payment recovery policy.
x402 and TEE failure states
Payment and execution can fail independently after a 402 Payment Required response.
402 payment required
|
+-- payment rejected ------------> no execution
|
+-- payment settled ------------- > TEE admission
|
+-- attestation rejected
| -> no secret release
|
+-- attestation accepted
-> run job
|
+-- result evaluation fails
+-- result evaluation passesIf payment settles and attestation fails, the trace should say exactly that. The client should not receive a generic “invalid payment” message because the payment may be valid while the execution gate failed.
If attestation passes and the model returns a poor answer, the service still needs an evaluation or dispute path. The TEE proves the approved runtime was available under the policy; it does not inspect the meaning of a generated sentence.
A worked decision for private inference
Imagine a document-analysis Blueprint with a private model and three job types.
| Job | Data | Protection policy | Result check |
|---|---|---|---|
estimate_tokens | Public metadata | Ordinary runtime | Deterministic count |
summarize_private | Customer document | TEE required, sealed secret path | Schema and citation checks |
debug_sample | Synthetic fixture | TEE preferred | Golden fixture evaluation |
This service should not require a TEE for the public token estimate if doing so adds cost without protecting sensitive data. It should require a TEE for the private summary and refuse to release the document until the report passes policy. It can allow a fallback for the synthetic fixture if the product explicitly accepts that weaker guarantee.
The policy is visible in the job definition and agent profile. An operator cannot turn a required private job into an ordinary process without changing the service’s published security claim.
Trace the evidence without leaking the input
A useful trace for summarize_private might contain:
trace: tr_8f2
payment: settled
service_job: summarize_private
artifact_digest: sha256:<approved-image>
tee_provider: <provider-family>
measurement: <approved-measurement-id>
attestation_age: 41 seconds
secret_exchange: accepted_once
runtime: succeeded
evaluation: schema_passed, citations_review_requiredThe trace should not contain the private document, plaintext secret, or full model output unless the user has explicitly chosen that retention. The measurement and attestation identifiers are useful because they let an investigator compare the run with the approved release.
Limitations and failure cases
The approved image has a bug. Attestation can show that the approved image ran, not that the code is correct. Use tests, formal checks, proofs, or task-specific evaluations for correctness.
The workload makes an unprotected network call. The TEE may protect memory while the application sends the document to another service. Review egress permissions and application behavior.
The platform enters debug mode. Debug settings can weaken isolation or alter measurement semantics. Treat debug mode as a separate development policy and reject it in the production profile unless the threat model explicitly allows it.
The machine reboots. The old attestation and exchange key may no longer describe the new workload. Require fresh evidence and make re-provisioning part of the recovery runbook.
The provider is unavailable. A required TEE should fail closed, but the payment path still needs a clear failed-execution outcome after settlement.
The attestation checker is misconfigured. Accepting any valid report from any provider is not the same as accepting the approved workload. Pin provider, measurement, freshness, and policy inputs deliberately.
The result is semantically wrong. An attested language model can still hallucinate. The service must say which quality checks are present and which require a human or downstream system.
State the guarantee precisely
Use a TEE for a job when the operator’s ordinary access to the code or data is part of your threat model. Use x402 for the payment decision, but keep it separate from the execution-integrity decision. Require attestation and sealed-secret exchange before releasing private inputs. Add a task-specific evaluation for the result, and preserve a redacted trace that shows which gates passed.
“This payment authorized this job, and this approved measurement ran it in an accepted protected environment under this policy.” That statement is valuable precisely because it does not pretend to prove more.
The x402 payments guide explains the admission path before this execution gate. The Tangle verification guide compares result checks that a TEE cannot replace.
Does a TEE prove that an AI agent gave the right answer?
No. It provides evidence about the environment and measured workload. Answer quality still needs a separate evaluation or verification method.
Does x402 protect private inputs?
No. x402 handles payment authorization and settlement metadata. Confidentiality depends on the application boundary, transport, storage, TEE policy, and secret-delivery path.
Is a TEE required for every Blueprint job?
No. Set the requirement per service or job according to the data and threat model. Requiring hardware protection for public, deterministic work can add cost without adding a useful guarantee.
What should the attestation checker check?
It should check the platform identity and signature, approved measurement, debug state, freshness, service or session binding, and any on-chain commitment required by the deployment policy.
Can the operator still control the service around the TEE?
Usually, yes. The operator may control deployment, routing, logs, timing, and network availability outside the protected workload. The threat model must include those boundaries.
For the deployment choices around remote providers and recovery, see Blueprint deployment architecture.
Public sources
The Blueprint TEE package documents current SDK architecture and configuration. RFC 9334 defines the remote-attestation roles and evidence model. AWS Nitro Enclaves attestation guidance explains measurements and platform-specific policy. The x402 protocol repository documents the payment flow that precedes execution.