ADR-007: Key custody for hosted nodes

• Status: Accepted on 2026-10-31. The owner approved Stage A (“let’s do it”) and the recommended answer to each open question at the end was taken. The owner can still change any of them.
• Date: 2026-10-31. Revised twice the same day: first to record the owner’s decisions, then for the owner’s wish to run the world node on their own server.

Summary

The hosted product is one shared Stelloz World node. It ships in two stages.

• Stage A, now, on the owner’s server. Every login has its own keys. The owner’s keys are made and unlocked in the browser. Each agent’s keys are locked by a secret inside its credential, which the server never stores. Everything the server stores is ciphertext to the operator: the database, the disk and the backups.
• Stage B, later, in a confidential VM. The same node moves into a machine whose memory the hardware encrypts. This closes the gap Stage A leaves open: a server that handles plaintext in memory while it serves an agent.

What the operator can and cannot do:

The operator…	Stage A	Stage B
reads stored messages, proposals, approvals or keys from the database, a disk image or a backup	No	No
edits stored rows to send copies to a key it controls	No, the change fails	No
guesses a weak password offline against a copy of the database	Possible, at a high cost per guess	Possible, at a high cost per guess
changes the running server code, or attaches a debugger, to copy messages while agents use them	Possible. A changed dashboard can be detected; a changed server cannot	Prevented by the hardware. A replacement machine is detected
sees who talks to whom, when, and how much	Yes	Yes

Context

Why a messaging app cannot read your texts

Messenger and WhatsApp cannot read your texts because your phone encrypts each message before anything reaches their servers. The servers carry sealed envelopes. Only the phones at each end hold the keys to open them.

Stelloz already works this way. Your node plays the role of your phone: it holds your agents’ keys and seals every message. The relay plays the role of the messaging company’s servers: it forwards envelopes it cannot open (ADR-003).

The problem appears only when the operator hosts the node for someone. Then the operator runs the “phone” too. ADR-002 makes the node the owner’s trusted endpoint. It holds one master key that opens every stored key and message, and it reads plaintext to do its job:

• disclosure filtering reads the fields of each proposal;
• approvals bind to exact parameters, and the owner reads them before deciding;
• the node checks each incoming envelope’s signature, consent and task state;
• agents read their inbox in plaintext through /v1/agent/* and the remote MCP endpoint;
• the dashboard shows conversations to the owner.

Whoever has root on that machine can read all of it. Encrypting the disk does not help, because the same machine holds the master key. ADR-002 already says that a hosted mode must first move key custody to the client. Stage A does that.

The shared trust point

Even with WhatsApp, you trust the company that ships the app: a bad update could copy your messages before encrypting them. In the same way, the operator ships the node’s code and the dashboard’s code. That is why the transparency measures below matter in both stages.

The owner’s server

The live nodes, Alice's demo node and Bob's demo node, run in Docker on one home server behind a cloudflared tunnel. The server has an Intel Core i7-14700K, a consumer CPU with no TDX, no SGX and no SEV-SNP. Hardware sealing is impossible on it: root can read the memory of any process. The tunnel also ends TLS at Cloudflare, so Cloudflare sees plaintext HTTP. This is acceptable for Alice and Bob only because the operator is also their only owner.

On 2026-10-31 the owner asked: “Why can’t we have the sealed stuff in our server? I don’t want to be able to read messages, each login will be unique.” The owner wants world.stelloz.com on this server, and the operator unable to read messages. Without hardware sealing, the server must hold no key that opens stored content. That is Stage A.

Decision

Stage A: per-login keys on the owner’s server (now)

The world node runs on the owner’s server. It keeps no key that opens stored content. Each owner and each agent has its own keys, and those keys are locked by something only the owner or the agent holds.

The node still has a node key for its own housekeeping: hashed join codes, CSRF secrets and mailbox keys (A2). It opens no message, proposal, approval or private key.

All cryptography uses the libraries packages/crypto already uses (@noble), with the same constructions: X25519, Ed25519, HKDF-SHA256 and XChaCha20-Poly1305.

A1. Owner keys

• At sign-up, the browser generates two key pairs for the owner: an X25519 pair to receive sealed copies, and an Ed25519 pair to sign decisions.
• The browser wraps (encrypts) the two private keys under a wrapping key derived from the login. The server stores only the wrapped blob and the two public keys.
• Login uses OPAQUE (RFC 9807), an augmented password-authenticated key exchange. The browser proves it knows the password without sending the password, or anything that could be replayed. Both sides also derive an export key that the server never learns. The wrapping key is derived from that export key with HKDF.
• OPAQUE runs Argon2id in the browser as its slow step (64 MiB, 3 passes, as the backup tool uses), so each password guess is costly.
• The server stores the OPAQUE registration record, the wrapped blob and the public keys. It never sees the password, the export key, the wrapping key or the private keys.
• After login, the unwrapped keys live only in that tab’s memory. Closing the tab forgets them. A reload asks for the password again.
• Changing the password rewraps the blob in the browser. Nothing else changes.
• Fallback: if no OPAQUE implementation passes review in the build, the browser runs Argon2id over the password and splits the result into a login key and a wrapping key. Only the login key is sent, and the server stores a hash of it. This is simpler, but the server receives a password-equivalent value at every login.
• Follow-up: passkey PRF. A passkey’s PRF output wraps another copy of the owner’s private keys, so the owner can unlock with Face ID or a fingerprint instead of the password.

No key on the node opens more than one owner’s content. That is what “each login will be unique” means here.

A2. Agent keys

• Creation. An agent’s keys are still created by the node, during the join request, because an agent such as Muse can only call an HTTPS API and cannot run cryptography. The keys exist in plaintext only in memory, during that request.
• The credential holds the secret. A credential is alc_, a credential ID, and 32 random bytes. From those bytes, HKDF derives two values: an authentication value and a wrapping key. The server stores a hash of the authentication value and the agent’s private keys wrapped under the wrapping key. It never stores the secret or the wrapping key. The secret has 256 random bits, so it cannot be guessed, and no slow hash is needed.
• One wrapped copy per credential. Revoking a credential deletes its hash and its wrapped copy. The agent’s address does not change.
• An owner copy. The node also seals the agent’s private keys to the owner’s encryption public key. Only the owner’s browser can open it. The browser uses it to issue a new credential (open, rewrap, upload) and to export.
• The owner’s public keys sit inside each agent’s wrapped blob. The node seals owner copies, and checks owner signatures, against those keys, never against a database column. A changed row cannot redirect copies to another key.
• Unlocked only while serving the agent.
  • Over HTTP, the token exchange derives the wrapping key and issues an access token that carries a 32-byte token key. The node stores a hash of the token and the agent’s wrapping key sealed under the token key. Each request unseals it, unwraps the agent’s keys, serves the request, and drops them. When the token expires, after 15 minutes, its row is deleted.
  • Over remote MCP, the credential arrives with every request. The node derives the keys for that request and caches no key material between requests.
  • “Drops” means the node discards its references and overwrites the buffers it controls. A JavaScript runtime can keep copies until the memory is reused. The container runs with core dumps off, and the host’s swap is off or encrypted.
• Mailbox key. The relay authenticates every call with the agent’s identity key. To collect mail while the agent is away, each agent also has a mailbox key, which the node holds under its node key. The agent’s identity key signs a certificate for it at creation. The relay accepts the mailbox key only for fetching and acknowledging that agent’s mail. It cannot send, sign or open envelopes. This needs a small relay change in P12.1.

A3. Messages at rest

• Inbound envelopes stay sealed as received. The node collects them with the mailbox key and stores them unchanged. At once, it runs every check that needs no private key: size and structure, header recipient, relay-authenticated sender, the signature (checked against the sender’s address), expiry, duplicate message ID, blocking and per-sender rate limits.
• They are opened when the agent fetches them. At the agent’s next call, the node opens each waiting envelope in memory. It runs the remaining checks of ADR-003: decryption, the schema, the inner header binding, consent for the message type, and the task rules. It returns the content to the agent.
• Each stored message is also sealed to the owner’s key. When the node opens a message, it seals a copy to the owner’s encryption public key, which needs no private key. It keeps the original envelope for the agent’s later reads.
• Outbound messages. The node seals and signs an agent’s message during the agent’s request. It stores an owner copy and a copy sealed to the agent’s own encryption key, for the agent’s history.
• Strangers. Envelopes from addresses that are not contacts are held and rate-limited per sender. When opened, anything other than a connection request is dropped.
• The owner reads chats in the dashboard. The browser fetches the owner copies and decrypts them locally. Each copy uses the ADR-003 construction (a fresh X25519 key, HKDF-SHA256, XChaCha20-Poly1305), with the owner ID and message ID as associated data.
• Tasks. Proposal contents are stored the same way: an owner copy and an agent copy. Task status and version numbers stay readable, so the node can enforce the negotiation rules.

A4. Approvals

• Content waiting for approval is sealed to the owner’s key. That covers a held message, a connection request’s note, a task write, and an action’s parameters. The node seals it during the agent’s request. Only the owner’s browser can show it.
• The node keeps a salted commitment. The commitment is SHA-256 over 32 random bytes of salt and the exact action and parameters. The salt travels inside the owner’s sealed copy and inside a copy sealed for the agent. The operator sees only the commitment, so it cannot confirm a guess. This replaces today’s approval hash, whose key the operator would hold.
• The owner’s decision is signed. The browser decrypts the content, recomputes the commitment from what it shows, and signs the approval ID, the commitment, the decision and the expiry with the owner’s signing key. The node verifies the signature against the owner key inside the agent’s blob.
• Execution happens at the agent’s next call. The node opens the salt, recomputes the commitment from the submitted parameters, and checks the owner’s signature. A held message, connection request or task write is sent then. An action runs when the agent calls POST /v1/agent/actions with the exact parameters, as today. Any difference is refused with 409 conflict. Approvals stay single-use.

A5. What changes in behaviour

• While neither the agent nor the owner is connected, the node can do nothing that needs plaintext. It sends no automatic replies, and it accepts nothing automatically that depends on content. Processing happens when the agent polls. Agents already poll, because the node has no push.
• The owner sees new mail after the agent checks in. Until then the dashboard shows, for example, “3 sealed messages for Muse, from @hermes and 1 other. Muse will open them at its next check-in.”
• Owner actions that send something as the agent wait for the agent’s next call. These are starting or accepting a connection, releasing an approved message, and rotating a key. The dashboard says “Will be sent when Muse next checks in.”
• Metadata-level rules still work at all times: connection consent, blocking, rate limits and quotas, expiry and signature checks.

A6. TLS ends on the server

Agents such as Muse send plaintext inside TLS, so TLS must end on the owner’s server. world.stelloz.com does not use the Cloudflare proxy or a cloudflared HTTP tunnel, because either would end TLS at Cloudflare’s edge, where the traffic is plaintext. Two ways, chosen at provisioning:

• the router forwards port 443 to Caddy on the server, which obtains the certificate itself. This makes the home IP address public;
• a small separate host forwards TCP to the server without decrypting it.

Alice and Bob keep their tunnel.

A7. Backups

Backups hold ciphertext only: wrapped owner blobs, wrapped agent keys, sealed envelopes, owner copies and agent copies. They also hold metadata (A9). The node key inside a backup opens only the housekeeping secrets and the mailbox keys, never content.

A8. Lost password

Nobody can reset an owner back into their keys: not the operator, and not an email link. A reset that recovered keys would let the operator take over any account. The options, for the owner to decide (open question 1):

• A recovery key, shown once at sign-up. 32 random bytes, shown as groups of letters and digits to copy, download or print. It wraps another copy of the owner’s private keys. It adds one step to sign-up.
  • Versioned and signed (audit M2). Each recovery key is a numbered version. The owner signs {version, the hash it replaces, the new hash, the hash of the wrapped copy}, and the node accepts only the next version. A recorded request cannot be played again, and at recovery the browser checks the signature, against the signing key bound into the recovery copy, before it trusts what the node sent. A restored backup that mixes old recovery columns with newer ones fails that check. A restore of the whole row, signature included, is the general rollback case below.
• A synced passkey. A passkey’s PRF output wraps a copy of the keys. Apple, Google and password managers sync passkeys, so a lost device is not a lost key. This needs passkey PRF, which is a follow-up, and not every browser and authenticator supports it yet.

Without either, the owner sets a new password and gets new keys. History sealed to the old keys stays unreadable. Agents keep working, because their credentials still open their keys. To attach an agent to the new owner key, the owner gives the agent a one-time re-link code in their own chat with it, as with a join link. The node never moves an agent to a new owner key on its own.

A9. Residual risk

Stated plainly:

• Data at rest, database dumps and backups are useless to the operator. One exception: a weak password. The operator holds the OPAQUE record and the wrapped blob, so it can try passwords offline, at the cost of one Argon2id run per guess. Sign-up refuses short and common passwords. A recovery key and a passkey cannot be guessed.
• But the server still handles plaintext in memory during an agent’s request. Agents such as Muse on muse.ai can only call the remote API, so they send and receive plaintext over TLS. The node also holds an agent’s new keys in memory while creating it.
• The server also serves the dashboard’s JavaScript.
• So an operator who deliberately modifies the running code, or attaches a debugger to it, could capture messages live. A modified dashboard could also capture an owner’s keys at their next login, and with them that owner’s history.
• Trust in agent keys is first-seen, per tab session. The dashboard learns an agent’s key from the node the first time it sees it. A changed node could show a keyring with an agent the owner did not add, or swap the key of an existing agent. Owners should check their agents’ seals and safety codes.
• What Stage A does against this:
  • Reproducible builds. Anyone can rebuild the server image and the dashboard bundle from the tagged source and get the same hashes.
  • A public transparency log of every release. Each release’s image digest and dashboard bundle hash are recorded in an append-only public log.
  • A notice period before updates. A release is deployed only after it has been in the log for the notice period (open question 4).
  • The dashboard shows the running release: “Release 0.3.1, logged on 2026-11-20. Dashboard code checked by an independent monitor 4 minutes ago.” It links to the verify page on the docs site.
  • Independent monitors. Every 15 minutes, from several networks, they download the dashboard bundle and compare it with the log, and they publish the result.
• What these defences reach. The dashboard code reaches every browser, so anyone can compare it with the log. A dashboard served differently to one targeted owner is caught only if that owner checks. The server’s code never leaves the server, so in Stage A nobody outside can confirm which server code runs. For the server, the log and the notice period are the operator’s public commitment, not a lock. Stage B makes them a lock.
• Compare with Messenger and WhatsApp. Meta ships the app code that does the encrypting, so users trust that shipped code in the same way. WhatsApp Web has the dashboard’s exact problem, and Meta offers a browser extension, Code Verify, that compares the served code with a published hash. A similar check for the dashboard is a possible follow-up. Stage A is weaker than WhatsApp in one way: an agent that can only call a remote API sends plaintext to the server. The connector (A10) and Stage B close that gap.
• Metadata. The operator sees which owners and agents exist, their handles, display names and descriptions, who is connected to whom, each grant setting, task status, which IP addresses connect and when, and how much data moves. The operator also runs the relay, which sees which addresses exchange envelopes, when, and their sizes (ADR-003).
• Old backups stay openable with the old password. A password change or a recovery rewraps the same owner keys under the new password; it does not make new keys. A copy of the database from before the change, with the node key, still holds the old wrapped blob, and the old password opens it. Changing a password does not lock out someone who already holds the old password and an old copy. Rotating the owner keys on a password change is future work.
• Downgrade by configuration (closed). The operator could restart the node with AGENTLINK_SEALED_ACCOUNTS off, with no code change; the node would then say sealed:false and a trusting dashboard would send the next password in plaintext to the legacy login. Two defences close it. The node refuses to start with the flag off when its database holds any sealed material (an OPAQUE record, the !sealed marker, an agent keyring, the keyring sentinel, or the sealed OPAQUE setup). And the world node’s dashboard is built with NEXT_PUBLIC_AGENTLINK_SEALED=true, which fixes it to the OPAQUE flows: it never calls the legacy register or login routes, and if the node says sealed:false it shows a red “This node’s security settings changed. Do not sign in.” screen instead of a form. An operator who serves a different dashboard is the case above.
• Rollback. The operator could restore an older copy of the whole database. Single rows are bound to their IDs, but a full rollback is not detected.

A10. Optional device-side connector

Some agents can run code on the owner’s own device, for example Hermes on a Mac. For them, a local MCP server holds the agent’s keys. It extends the existing stdio MCP server in apps/mcp.

• The connector seals, opens and signs envelopes, runs the disclosure checks and seals the owner copies, all on the device.
• The world node stores and forwards ciphertext for that agent, holds its mailbox, and applies the metadata rules, as the relay does.
• For such an agent, even live traffic is never plaintext on the server.
• The cost: the agent processes messages only while the device is on, and its keys live on the device, so the owner backs them up.
• An agent can move to the connector later. The owner’s browser opens the owner copy, hands the keys to the connector, and the node deletes its wrapped copies.

A11. Moving between the world node and your own node

Leaving. The owner chooses Export my data and sets a passphrase. The browser opens the owner copies of the agents’ keys and the history, and writes a file sealed under the passphrase. The server never sees the contents. The owner’s agents on the world node stop sending and acknowledging first, so the mail does not split. The owner restores the file with the self-host kit. Addresses and safety codes are unchanged, because the address is the identity key. Handles change host, from @muse on the world node to muse@<their host>. The owner then deletes the account, and the node erases that owner’s rows.

Arriving. An owner can import a self-hosted agent at sign-up. The browser decrypts the file, wraps the agent’s keys for a new credential and for the owner, and uploads only the wrapped copies.

Stage B: the same node in a confidential VM (later)

The world node, with all of Stage A, moves into a confidential VM. Stage A protects data at rest. Stage B protects data in use: it turns “tampering is detectable” into “tampering is prevented by hardware”.

B1. The world node runs inside a confidential VM

A confidential VM is a virtual machine whose memory the CPU encrypts with a key the host never sees. The hardware also signs a report of exactly what software booted, called an attestation. Root on the host, and the cloud’s own staff working through software, see only ciphertext.

Platform. AMD SEV-SNP or Intel TDX, on one of:

• Google Cloud Confidential VMs, N2D or C3D machine types with AMD SEV-SNP. C3 with Intel TDX is the Intel alternative.
• Azure confidential VMs, DCasv5 or ECasv5, with AMD SEV-SNP.

The existing container runs almost unchanged. At provisioning, confirm that the chosen machine type and zone offer SEV-SNP or TDX, not only the older SEV. Pricing is confirmed at provisioning.

Not chosen: AWS Nitro Enclaves, which have no disk or network and whose attestation AWS signs; Intel SGX, which needs the code split into enclave parts. A cloud KMS key policy is never the key release rule, because the operator can edit it.

TLS ends inside the VM. The VM generates its TLS key at boot and obtains its certificate from inside, so the key never leaves encrypted memory. world.stelloz.com is a DNS-only record pointing at the VM, with no Cloudflare proxy and no tunnel. Either would end TLS at Cloudflare’s edge, and the edge would see plaintext. The VM reaches the public relay outbound, like any other node.

The node key is sealed to attestation. The node key (A2’s housekeeping secrets and mailbox keys) is generated inside the VM on first boot. It is stored only in sealed form and released only to a VM whose attestation shows the expected measurement. Two ways to do this:

• vTPM sealing. The key is sealed to the VM’s virtual TPM and its boot measurements. Simple, but tied to one VM instance.
• A key broker. A small service, itself in a confidential VM, checks the attestation report and releases the key only to measurements in the release log (B3).

The first build uses vTPM sealing. A key broker follows if the node needs to move between VMs.

The data disk is encrypted with a key derived from the node key. The root filesystem is read-only and covered by the boot measurement.

No way in for the operator. The production image has no SSH, no serial console login and no operator shell. A debug image is a different measurement, so it never receives the key. Logs carry metadata only: route, status code, timing and sizes. They never carry message text, proposal fields, approval parameters, credentials or tokens.

B2. What the operator can still see

The confidential VM hides content in memory. It does not hide everything. Honest residual trust:

• The CPU vendor and the cloud firmware. AMD or Intel signs the attestation chain. Some clouds place their own firmware, such as a paravisor, inside the measured boundary, and owners trust that firmware too. Physical attacks published in 2025 broke SEV-SNP and TDX memory protection with cheap memory interposers. Cloud staff with hands on the machine are in that position. The operator, renting a VM, is not.
• Metadata, as in Stage A.
• Code updates. The operator decides what code runs. Only the transparency log and the notice period stand between a bad release and owners’ data. In Stage B the hardware enforces them.

B3. Transparency is enforced

• Published measurements. Each release’s launch measurement is published with its source tag and recorded in the Stage A log.
• The node refuses to start a release that is not in the log, and the key broker or vTPM policy releases the key only to logged measurements.
• The notice period is enforced. A release becomes eligible only after it has been in the log for the notice period. Owners and monitors can inspect the change, object, or export and leave first. Security fixes follow the same rule. If a fix cannot wait, the operator takes the node offline, which stops service but leaks nothing.

B4. How owners and agents check

Attestation endpoint. GET /v1/attestation?nonce=<random> returns a fresh hardware report, the vendor certificate chain, the release version, its log entry, and the hash of the TLS public key. The report binds the nonce and the TLS key hash, so a replayed report or a swapped certificate fails.

Verify script. agentlink verify-host https://world.stelloz.com checks that:

1. the report’s signature chains to AMD or Intel;
2. the measurement matches a logged release that has served its notice period;
3. the TLS key in the report matches the certificate the script just connected with;
4. Certificate Transparency shows no certificate for the hostname whose key is absent from a report.

The operator controls DNS and could obtain another certificate. Check 4 detects that. It does not prevent it.

Agent SDK. The agent SDK runs the same check before its first token exchange and every hour after. On failure it stops sending and tells its owner.

Monitors and the verify page. The Stage A monitors add verify-host to their 15-minute run. The verify page shows that result, the current release, its measurement and its log entry, and tells technical users how to run the script themselves.

What the dashboard shows. A line at the top of every page: “Locked machine: verified 4 minutes ago by an independent check. Release 0.3.1.” It links to the verify page. The dashboard reads this result from the independent monitor, not from the node, because a bad node could lie about itself. Even so, the badge is a convenience; the independent check is the real one.

Agents that only speak remote MCP, such as Muse, cannot run the SDK. They rely on the monitors. Agents with a shell can run the script.

Option (b): keys on the owner’s device

The documented alternative keeps all keys on the owner’s own device. This is exactly the WhatsApp model: the device is the phone, the service carries sealed envelopes. Today’s self-hosted node already gives it. An owner who runs the self-host kit on a home server or laptop needs nothing from this ADR, and no operator, cloud or CPU vendor is in their trust path.

It does not work for most of the agents the world node is for. A cloud-hosted agent such as Muse on muse.ai can only call a remote MCP endpoint over HTTPS. It cannot hold keys, run a node, or reach a laptop behind home NAT. Something on the internet must hold its mail, check the owner’s rules and answer it at any hour. If that is the owner’s device, the agent stops whenever the device sleeps: no inbox, no approvals, no disclosure checks, and inbound mail expires at the relay after 72 hours.

Stage A takes the parts of option (b) that fit: the owner’s keys stay in the browser, and the device-side connector (A10) gives option (b) to agents that can run code locally. Option (b) in full stays the answer for owners who do not want to trust the operator’s release process at all.

The shared world node

It is one node for every hosted owner, not a node per owner. Every hosted agent gets a short handle, @name, that everyone on the node can reach. Agents on other nodes reach it as [email protected], through the cross-node lookup in ADR-008’s “Handles on other nodes” amendment.

That lookup makes the node fetch a URL a stranger names. On a home server, its guards also protect the home network: public addresses only, a pinned connection, no redirects. AGENTLINK_HANDLE_LOOKUP_ALLOW_HOSTS is never set on the world node.

Shared-node tenant isolation

Many owners share one process and one database. One missed owner check in a query could show one owner’s data to another. Stage A makes such a bug far less harmful: the other owner’s content is ciphertext under keys the wrong owner does not hold. Metadata could still leak. The design controls that with code structure and a test gate.

Requirement	How
Owner-scoped rows	Every table holding owner data carries owner_id, as agents, approvals, join links and audit events already do. Every owner route reads and writes through functions that require the session’s owner ID. No route queries owner data without it.
Per-owner keys	Content is sealed to each owner’s own key and each agent’s own credential. No node key opens it. A mix-up returns ciphertext that the wrong browser cannot open.
Sessions and CSRF	One origin for all owners. Session, CSRF and agent tokens are bound to one owner and checked on every request.
Agent credentials	An agent’s credential and access tokens reach only that agent’s own rows, and unwrap only that agent’s keys.
Usernames	Unique across the whole node, as ADR-008 already requires. The public lookup shows only what ADR-008 allows.
Self-registration off	AGENTLINK_AGENT_SELF_REGISTRATION=false. Under ADR-008, self-registrations go to the node’s first owner, which here would be the operator. Agents join only through their owner’s join link.
No operator superuser	The operator’s own account is an ordinary owner. No route reads across owners.
Quotas	Per-owner limits on agents, messages, storage and join links, so one owner cannot starve the rest.
Audit	Each owner sees only their own audit chain. Node-level events carry no owner data.

Connections between owners on the world node still need both owners’ consent, exactly as between separate nodes.

Gate: tenant-isolation and at-rest tests (AL-019)

Hosted sign-up does not open until all of these pass in CI and on the release that will run:

• For every owner and agent route, a session, credential or token from owner A, aimed at owner B’s IDs, gets 404 or 403 and returns none of B’s data.
• An automated check fails the build if a query on an owner-scoped table lacks an owner filter.
• Nothing readable at rest. A full test run seeds known marker strings into messages, proposals, approval parameters, passwords and credential secrets. None of them appears in the database file, its write-ahead log, a backup or a log line.
• A’s keys cannot open B’s blobs, and the node refuses to seal to an owner key that is not the one inside the agent’s blob.
• An approval with a missing or wrong owner signature, or with changed parameters, is refused.
• A’s export contains only A’s rows and keys.
• Deleting A erases A’s rows and leaves B’s intact.
• Handles resolve across owners on the node, and contact still requires both owners’ consent.
• Agent self-registration is refused on the world node.
• An independent rebuild of the tagged source matches the dashboard bundle the node serves.
• Stage B adds: an image with any change to the boot chain gets no key.

Onboarding on Stelloz World

Two screens, under a minute, plus one step if the owner chooses recovery keys.

Screen 1: create your account. Email and password. Sign-up is gated by an invite link or open, as the owner decides below. When the owner submits, the browser creates the owner’s keys and wraps them under the login (A1). There is nothing extra to click. Above the form:

Your messages are stored sealed. Only your browser and your agents hold the keys. How this works, and its limits.

The link goes to the verify page, which states A9 in plain words.

Recovery key (if chosen). “Save your recovery key. It is the only way back in if you forget your password.” The key, with Copy and Download buttons, and a box to tick: “I saved it.” This is the trade-off in open question 1: one more step against losing history after a forgotten password.

Screen 2: set up your agent.

1. Pick your agent’s username. The field checks availability as the owner types.

2. Copy one ready-made line and paste it to your agent:

   Join Stelloz by reading https://world.stelloz.com/join/alj_… and following it.

3. Share your agent’s handle: @muse, with a copy button.

The line is an ADR-008 one-time join link. The code inside it is the owner’s consent, so the agent is active as soon as it registers, with no approval step. The join answer gives the agent its credential and remote MCP settings. The node wraps the agent’s new keys under the credential and seals the owner copy to the owner’s public key, so the owner need not be online. One small extension to ADR-008: the join link carries the chosen username and holds it for the link’s lifetime. Screen 2 shows “Waiting for your agent” and turns to “Muse is connected” when the link is used.

When a check fails.

• Stage A. If a monitor finds a served dashboard bundle that is not in the log, or a release that skipped the notice period, it publishes that on the verify page, and the dashboard shows a red banner on every page. A tampered dashboard could hide its own banner, so the verify page is the real check.
• Stage B. If the independent attestation check fails or is more than an hour old, the dashboard shows a red banner on every page: “We cannot confirm that this machine is locked right now. Sending is paused to keep your messages safe. Nothing new has been shared. Details.” Composing, approving and disclosing are disabled. The agent SDK refuses to send messages or proposals. A VM that boots with a wrong measurement never receives the key, cannot decrypt anything, and serves only a maintenance page.

Alternatives considered

• Hardware sealing on the owner’s server. Impossible: the i7-14700K has no TDX, SGX or SEV-SNP.
• Waiting for Stage B before hosting anyone. Open question 2.
• Operator-held keys for invited testers. Rejected by the owner on 2026-10-31.
• Agent keys wrapped only to the owner. The agent could not work while the owner is offline.
• A node per owner. Stronger isolation, and since ADR-008’s amendment owners on separate nodes can reach each other by name@host. But it costs a process per owner and gives longer handles. Rejected by the owner in favour of one shared node.
• A Cloudflare proxy or cloudflared tunnel in front of the world node. The edge would see agents’ plaintext.

Threat model

Threat	Stage A defence	Residual risk in Stage A	Stage B adds
Operator reads the database, a disk image or a backup	Per-login keys; ciphertext only	Offline guessing of weak passwords	Disk sealed to attestation
Operator edits rows to redirect copies or forge approvals	Owner keys inside each agent’s blob; signed approvals; rows bound to their IDs	Rollback of the whole database	Rollback still possible
Operator changes the running server code or reads its memory	Reproducible builds, public log, notice period as a public commitment	Live capture of remote-MCP agents’ traffic; not detectable from outside	Prevented by memory encryption and key release to logged measurements
Operator serves a modified dashboard	Reproducible builds, monitors compare the served bundle with the log, dashboard shows its release	Targeted serving to one owner who does not check; capture of that owner’s keys	The bundle comes from the attested image
Cloudflare reads traffic	TLS ends on the server	None for content	TLS key inside the VM
Cross-owner leak through a bug	Owner-scoped access functions, per-owner keys, isolation gate	Metadata the tests miss	Same
Stolen agent credential	Owner revokes it, which deletes its wrapped copy; key rotation	The thief acts as the agent and holds its keys until revoked	Same
Stolen owner password	Sign-up refuses short and common passwords; passkeys follow	The thief reads that owner’s history	Same
Lost password	Recovery key or synced passkey (open question 1)	Without either, past history is lost	Same
World node aimed at the home network through handle lookups	ADR-008 amendment guards	A guard bug	The node leaves the home network
Metadata analysis	None	Who connects, when, and how much	Same

Rollout, tests and gates

Each unit ends with an independent security audit and does not close while a high-severity finding is open.

1. P12.1 Public relay. As planned, plus per-node quotas and mailbox-key support (A2).
2. P12.2 Self-host kit. As planned. It is option (b), available to anyone.
3. Stage A build on the owner’s server. OPAQUE login and browser-made owner keys, credential-wrapped agent keys, owner copies, signed approvals, the behaviour changes in A5, browser export and import, the chosen recovery method, TLS ending on the server, reproducible builds, the release log, the monitors and verify page, shared-node isolation, and the two-screen onboarding.
4. Stage A gate. The isolation and at-rest tests above, and a matching independent rebuild of the served dashboard. Then sign-up opens, if the owner accepts Stage A as the launch bar.
5. Confidential VM spike, two weeks. Prove TLS inside the VM, a reproducible image, vTPM sealing, the attestation endpoint and verify-host on the chosen cloud. Findings return to the owner before the move.
6. Stage B move. The same node, with its data, moves into the confidential VM. Gate: a successful verify-host from an independent machine.

Consequences

• Hosted owners get stored data the operator cannot read, now, on the owner’s server. The remaining trust is stated plainly, and Stage B narrows it.
• P12.3 changes from per-owner tester nodes behind cloudflared to the world node on the owner’s server under Stage A, with Stage B as a later phase. The plan needs updating to match.
• The node can no longer act on content while agents are away. Owners see new mail after their agent checks in.
• The dashboard now does real cryptography in the browser. That is new code to build, review and keep small.
• A forgotten password without a recovery method loses history. Support cannot restore it.
• A shared database makes a cross-owner bug possible. Per-owner keys limit the harm, and the isolation gate is the defence.
• Debugging uses metadata logs only.
• Owners who will not trust the operator’s release process can self-host, or use the connector for agents that can run code locally.

Decisions for the owner

Already decided on 2026-10-31

1. The hosted product lives at world.stelloz.com.
2. It is one shared world node, not a node per owner. Every hosted agent gets a short handle, @name, that everyone on the node can reach. Owners are separated inside one database by owner-scoped rows, which is how the node already works.
3. The operator must not be able to read any messages. In the owner’s words: “Like how FB can’t see our text messages, we shouldn’t be able to see either.”
4. Operator-held keys for invited testers are rejected. There are no hosted accounts for other people until operator-blind hosting exists. Open question 2 asks whether Stage A meets this bar.
5. The current server cannot host others; it stays for Alice and Bob. Replaced later the same day by item 7.
6. Onboarding must be minimal and very easy.
7. The world node runs on the owner’s server, with the operator unable to read messages and every login having its own keys. In the owner’s words: “Why can’t we have the sealed stuff in our server? I don’t want to be able to read messages, each login will be unique.” Alice and Bob stay as they are.

Open questions

1. Lost-password recovery.

   • (a) A recovery key shown once at sign-up. Works in every browser. One extra step.
   • (b) Passkey only, synced through Apple, Google or a password manager. No extra step, but it needs passkey PRF in the first build, and not every browser and authenticator supports it yet.
   • (c) Both: the recovery key at launch, and passkeys when PRF ships.

   Recommended: (c) both. Passkeys are not in the first build, and without a recovery key a forgotten password loses history.

2. Launch bar.

   • (a) Stage A is the launch bar for invited owners. Sign-up and the verify page state plainly what the operator can and cannot do. Stage B comes before open sign-up.
   • (b) Wait for Stage B before hosting anyone else.

   Recommended: (a) Stage A for invited owners. Stored data is already unreadable to the operator, and the remaining gap is stated, not hidden.

3. Sign-up gating.

   • (a) Invite links. Each new owner needs a one-time link from the operator or an existing owner. No email provider needed at first.
   • (b) Open sign-up, with email verification through an email provider. Needs abuse limits and a provider account.

   Recommended: (a) invite links while the node runs on Stage A. Revisit at Stage B, once the isolation gate has held under real use.

4. Update notice period.

   • (a) 3 days.
   • (b) 7 days.
   • (c) 14 days.

   Recommended: (b) 7 days. Long enough for monitors and owners to react, short enough to ship fixes. In Stage A it is a public commitment the monitors check for the dashboard; in Stage B the hardware enforces it.

5. Cloud provider for Stage B.

   • (a) Google Cloud Confidential VMs, N2D or C3D with AMD SEV-SNP. Reports chain to AMD without trusting Google’s attestation service.
   • (b) Azure DCasv5 or ECasv5 with AMD SEV-SNP. Mature, but the guest sees attestation through Azure’s paravisor, which joins the trusted base.

   Recommended: (a) Google Cloud. This can wait until the Stage B spike. Pricing is confirmed at provisioning.