TEE & Attestation

The Agent API runs inside a hardware-isolated confidential VM (Intel TDX, on Google Cloud, using the open-source dstack stack). 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.
Keys and releases: the VM gets its keys from our own dstack KMS, which runs on a separate Google Cloud TDX VM. Which code may get keys is decided by contracts on Ethereum.
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.
Front-1 metadata. Traffic reaches the VM through front-1, a separate host we run. It forwards TLS ciphertext and has no certificate key, but it sees the caller’s IP address, the host name, and traffic size and timing. It keeps no access log and its journal is volatile. It can interrupt traffic or forge the address the geofence and rate limits use, but it cannot read or undetectably change the HTTP exchange. Inside the VM, the edge, TLS and ingress services see the address and remove it before the request reaches the API server, which records no caller address.
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.
Tunnel	A WireGuard tunnel the VM opens to `front-1`. The VM publishes no ports.
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.

Keys and releases

The VM does not hold its keys by itself. Our own dstack KMS, on a separate Google Cloud TDX VM, derives them and releases them only to a VM that passes its checks:

Contracts on Ethereum decide. An app contract lists the compose hashes that may obtain keys, and a KMS contract lists the OS images and KMS measurements it accepts. The KMS reads both through a light client inside its own VM, so a change counts only once it is about 13 minutes deep.
Releases wait. The contracts are owned by a DAO. A new release is allowed only through a 24-hour timelock. A revocation takes effect at once, but it stops future key release only: it does not erase keys a running VM already holds.
The compose names the KMS. The attested compose sets key_provider to kms and pins the KMS’s CA key as key_provider_id, so a VM started under any other key provider does not match.
OS image trust. On Google Cloud, dstack takes the guest OS image identity from the VM’s virtual TPM, not from the TDX registers. Which kernel booted therefore also rests on Google’s vTPM.

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 the open-source dstack verifier, pinned by digest, and send it the quote. It checks Intel’s signature chain and replays the event log. The environment variable points it at Intel’s own service for the TDX collateral.

docker run -d --rm --name dstack-verifier -p 127.0.0.1:8090:8080 \
  -e DSTACK_VERIFIER_ATTESTATION__URLS__PCCS=https://api.trustedservices.intel.com \
  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`. On Google Cloud the verifier cannot read this flag and reports `null`. Then `details.app_info.os_image_hash` must equal `os_image_hash` in `info.json`, and be an OS image the KMS contract allows.
`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:'

Check where the keys come from

The attested compose must take its keys from a KMS, with the dstack gateway off:

jq -r .app_compose info.json | jq '{key_provider, key_provider_id, gateway_enabled}'

key_provider must be kms and gateway_enabled must be false. key_provider_id is the KMS root’s public key (P-256, hex). Note it and compare it next time you check.

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 with keys from our KMS, 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

Keys and releases

Geofence

Endpoints

Verify it yourself

Next steps

Transparency Proofs

How it works