TEE scope statement — Anthosting
Status: DRAFT. Not reviewed by a lawyer. Not published. The technical claims here are the verifiable ones from
../security-model.mdand fromevidence/; the framing follows the standard confidential-computing convention of stating a threat model before claiming anything. SeeREADME.md.
This document says what the confidential virtual machine protects and what it does not. It is part of the Terms of Service. It is deliberately unsatisfying in the second half, because the honest limits of a TEE are the part that matters and the part marketing usually omits.
1. The threat model, stated first
A guarantee is meaningless without saying who it is against. Ours is:
In scope. The host operator and a compromised host OS or hypervisor, including whoever holds the Phala account and API key. They control the machine, its firmware, its network, and when it starts and stops. They cannot read the buyer key or the prompt contents in memory, and they cannot serve unapproved code as if it were approved.
Out of scope. Anything running inside the enclave that is the approved code; the Antseed network; the model sellers; Phala's key-management service; Intel; the public chain; and the operator of this service. Each is named in §5 with what it means concretely.
Confidential computing moves the trust boundary rather than eliminating it: what we no longer trust is the host, and what we now trust instead is the hardware vendor and the measured code. That trade is the point, and it is also a cost.
2. What the enclave protects
| protected | how | what backs the claim |
|---|---|---|
| the buyer key | derived per boot from the hardware via the platform's key service, injected into the buyer daemon in memory, never written to disk | infra/phala/tenant/agent.mjs:119; the image's root filesystem is read-only with only a tmpfs, so there is nowhere to write it |
| your prompts and model traffic | exist in enclave memory, are proxied straight to the seller, and are destroyed on restart | agent.mjs:207; docker-compose.ingress.yml:79 |
| the TLS private key for your tenant's hostname | generated and used only inside the VM; validated over the TLS handshake (tls-alpn-01), so no DNS credential ever enters the VM | docker-compose.ingress.yml:33 |
| what code is running | a hardware-signed quote commits to the measurement of the OS image and the compose, and the verifier replays the event log and checks both | evidence/B/B4/, evidence/B/B5/, evidence/F/F1/ |
| who is running it | the quote binds the tenant id, the buyer address, and a fresh nonce; the domain-binding quote binds the hostname | evidence/B/B5/ |
| resistance to a tamper | changing one environment variable in the compose changes the app identity, the measurement, and therefore the derived key — so a tampered deploy cannot spend from the approved buyer's balance | evidence/B/B4/ |
3. What it does not protect — every item, with its consequence
| not protected | what that means for you |
|---|---|
| network egress | there is no egress allowlist. A running tenant can reach anything it can route to. The platform exposes no compose-level control we could find, so this is not configurable by us. What is true: the boot, identity and operator paths need no network at all (proved by running the image with networking disabled), no DNS credential is in the VM, and there is no key material on disk to exfiltrate. The exposure is a compromised process inside the approved code reaching the network — not a stolen key |
| availability | no uptime commitment, no SLA. The machine can stop, be re-created, or die with its node. A suspended machine still bills for disk; only deletion stops that |
| the key-management service | the buyer key is derived through Phala's KMS. The hardware prevents the hypervisor from reading it; the KMS provider can derive it. Custody is unaffected — a KMS that leaked the key would hold a spending key, and still not a withdrawal right |
| side channels | memory encryption does not defend against traffic analysis, speculative execution, or anything else in that family. We do not claim to mitigate them and do not know the platform's posture |
| rollback and replay of state | a restored snapshot is not attested as the state you had before. In practice the key is re-derived from app_id, so it survives a restart — and a balance's ownership still lives in the operator wallet, not the machine |
| the seller | your prompt goes to a third party chosen by the Antseed network. Their practices are outside this statement and outside our control |
| the Antseed network | seller discovery, metadata, and routing are the network's business. Your buyer's on-chain address is visible to peers |
| the chain and the contracts | public, irreversible, and not ours. Deposits and withdrawals are readable by anyone forever |
| integrity of the response | a passing verification says the right measured code ran on genuine hardware. It says nothing about whether a model's output is correct, safe, or honest |
| software defects in the approved code | a verified build is still a build with bugs. Attestation is not review |
| our control plane | the VM says nothing about the control plane, which holds two bearer tokens per tenant in plaintext. A compromise there can spend your balance up to the on-chain credit limit. See the Terms §3.2 |
4. How to check any of this yourself
The claims above are meant to be falsifiable. Three checks, none of which require trusting us:
# 1. Does the machine run the code we approved? (DCAP-verified quote, replayed event log)
node packages/verifier/scripts/verify-attestation.mjs https://<tenant>.anthosting.dev
# 2. Is the measurement the one that was approved offline?
node packages/verifier/scripts/check-measurement.mjs https://<tenant>.anthosting.dev/attest \
--compose-hash <hex> --os-image-hash <hex>
# 3. Is the approval itself signed, and by what key?
curl -s https://verify.anthosting.dev/api/measurementsAnyone can run these. The verifier is a separate service on a separate host that holds no credential — it refuses to start if it can see one — so it does not depend on us being honest about our own measurements. And the approved measurement set is signed with an Ed25519 key whose private half lives on one offline machine and appears nowhere in this repository.
For a reader who does not want to run anything: that is a fair position, and the honest summary is that you are trusting the CPU vendor, the platform, and the signer of the manifest.
5. Versioning — what this statement covers
Every one of those changes when the code changes, and after an image upgrade the approval must be re-recorded and re-signed — otherwise the verifier reports the tenant as failing the approved-image check. That is visible and deliberate, not a silent gap.
6. The honest summary
The enclave makes a specific, checkable promise: the buyer key and your prompt contents are not readable by the host operator, and the code running is the code we approved. Everything outside that sentence — availability, egress, sellers, our control plane, the chain, and software defects — is not protected by this technology, and if a property you care about is not in the sentence above, it is not something this service provides.