TEE & Attestation

The Agent API runs inside a hardware-isolated confidential VM (Intel TDX, on Phala’s dstack). TLS ends inside that VM, so the machine that hosts it only ever carries ciphertext, and anyone can check which code is running.

At a glance

Inside the attested VM: the API server, its database on an encrypted disk, encrypted backups, TLS termination, the geofence and the transparency log notary.
Not inside it: agent funds. They sit in each agent’s wallet on NEAR Intents, under the policy the owner signed.
Proof: GET /tee/attestation returns a TDX quote that binds the API’s TLS key, the notary’s keys and your own nonce.
Verify it in about 15 minutes with curl, openssl, jq, xxd, base64 and Docker. No API key needed.

What it guarantees

What the TEE gives you

TLS ends inside the attested VM. Its certificate key is created there and never leaves it.
The host machine can’t read requests, keys or the database.
Every container image is pinned by digest in the compose file that the quote attests.
The notary that signs the transparency log holds keys bound into the same quote.

What it doesn't cover

Funds. They’re in the agent’s wallet on NEAR Intents, not in the VM. The policy limits what the API can do with them.
Gateway metadata. Phala’s gateway, in its own TEE, sees the caller’s IP address and the host name. Everything else is encrypted.
Logs and metrics. A telemetry container (Grafana Alloy) sends them out of the VM to Grafana Cloud. Before a log line leaves, every IPv4 address is replaced with <redacted> and Postgres DETAIL lines, which quote row values, are dropped. Its write token is a sealed secret.
Rebuilding from source. The images are built reproducibly, but the source isn’t public yet, so you can check which images run, not rebuild them.

What runs inside

Part	Role
API server	The Agent API itself
Postgres	Data, on the VM’s encrypted disk
Backups	Encrypted to a key only this app’s VMs can derive, and to the operator’s offline break-glass keys. Each has a signed manifest (`<object>.manifest.json`: name, SHA-256 and size), signed by an Ed25519 key derived in the enclave. A restore verifies it before anything decrypts.
Edge and TLS	Geofence, then TLS with a Let’s Encrypt certificate obtained inside the VM
Ingress	Host pinning, per-address rate limit, balancing across server processes
Attestation and notary	Serves `/tee/*`, and signs transparency log checkpoints
Telemetry	Grafana Alloy. Sends metrics and logs to Grafana Cloud, with IPv4 addresses redacted and Postgres `DETAIL` lines dropped.

Geofence

Connections from these jurisdictions are refused before TLS completes, matching the NEAR AI Cloud terms of service: Cuba, Iran, North Korea, Syria, and the Crimea (Sevastopol included), Donetsk and Luhansk regions of Ukraine. A refused client sees a closed connection, not an HTTP error. Addresses are placed by where they were allocated, so a caller on a rented foreign host is placed by that host.

Endpoints

All three are public GETs on the API host.

Endpoint	Returns
`/tee/info`	`app_id`, `app_name`, `instance_id`, `compose_hash`, `os_image_hash`, `mr_aggregated` and `app_compose`, the full compose the VM booted
`/tee/attestation?nonce=<64 lowercase hex>`	A fresh TDX quote (`attestation`), with `report_data`, `tls_cert_fingerprint`, `signing_address`, `signing_algo` (`ed25519`), `log_key`, `notary_key` and your `request_nonce`
`/tee/notary`	The notary’s `log_key`, `notary_key` and `signing_address`, its latest `checkpoint`, and its `birth` quote, which transparency proofs check against

/tee/info and /tee/attestation can answer 503 with {"error":"busy"} and Retry-After: 1 when quote requests are already in flight, so try again after a second. Either can answer 502 with {"error":"attestation_unavailable"} when the VM could not produce the answer. A nonce that is not 64 lowercase hex characters is a 400.

Verify it yourself

This walkthrough checks that a connection to api.agentsonintents.com ends inside a genuine, up-to-date TDX VM running the compose it publishes, and that the notary keys belong to that VM.

Prerequisites

curl, openssl, jq, xxd and Docker. Work in an empty directory:

HOST=api.agentsonintents.com

Read the VM's identity

curl -s "https://$HOST/tee/info" -o info.json
jq 'del(.app_compose)' info.json

Note app_id. It stays the same across releases of this deployment. compose_hash changes with every release.

Ask for a quote with your own nonce

A fresh nonce proves the quote was made for you, now.

NONCE=$(openssl rand -hex 32)
curl -s "https://$HOST/tee/attestation?nonce=$NONCE" -o att.json
jq 'del(.attestation)' att.json

request_nonce must equal $NONCE.

Get the TLS key fingerprint yourself

The SHA-256 of the certificate’s public key (SubjectPublicKeyInfo), read from your own connection:

TLS_FP=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -r | cut -d' ' -f1)
echo "$TLS_FP"

It must equal tls_cert_fingerprint in att.json. The certificate renews about every 60 days. If the two differ, run steps 3 and 4 again.

Check report_data

The quote’s report_data is 64 bytes: SHA-256(signing_address ‖ tls_fingerprint) followed by your nonce. signing_address is the notary’s log key followed by its cosigner key.

SIGNING_ADDRESS=$(jq -r .signing_address att.json)
EXPECTED="$(printf %s "$SIGNING_ADDRESS$TLS_FP" | xxd -r -p | openssl dgst -sha256 -r | cut -d' ' -f1)$NONCE"
[ "$EXPECTED" = "$(jq -r .report_data att.json)" ] && echo "report_data OK"

Then check that signing_address is exactly the two published notary keys. A key reads <name>+<key hash>+<base64>; the base64 decodes to one type byte and the 32-byte public key:

key() { jq -r ".$1" att.json | cut -d+ -f3- | base64 -d | tail -c 32 | xxd -p -c 64; }
[ "$(key log_key)$(key notary_key)" = "$SIGNING_ADDRESS" ] && echo "notary keys OK"

This is the same layout NEAR AI Cloud’s verifier checks.

Verify the quote with dstack-verifier

Run Phala’s verifier, pinned by digest, and send it the quote. It checks Intel’s signature chain and replays the event log.

docker run -d --rm --name dstack-verifier -p 127.0.0.1:8090:8080 \
  dstacktee/dstack-verifier@sha256:0ed61d60f6e0d44cf466e15dc6894f37152d8567cfa76bd8785a921b2d906c38

jq '{attestation}' att.json \
  | curl -s -X POST http://127.0.0.1:8090/verify -H 'content-type: application/json' -d @- \
  -o verdict.json
jq '{is_valid, reason, details: (.details | {report_data, os_image_is_dev, tcb_status, advisory_ids, app_info})}' verdict.json

A pass needs all of these:

Field	Must be
`is_valid`	`true`
`details.report_data`	The same as `report_data` in `att.json`
`details.os_image_is_dev`	`false`
`details.tcb_status`	`UpToDate`
`details.advisory_ids`	`[]`
`details.app_info.app_id`	The `app_id` you noted, and the same next time you check

Tie the compose to the quote

The quote attests a compose hash. /tee/info publishes the compose itself. They must match:

[ "$(jq -r .details.app_info.compose_hash verdict.json)" = "$(jq -r .compose_hash info.json)" ] \
  && [ "$(jq -j .app_compose info.json | openssl dgst -sha256 -r | cut -d' ' -f1)" = "$(jq -r .compose_hash info.json)" ] \
  && echo "compose OK"

Now app_compose is exactly what the VM runs. Read it to see every image digest, every measured setting and the names of the sealed secrets:

jq -r .app_compose info.json | jq -r .docker_compose_file | grep 'image:'

With every check passing, a connection to the API host ends inside a genuine Intel TDX VM with a production OS image and an up-to-date TCB, running exactly the published compose, and the notary keys that sign the transparency log belong to that VM.

Steps 3 and 4 read the certificate over two separate TLS connections to the same host. That’s enough here, because the quote binds the key itself, and both connections must present it.

Agent API

Quickstart

Guides

Trust & Verification

API Reference

What it guarantees

What the TEE gives you

What it doesn't cover

What runs inside

Geofence

Endpoints

Verify it yourself

Next steps

Transparency Proofs

How it works

​What it guarantees

What the TEE gives you

What it doesn't cover

​What runs inside

​Geofence

​Endpoints

​Verify it yourself

​Next steps

Transparency Proofs

How it works

What it guarantees

What runs inside

Geofence

Endpoints

Verify it yourself

Next steps