An app's server-side component runs as a subset-checked capability delegate — it holds a delegated UCAN, never the user's key, and can be attested — so a backend can act on a user's data without custody of their authority.

TEE Backends

A TEE backend is an app's server-side component that acts on a user's data as a subset-checked delegate, not a key-holder: at sign-in the user delegates a least-authority capability set to the backend's DID, materialized as a PortableDelegation (a UCAN) — so the backend can read/write exactly what it was granted and nothing more, and it never possesses the user's owner key.

Role

This is what lets an app have a real server (ingesting data, running agents) inside the capability model without becoming a trusted custodian. Running that backend in a TEE means even the operator can't exceed the delegated authority — the backend is a verifiable, attestable subset-delegate.

Mechanics

The app + backend manifests are composed into one capability request at sign-in (single wallet prompt); the backend's grant is materialized as a PortableDelegation with no second prompt (packages/node-sdk/src/delegation.ts), and brokered by OpenKey's /delegate endpoint (apps/api/src/routes/delegate.ts). The backend then signs invocations with its own session key; the node admits them only within the delegated subset (cacao-chain-validation). It can decrypt only what it holds a decrypt capability for.

Relationships

A subset delegate of the user's capabilities; provisioned via capability-composition + delegation-api; brokered by OpenKey; runs in a TEE; the canonical example is Listen's backend.

Status & drift

Shipped. The backend is never a key-holder — this is the core security property of the manifest app model.

Sources

js-sdk: packages/node-sdk/src/delegation.ts (PortableDelegation materialization)
openkey: apps/api/src/routes/delegate.ts (delegation broker — OpenKey repo, not in this checkout)