TEE for AI Agents: What Hardware Isolation Can Prove

A trusted execution environment (TEE) for AI agents is useful only if the customer can answer two different questions. Can the machine administrator read or change the private work while it runs? Did the approved program run inside the protected boundary?

Suppose an agent must inspect a private contract with a model hosted by another team. An agent profile is the versioned bundle of model choice, tools, instructions, and output schema that the workflow expects. The runtime is the process and machine environment that carries out that profile. An ordinary container can package the code, but the host administrator may still control the kernel, memory, storage, logs, and network around it.

A TEE changes that boundary with hardware-backed isolation. An attestation report is signed evidence about the protected environment and selected measurements of the code and configuration that started there. A measurement is a cryptographic fingerprint of a relevant image, binary, boot component, or configuration. The client can use the report before releasing a secret or private input.

The evidence has a precise scope. A TEE can support a claim about where approved code ran and which workload identity the hardware reported. It cannot prove that the code is correct, that the model is safe, that the result is useful, or that data is protected after it leaves the workload.

Tangle is a coordination network for services that independent parties run. Its contracts record selected registration, service, payment, verification, and lifecycle state while application work runs outside the chain. Off-chain means computed outside the blockchain, while on-chain means recorded in blockchain state. Tangle represents that choice as an execution policy on a Blueprint, a reusable service template. An operator is the party that runs the Blueprint and its Services. A Service is one configured instance with an owner, operator set, payment terms, and lifecycle state. A Blueprint Manager is the operator-facing process that selects an eligible runtime and keeps the Service aligned with protocol state. The current Tangle execution confidentiality guide documents the policy and its runtime behavior.

A TEE protects a boundary, not a promise

An ordinary container is a packaging and process-isolation mechanism. It can make dependencies reproducible and limit some operating-system access. The host usually retains administrative control over the machine that runs it.

A TEE adds a hardware-enforced boundary around a workload. The exact boundary depends on the hardware and provider. Amazon Web Services (AWS) Nitro Enclaves, Google Confidential Space, AMD SEV-SNP, Intel TDX, and other systems expose different interfaces and threat models.

The customer should phrase the desired claim like this:

Approved claim:
  The workload identified by measurement M ran on an accepted TEE platform.

Still separate:
  The workload implements the intended function.
  The output is correct for the task.
  The network and output path reveal no sensitive data.
  The provider will keep the service available.

That wording prevents the common mistake of treating “confidential” as a complete service guarantee.

The AWS Nitro Enclaves security documentation describes isolation from the parent instance, no external networking, no persistent storage, and an attestation feature for enclave identity. Those are properties of that provider’s system, not a universal description of every TEE.

Tangle makes confidentiality a service policy

The current Tangle model keeps artifact sources and confidentiality intent separate. A source says how an operator fetches and executes an artifact. Confidentiality says whether the service accepts ordinary execution, prefers a TEE, or requires one.

The documented policy values are:

Policy	Meaning	Failure behavior
`any`	Standard and TEE execution are acceptable	The manager may choose an eligible path
`tee_preferred`	Prefer a TEE when the operator can provide one	Standard execution remains an explicit fallback
`tee_required`	Only a TEE execution path is acceptable	Fail closed when requirements cannot be satisfied
`standard_required`	Use ordinary non-TEE execution	A TEE path is not selected

“Fail closed” means the service refuses to start or accept the protected path rather than silently downgrading to a weaker environment. That behavior matters when the customer’s privacy requirement is mandatory.

The policy belongs in the public Blueprint definition. If it lives only in an operator’s local setting, the customer cannot inspect the promise before creating a Service.

The current public manifest shape is shown below; the names and values are illustrative:

{
  "metadata_uri": "ipfs://your-blueprint-metadata",
  "metadata": {
    "name": "confidential-prover",
    "execution_profile": {
      "confidentiality": "tee_required"
    }
  },
  "sources": [
    {
      "kind": "container",
      "registry": "ghcr.io",
      "image": "acme/confidential-prover",
      "tag": "1.2.0"
    }
  ]
}

The fields and policy value match the public documentation. The complete deployment definition also needs the fields required by the target network and SDK release. Do not add a fictional “TEE source” beside the container source. The policy is layered on top of the source.

The current Tangle documentation says that only container sources are eligible for TEE placement on the manager path. It also says that tee_required filters out non-container sources and fails when the operator lacks the required TEE runtime prerequisites. For local container execution, the documented requirement is a Kubernetes kata runtime class. For remote execution, the operator must configure a TEE-capable provider and an attestation policy.

Attestation is a handshake

Attestation works as a handshake between a workload and a relying party. A relying party is the client or service that decides whether to trust the report for a specific action, such as releasing a key.

The common sequence is:

The workload starts inside the protected environment.
Hardware or a provider attestation service creates a signed report or token.
The report includes measurements, provider identity, freshness data, and sometimes an ephemeral public key.
The client verifies the signature chain and compares the claims with its policy.
The client releases only the secret or input that the accepted workload should receive.
The workload processes the data and returns an output through the defined application path.

The measurement is usually a digest rather than a human-readable version name. The client should compare it with an approved value and decide how upgrades change that value.

Freshness prevents an operator from presenting a valid report from an old workload as evidence for a new request. A nonce is a unique value included in a challenge so the resulting report is bound to that exchange. An expiry or issued-at value serves a related purpose when the provider’s protocol uses tokens with a defined lifetime.

The AWS attestation guide says that Nitro Enclaves can request a signed attestation document from the Nitro Hypervisor and that an external service can compare its measurements with an access policy. The Google Cloud attestation guide describes a similar policy flow in which claims about a confidential environment become signed tokens that services such as Secret Manager or identity and access management (IAM) can check.

The report is evidence only after the relying party verifies it.

Releasing secrets without handing them to the host

A protected workload often needs a key, model weight, or customer document after it starts. Putting that value in an ordinary environment variable gives the host a straightforward place to inspect it. Attestation can move the release decision to a key service or client that is willing to trust only an approved measurement.

A common pattern uses an ephemeral key pair created inside the protected workload. The workload sends the public key as part of an attested handshake. The client validates the report and encrypts the secret to that public key. Only the workload holding the private key can decrypt it.

The following TypeScript-like pseudocode is illustrative. It describes the policy decision rather than claiming a Tangle SDK function name:

const report = await workload.getAttestation({ nonce })
const claims = await verifyProviderReport(report)

if (!policy.accepts({
  measurement: claims.measurement,
  provider: claims.provider,
  fresh: claims.nonce === nonce,
  debug: claims.debug === false,
})) {
  throw new Error('refusing to release the secret')
}

await workload.send(encryptFor(claims.ephemeralPublicKey, secret))

The policy must bind the secret to the exact workload and request. Accepting any valid report from the provider is too broad if the provider hosts many unrelated images. Accepting the right measurement without freshness is vulnerable to replay. Accepting a fresh report without checking debug status or configuration can weaken the intended boundary.

The provider’s key-release and report-validation documentation remains authoritative. Tangle can record the Blueprint policy and Service intent, but it does not replace the provider’s cryptographic verification library.

Provider reports are not interchangeable

The words “TEE” and “attestation” hide provider-specific behavior.

Provider example	Protected workload model	Evidence and operational detail
AWS Nitro Enclaves	An enclave receives dedicated virtual CPUs and memory from a parent Elastic Compute Cloud (EC2) instance	Nitro generates a signed attestation document; the enclave has no external network or persistent storage
Google Confidential Space	A workload runs in a confidential virtual machine (VM) with an attestation service	Tokens can carry hardware, image, debug, nonce, and container claims under an attestation policy
Azure confidential VMs	A confidential VM uses hardware-backed isolation and attestation services	Guest attestation can expose platform and boot-state claims for a relying party

The Google Confidential Space token-claims reference shows how image digests, hardware models, debug status, nonce, issue time, and expiry can appear in an attestation token. The Azure guest-attestation guide explains that a guest can obtain a platform report and present an attestation token to a relying party before receiving sensitive resources.

The Tangle software development kit (SDK) can present a common Blueprint-facing policy while the provider differences remain real. Startup time, available hardware, report format, image identity, network path, logging, storage, update procedure, and key-release behavior vary by provider. Document the provider and hardware family that the Service accepts.

What a TEE proves about an AI service

Imagine an inference Blueprint that accepts a private prompt and returns a structured decision. An evaluation is a repeatable test of a model or agent on a defined task set. A trace is the time-ordered record of the execution path. The service can collect several kinds of evidence:

Evidence	Supports	Does not support
Approved container digest	Which image should run	That the image was launched successfully
Attestation measurement	Which measured workload the provider reported	That the workload’s algorithm is good
Model weight digest	Which model files the workload loaded, if included in the measured claim	That the model follows the task policy
Input and output trace	What the application recorded during the run	That an unprotected process did not observe a value elsewhere
Task evaluation	Whether selected examples satisfy the acceptance rule	That unseen prompts will behave the same

The combination is stronger than any line alone. It is still a set of bounded claims.

A canary is a known input chosen to catch a selected behavior change. The AI service guide in this series explains how inference evidence, sandbox evidence, and task evaluations fit together.

If the model’s output is wrong because the prompt was underspecified, the TEE has done its job and the application has still failed. If the model weights are correct but the output is altered after the protected process returns, the TEE claim ends at the output boundary. If a customer sends the secret to the wrong endpoint before the attestation check, the later report cannot undo that disclosure.

Confidentiality policies change availability

tee_required can protect a high-value input from accidental downgrade. It also means an operator without the right hardware or runtime cannot serve the Job. The customer must accept the resulting availability and cost tradeoff.

tee_preferred can keep more operators eligible. It also allows standard execution, so the customer needs a policy for when a fallback is acceptable. “Preferred” should never be presented as “protected.”

any maximizes placement options. It is appropriate for a workload whose confidentiality requirement is optional or whose inputs are already public.

standard_required can be useful when the application depends on ordinary runtime features that the TEE path cannot provide. The policy is a product decision about data and threat model, not a ranking from weak to strong.

The service owner should surface the policy before a customer funds or invokes the Service. At the protocol layer, current Tangle documentation also describes confidentiality intent in service requests and operator quotes. That allows a customer’s requested mode to become part of the Service agreement instead of an undocumented operator preference.

Failure cases that break the easy story

The report is valid for the wrong image

The provider can honestly attest to an image that the customer did not approve. Compare the exact measurement or image digest with a policy maintained by the customer or Blueprint.

The image is correct, but the code is wrong

Attestation binds the identity of code, not its meaning. Review the code, test vectors, model configuration, and evaluation in a standard deployment.

The report is old

Use a nonce, issued-at claim, expiry, or provider-specific freshness rule. The policy should reject a report that can be replayed for a different request.

Debug mode is enabled

Debug configurations may weaken the protection or make the environment unsuitable for secrets. Check the provider’s debug claim and fail closed when the policy requires production configuration.

The model downloads weights after attestation

If the measured workload can fetch arbitrary weights after the report is issued, the image measurement alone may not identify the model that served the answer. Bind model identity into the measured configuration, enforce an allow-list, or state that the model choice remains outside the attestation claim.

The output path leaks the input

The host may not read protected memory while the Job runs, but the application can write sensitive data to logs, return it in an error, send it to an unrestricted network endpoint, or persist it to a shared store. TEE isolation does not replace output filtering and network policy.

The provider has a side channel

Hardware isolation reduces a class of host inspection risks. Timing, cache, memory-access patterns, bugs in the workload, and provider implementation details can create other paths. Assess the provider and hardware against the data’s sensitivity.

An update changes the measurement

Rebuilding a container, changing a boot component, or rotating a model can change the report. Plan the approval, rollout, and rollback process around the new measurement. Do not silently accept every new digest because the service needs to restart.

The TEE is unavailable

With tee_required, a failed placement should be visible as an unavailable service rather than silently becoming ordinary execution. With tee_preferred, the Service must expose when it fell back and let the customer decide whether that result remains acceptable.

A TEE is one layer in an AI service

For a private document-analysis agent, a defensible path can look like this:

The agent profile names a model, tool set, output schema, and data-retention policy.
The Blueprint publishes a versioned container and tee_required policy.
The operator starts the container on a TEE-capable runtime.
The client validates a fresh attestation against the approved measurement.
The client releases the document or model key only after the check passes.
The job runs with a restricted network, filesystem, and output policy.
The service returns a trace reference, model identity, and evaluation result.
The customer can reject the result if the attestation or task check fails.

The TEE addresses the operator’s access to protected memory during execution. The Blueprint addresses service coordination and declared policy. The evaluation addresses task quality. The trace addresses inspection. The output policy addresses what leaves the boundary.

The Tangle verification guide explains why those checks should not be collapsed into one “verified” label.

When to choose hardware isolation

Use a TEE when the customer needs protection from the host operator during execution, can validate the attestation before releasing secrets, and accepts provider-specific hardware and availability constraints.

Multi-party computation (MPC) keeps one operator from holding a complete input by splitting the computation across participants. The NIST MPC definition describes that privacy boundary. Use an MPC protocol when no single operator should hold the complete input and the computation can tolerate a multi-party protocol.

Use ordinary containers when the input is public or the provider is already inside the accepted trust boundary.

Use a stronger result evaluation or proof when the main risk is an incorrect answer rather than host inspection.

Many services need more than one. A private AI service can require a TEE, pin the model digest, record a trace, and run an evaluation set. The correct description is the intersection of those claims, with each assumption stated.

Does a TEE prove that an AI answer is correct?

No. It provides evidence about the protected environment and measured code. The answer needs a separate evaluation, proof, or application-specific correctness check.

Can the operator see data inside a TEE?

The hardware boundary is designed to restrict the ordinary host from reading protected memory. The exact guarantee depends on the provider, hardware, configuration, workload, and output path. The operator may still observe metadata such as timing, traffic volume, or whether a job ran.

Is a TEE the same as a software container?

No. A container packages and isolates processes through software controls. A TEE adds a hardware-backed boundary and an attestation mechanism. A confidential service may use both, but they support different claims.

What should a client check in an attestation report?

Check the signature chain, provider and hardware identity, expected measurement, debug status, freshness or nonce, audience, expiry, and any key-binding claim required by the protocol. Reject the report when the provider’s policy or the Blueprint’s approved values do not match.

What happens when the TEE cannot start on Tangle?

With tee_required, the current Tangle policy is intended to fail closed when the required TEE runtime cannot be satisfied. With tee_preferred, standard execution may be used as a fallback, so the customer must decide whether the fallback is acceptable.

Does Tangle make cloud providers interchangeable?

No. Tangle can expose a common execution policy, while provider report formats, hardware, startup time, networking, storage, and key-release behavior remain different. The Service should name the accepted provider and policy.

Public sources

The Tangle execution confidentiality guide documents policy values and manager behavior. The AWS Nitro Enclaves security guide documents one provider’s isolation boundary. The AWS attestation guide documents signed measurements. The Google Cloud attestation documentation documents claims and relying-party policy. The Azure guest-attestation guide documents a confidential VM handshake. The NIST MPC definition describes the privacy boundary of multi-party computation.

Hardware isolation is worth adopting when it changes what data the customer is willing to send. It should be described as evidence about a boundary, followed by the separate tests that establish whether the work itself is correct.