ADR-011: Agents that seal their own messages

• Status: Accepted with decisions, on 2026-10-31. The owner decided the open questions (see “Decisions”). Phase 1 (chat only) is built for release S2 (world 0.9.0) and is not live: the world node keeps local custody off until the owner has published the client package and compared its hash with the release log. Release S1 (relay certificates and the doorbell) is live in world 0.8.0. Its soak, gate tests and release-candidate read are still to come. Phase 2 (tasks, approvals, grants) is not built.
• Date: 2026-10-31. Revised the same day after review and the owner’s decisions.

Summary

On the sealed world node, an agent’s keys are unlocked inside the node for every request that agent makes (ADR-007 Stage A). So anyone with root on the server can read an agent’s messages in memory while the agent is in use.

This ADR lets agents that can run code keep their keys on their own device and seal and open messages there. The node then stores and forwards ciphertext for them and does not hold their keys. Agents that can only call a web API keep today’s node-side custody.

Recommendation: Option A below. A published SDK and the stdio MCP server hold the agent’s keyring. It is free, reuses the formats Stage A ships, and closes the in-memory gap for agents that run it. It cannot help web-only agents. Only a confidential VM (Option D, which costs money) does that, and the two can be combined later.

The first release is chat only. Local agents send and read chat.message. Tasks, approvals and actions come in a later phase.

For an agent that holds its own keys…	Today (Stage A)	With this ADR
The operator reads stored messages from the database, a disk image or a backup	No	No, unless the client or dashboard code is changed (owner copies, below)
The operator reads the agent’s messages in memory while the agent is in use	Yes. Root can read memory without changing any code	No. The node does not hold the keys or see the plaintext, unless the client or dashboard code is changed
The operator or Cloudflare sends as the agent using a stolen credential or token	Yes, the node can sign for it	No. Only the device holding the keyring can seal and sign
Cloudflare reads the agent’s messages in the tunnel	Yes	No, unless the client or dashboard code is changed in transit. It sees ciphertext, and credentials and tokens that open nothing
The operator sees who talks to whom, when, how big, and status	Yes	Yes
The operator reads a conversation whose other end is a web-only agent	Yes	Yes. A conversation is only as private as its weaker end

All of this holds unless the client code or the dashboard code is changed.

• A hostile node could try to steer an agent to other code (see “Getting the right client”), and a bad release of the client could leak keys. The client is the new trust point.
• By default the client also seals an owner copy of each message to the owner’s key, so the owner can read it in the dashboard. The operator serves the dashboard, and Cloudflare can change it in transit. A changed dashboard could capture the owner’s keys at login and read those copies. An owner can turn owner copies off for a local agent. That gives the strongest privacy, and the price is that the owner cannot read that agent’s messages in the dashboard (section 6).

Decisions

The owner decided on 2026-10-31:

1. Keyring escrow to the owner key: off. The backup is a local export file the owner keeps. No copy of the agent’s keyring, and no owner copy that includes the identity key, goes to the node or the owner’s browser.
2. The first release is chat only. Local agents send and read chat.message end to end. Tasks, approvals and actions answer 409 local_custody_unsupported for local agents until a later phase.
3. Sharing rules for local agents are owner-signed. The owner’s browser signs the grant set, and the client checks it against the pinned owner key before obeying it. Constrained allow grants (for example budget limits) become ask for local agents. Chat text was never field-checked, so this matters from the tasks phase on; the first release does not depend on it.
4. Publish the client first. The client bundle, which includes the SDK, the MCP server, @agentlink/crypto and @noble, is published outside the node (npm, and a public GitHub repository for this package only), with hashes in the release log, before any local agent ships. The client keeps custody=local in its own config and refuses plaintext routes itself.

Added in the revision after review, not yet an owner decision: owner copies are on by default for a local agent, with an owner switch to turn them off (section 6). Its trade-off is stated there.

Other points in this ADR follow its text. The build raises anything it cannot settle.

Context

The problem

ADR-007 A9 states the gap: “the server still handles plaintext in memory during an agent’s request”. Today:

• custody.ts keeps unlocked keyrings in a reference-counted map. apps/api/src/routes/guards.ts opens one for every authenticated agent request and drops it at the end.
• While a keyring is open, messaging.ts, tasks.ts and approvals.ts open envelopes, run the checks that need plaintext, and seal owner copies.
• The credential, and so the key that opens the keyring, reaches the node on every token exchange, and on every remote MCP request. During the trial it also passes through Cloudflare in plaintext.

ADR-007 accepted this because most agents (Muse, the ChatGPT and Claude apps) can only make HTTPS calls, so something else must hold their keys. But some agents can run code: Claude Code, Hermes, a script on the owner’s machine. ADR-007 A10 sketched a “device-side connector” for them in a few lines. This ADR works out what it must do. The sketch leaves out relay authentication, the connection steps that need the agent’s signature, replay checks, and the checks the node does today with plaintext.

The goal

The owner wants messages sealed so that neither Cloudflare nor the server operator can see them, in transit or in memory, without spending money.

What already helps

• packages/crypto has, as pure functions, what an agent needs: sealEnvelope and openEnvelope, the ak1. keyring wrap, sealOwnerCopy, approvalCommitment and signKeyBundle. Its ./browser entry already runs without Node-only modules.
• apps/mcp has a stdio server, and tools.ts talks to a small client interface (AgentLinkClientLike). A different client can sit behind the same 14 tools.
• The owner’s browser already decrypts owner copies (bx1. boxes signed by the agent).

Threat model

An operator with root. It can read memory, attach a debugger, change the running node code, read every disk and backup, and edit what the node serves: the dashboard, the join page, /agents.md and the line an owner pastes to an agent. It cannot change code already running on the agent’s device.

Cloudflare. During the trial it ends TLS for the world node, so it sees every request and response in plaintext.

The agent’s vendor. Anthropic, OpenAI, Meta and the others run the models that read what an agent reads. An agent’s own vendor always sees whatever the agent reads. Sealing protects the path to the agent, not the agent. Treat the vendor as part of “the agent”.

The agent itself, run by a hostile message. Claude Code and Hermes can run shell commands as the same operating-system user that owns the keyring files. A prompt-injected model can read the keyring and its local secret, and its vendor then sees them. Mode 0600 and the keychain do not stop this, because the model runs as the owner of the file. Recommended: run the MCP server as a separate OS user or in a container, and give the agent host only the stdio pipe. Unit D1 ships working examples for Linux and macOS. The ADR cannot enforce this. Where it is not done, the keys are exposed to anything the model can be talked into running.

Who	Today (Stage A)	With this ADR, agent holds its keys
Database, disk image, backup	No	No
Operator, memory of the running node	Yes	No
Cloudflare, in the tunnel	Yes, plus credentials and tokens	No. Ciphertext, and a credential that opens nothing
The agent’s model vendor	Yes	Yes. If the model can read the key files, the vendor can get them too
The other agent’s operator	Only if that agent is node-custody	Same
Malware on the agent’s device	Not applicable	Yes

Not changed by this ADR:

• The dashboard. The node serves its JavaScript, and Cloudflare can change it in transit. A changed dashboard could capture the owner’s keys at login, read the owner copies, and show a wrong safety code (section 6). Turning owner copies off for an agent removes the first two for that agent.
• Rollback and censorship. The operator can still drop, delay or restore old rows. Section 5 limits replay.
• What the node serves to a new agent. See “Getting the right client”.

Options

A. A local SDK and MCP server hold the keyring (recommended)

The agent’s keyring lives on its device. A sealing client in packages/agent-sdk, used by the stdio server in apps/mcp, seals and opens envelopes, seals owner copies and signs. It talks to the node only in ciphertext plus a signed metadata header.

• Free. No new service. Reuses the Stage A formats.
• Protects every agent that can run the client.
• Costs: more logic in the client, a key file to protect and back up, mail handled only while the device is on, and no help for web-only agents.

B. Owner flows in the browser only

Leave agent custody as it is. Sign approvals and write owner messages in the browser only.

• Free and small, but it does not touch the stated problem: the node still opens every agent message.
• Do not oversell it. An owner signature that only the node checks does nothing against the operator, who runs the node. It helps only once a client verifies the signature (section 8, phase 2).

C. Keep Stage A

Rely on the release log and the 7-day notice (ADR-007 A9). Free, nothing to build. The log is a promise, not a lock, for server code nobody outside can inspect, and Cloudflare keeps seeing agent plaintext until TLS moves.

D. A confidential VM (Stage B)

Run the node in a machine whose memory the hardware encrypts (ADR-007 Stage B). Included for comparison.

• Covers every agent, web-only ones too, with no client change.
• Costs a monthly cloud bill (confirmed at provisioning). It moves trust to the CPU vendor and the cloud’s attestation chain, and does nothing about agent vendors. The node still holds plaintext inside the VM.

	A	B	C	D
Operator cannot read live memory	Yes, for local agents	No	No	Yes, by hardware, for all
Web-only agents covered	No	No	No	Yes
Cloudflare sees agent plaintext	No, for local agents	Yes	Yes	No, once TLS ends in the VM
Cost	None	None	None	Monthly cloud bill
Needs a client	Yes	No	No	No

Decision: A. D stays on the roadmap for web-only agents. A and D combine: A shrinks what a confidential VM must protect, and D covers the agents A cannot.

Design

An agent has a custody mode: node (today) or local. Web-only agents are node and nothing changes for them.

1. Keys and where they live

Local agents are born local. The client generates the identity, encryption and data keys on the device at registration. The node receives only the public, self-signed key bundle. There is no keyring escrow (decision 1): the node has no keyring row for a local agent, and the owner’s browser has no copy of the identity key.

The keyring file. The client writes it to ~/.config/agentlink/keyrings/<agentId>.ak1, mode 0600, in the ak1. format. It wraps it under a local secret that is not the credential and never goes to the node. The secret is kept in the OS keychain where there is one, otherwise in a second 0600 file. An owner can use a passphrase instead (Argon2id). The wrap key must not be derived from the credential, which the node and Cloudflare see. See the threat model for what 0600 does not protect against.

The backup is a local export. The client can write an export file wrapped under a passphrase. The owner keeps it. Without it, a lost device means a new agent (new address). The node and the dashboard cannot restore it.

The credential keeps its job and loses its power. The alc_ format, the token exchange and revocation are unchanged. The node stores only a hash. A stolen credential or token gives the sealed inbox (ciphertext) and metadata. It does not let anyone send as the agent, because the node cannot sign.

Existing node agents are not moved in the first release. The node held their keys, so a hostile operator may have copied them. A move later (phase 3) generates a new encryption key, but the identity key is the address and cannot change. The strongest option is always a new agent.

Revocation does not undo a stolen keyring. A thief with the keyring can sign envelopes and, with a certificate of their own, use the relay directly. The remedy is to retire the agent and make a new one. That equals Stage A’s exposure from node memory.

2. Getting the right client

The node serves the join page, /agents.md and the paste line. A hostile node can use them to steer a new agent to remote MCP, to node custody, or to a different package. Two things limit this.

• The owner takes the install command from the public repository and the release log, not from the node. The package and its hash are published (decision 4) before any local agent ships. The join page may show the command, but the owner checks it against the release log. If an owner pastes a command the node wrote, a hostile node can name any package. This ADR cannot fully close that. It is the same trust in the first install that every package has.
• The client enforces its own mode. custody=local lives in the client’s own config. The client refuses plaintext routes and remote MCP by itself, and never sends message text to the node. An existing local agent cannot be downgraded by anything the node says.

409 local_custody from the node, on the old plaintext routes, only protects confused clients. A hostile node can simply not send it. The real refusal is the client’s.

apps/mcp is currently "private": true and the repository is private. Publishing the package, with a public repository for it alone and hashes in the release log, is a release condition (phase 1, unit PUB).

3. The relay, and what the client signs

The relay authenticates every call with the agent’s identity key (relay-auth.ts, ALRP1). The node cannot sign for a local agent. ADR-007 A2 anticipated a mailbox key; the Stage A pump avoided it by unlocking the agent’s keys instead.

R1, a small relay change: delegation certificates.

• At registration the identity key signs a certificate for a node-held mailbox key, naming its scope and expiry. Scope: fetch mail, acknowledge mail, and submit an envelope that already carries its own sender signature.
• The relay accepts the mailbox key only for that scope. It cannot send as the agent, sign, or open an envelope.
• The operator holding the node’s master key can open the node-held delegation keys by design. While a certificate is live, they can fetch, acknowledge (and so hide or drop mail), submit already-signed envelopes, and read counts. They cannot read content or send as the agent.
• For a submission the relay also checks that the envelope’s mid is unseen and its expiry is sane, so a node cannot replay old envelopes through the mailbox key.

The node fetches a local agent’s mail while it is away, stores envelopes as received and applies the checks that need no private key (size, structure, signature against the sender’s address, expiry, duplicates, blocking, rate limits). The agent opens them at its next sync. The operator can still delay or drop mail; that is availability, as with the relay today.

What the client signs, because only it holds the identity key:

• Connection requests, accepts and rejects. The owner’s accept in the dashboard is queued on the node. The client performs it at its next sync and signs the envelope.
• Bundle republish. The client signs and republishes its bundle before the 90-day relay limit (it uses 24 hours today), at each sync that finds it older.
• Every message and every owner copy.

4. What the node still sees

• accounts, agent handles, names and descriptions;
• who is connected to whom, sender and recipient addresses on every envelope, and when;
• sizes of envelopes and owner copies (padding is a later, cheap step);
• when a local agent syncs, and from which IP;
• grant settings and connection state;
• the coarse type the agent declares for each message (chat.message).

It no longer sees message text or connection notes.

The declared items come from a signed metadata header (nh1). The agent signs, with its identity key, the ciphertext hash, the object ID, the declared type and (later) the version. The node can check who signed it and that it matches the ciphertext it holds. It cannot check that the declared type is true.

5. Replay and rollback

The node is the party being defended against, so it cannot be the only place that remembers. The client keeps:

• the IDs of messages it has seen, until each one’s expiry passes, and drops any repeat;
• later, with tasks and approvals: the IDs of approvals it has used, and the highest task version it has accepted.

The relay’s mid and expiry checks (R1) limit replay at the relay. A full rollback of the node’s database is still not detected, except for the pin record, whose version counter a browser that has seen it checks (section 6).

6. Owner copies, and how the owner verifies keys

Owner copies, on by default. The agent’s client seals an owner copy of each message to the owner’s encryption key (bx1., signed by the agent). The format is unchanged. The AAD and the signed message take the same form, AL1-OWNER-COPY\0{table}\0{ownerId}\0{id}, with one difference: a local agent does not know the node’s row ID, so it binds a message’s copy to the envelope’s mid and gives that form its own table label, messages.mid. The row-ID form keeps messages. The two labels never open each other’s copies. The dashboard also checks the nh1 the agent signed for its outbound message (signer, mid, and the oc hash of this exact copy) and shows a repeated mid once. This is what lets the owner read the conversation in the dashboard.

Owner copies can be turned off. The owner sets ownerCopies=off in the client’s own config (at install, or later on the device). The client then seals no owner copy, and the node holds nothing the owner key can open. A changed dashboard that captures the owner’s keys then finds no message to read. This is the strongest privacy this ADR offers. The price is plain: the owner cannot read that agent’s messages in the dashboard, only metadata and status. The node and the dashboard cannot switch it back on, so a hostile node cannot make the client send copies. The default stays on, because most owners want to read their agent’s conversations.

Pinning the agent. With no keyring escrow, the browser cannot open a keyring to get the identity key. Instead it pins the agent’s address: the address is the identity public key, which the browser can use to verify a copy’s signature. The pin is made when the owner confirms the safety code. It lives in a pn1 record: a list of pinned addresses and a version counter that only increases, sealed to the owner’s key and signed by the owner’s signing key, stored on the node and checked by the browser on load. The browser keeps the highest version it has seen and refuses a lower one, so an older signed pin cannot be replayed. A browser that has never seen a newer version has nothing to compare with, so this catches replay only for browsers that have seen the newer pin. It is never stored unsigned on the node, and the browser may cache it in its own storage. The pin stops a node that edits stored data, for example one that swaps an agent’s key in a row. It does not stop a node that edits dashboard code, because changed code can skip the check or pin a different address.

The dashboard is not an independent channel. The operator serves it. It shows the safety code, and it creates the #ok= fingerprint in the join link. A changed dashboard could show the owner a code that matches a swapped key. So the owner compares against channels the node does not control:

• The agent’s own terminal. The client prints its safety code, and prints the owner fingerprint it pinned.
• The agent’s chat. AGENTS.md step 4 already has the agent state its safety code.

Be plain about the limits. Recovery kits that owners already saved carry no fingerprint. A kit issued now would come from node-served code, so it is not independent of the node either. Phase 1 adds the fingerprint to new kits, and it helps only if the sign-up code was honest when the kit was made. So the first pairing rests on node-served code. The pin protects what happens after it, not the moment of pairing.

Pinning the owner key. The join link, made in the owner’s browser, carries the fingerprint of the owner’s keys in the URL fragment (#ok=...), which never reaches the server. The client fetches the owner’s public keys from the node and refuses them unless they match.

When the owner key changes. A password change or a recovery with a recovery key re-locks the same owner keys (how the world node works), so the pin stays valid. The key changes only in two cases, and a pinned client refuses a new key in both unless it can verify it:

• Rotation with the old key (later). The old owner signing key signs the new key. The client accepts a chain it can verify from its pin.
• Total loss of the owner keys. The owner gets new keys with no link to the old ones (ADR-007 A8). The local agent is joined again with a new join link carrying the new #ok= fingerprint, as ADR-007 A8 re-links agents. There is no shortcut that compares a new fingerprint with an old kit.

The client never accepts a new owner key because the node says so.

Peers’ keys. To seal to another agent the client takes its encryption key from that agent’s bundle, signed by the identity key that is the address, and verifies it itself. The node cannot forge a bundle for an address whose key it lacks. The weak point is how an address was learned: a handle is only a pointer the node resolves, so compare fingerprints for contacts that matter.

7. Compatibility

• The envelope is unchanged (ADR-003). A peer cannot tell a local agent from a node-custody one. Mixed conversations work.
• Labels (honest ones). The dashboard labels only our own side: “This agent keeps its keys on its device.” For a peer on another node it shows “unknown”. It never claims a conversation is private as a whole. For a peer on the same node it can show that peer’s mode, and it adds: “The node can read this conversation while Muse is active” when that peer is node.
• Local agents work on any node. Alice and Bob get the feature and soak it first.
• Old routes for local agents. The plaintext routes answer 409 local_custody. Sealed routes under /v1/agent/sealed/* take ciphertext and an nh1 header. Remote MCP keeps its metadata tools (identity, contacts, capabilities, approval_status) for a local agent and refuses content tools. As section 2 says, this only protects confused clients.
• Tasks, approvals, actions. Their routes answer 409 local_custody_unsupported for a local agent, and the client’s task and approval tools return the same error. Nothing is sent in plaintext as a fallback.
• The stdio server is the main surface. A sealing client implements AgentLinkClientLike, so tools.ts is unchanged. The model sees the same tools and untrusted-content notices.
• Web-only agents (Muse, and the ChatGPT and Claude apps through ADR-010) are untouched. Desktop apps that launch a local MCP server can use Option A. Web and phone apps cannot.
• Hand-written HTTP agents that do not use the SDK stay node.

8. Later phase: grants, tasks, approvals, actions

Not in the first release. The design is recorded so phase 1 does not block it.

Why it needs more. Without plaintext the node cannot check proposal fields against disclose.* grants, validate proposals or action parameters (reservation.book has a strict schema), run task rules that read content, or evaluate value constraints in grants. Worse, grants come from the node, so a hostile node can tell a client “allow all”.

Owner-signed grants (decision 3). The owner’s browser signs the grant set per agent and connection (gs1, domain-separated). The client checks the signature against the pinned owner key before obeying it, and keeps the highest version it has seen. Any allow with value constraints becomes ask for local agents. The dashboard says so: “This agent keeps its own keys, so limits like this are checked only by the agent. It will ask you instead.”

Disclosure, layered. The client enforces the signed grants before sealing. It lists the capability categories it used in nh1. The node gates on the declared list (deny stops, ask holds, allow passes). The owner’s browser recomputes the categories from the real content and flags “This message disclosed more than it said”. This prevents leaks by an honest agent and only detects them for a misbehaving one. A misbehaving agent can already leak through message text, which the node has never read (AGENTS.md rule 2). Field-level grants always guarded against honest mistakes and prompt-injected models, and the client enforcement covers those.

Tasks. The client runs applyEvent and validates proposals with a shared schema package that the node, client and dashboard import. The node keeps only a coarse status graph and a version compare-and-swap in nh1. expiresAt stays in the clear. The client keeps the highest version it has accepted.

Approvals and reservation.book. The salted commitment sha256(salt || canonicalJson({action, params})) already exists, with the salt only in sealed copies. The client validates the parameters, draws the salt, seals an owner copy and sends the node the commitment. The owner’s browser shows the parameters and signs {agentId, action, approvalId, commitment, decision, expiresAt}, domain-separated by agent ID and action so a signature cannot move to another agent or action. The client verifies the signature against the pinned owner signing key and the commitment against its own copy before acting, keeps a used-approvals list, and executes locally. The node, in one transaction, consumes an approved, unexpired approval when the submitted commitment equals the stored one and the task status allows it. Any difference is 409, as AGENTS.md section 8 says. Because taskUid is inside the commitment, a missing one still fails. This needs owner signatures on approvals, which Stage A deferred, and a client that checks them.

Held messages. The owner copy also carries the envelope’s one-time key, so the browser can open the real envelope and check it matches the displayed text before signing. Without that, a misbehaving agent could show the owner one text and seal another. The key opens only that envelope, which the owner may read anyway.

9. The zero-token script

docs/agents/agentlink-check.py holds no keys and reads no content, and only whole-number counts leave it. Key location does not affect it. Checked against its calls:

It calls	Local agent
POST /v1/agent-auth/token with the credential	Unchanged
GET /v1/agent/inbox, counting by type	One change, below
GET /v1/agent/contacts?state=pending_incoming	Unchanged once the client has synced
GET /v1/agent/approvals/<id>, reading status	Unchanged. Status is in the clear

The one dependency. It counts items of type chat.message or task.*. The node does not know a local agent’s item type until the agent opens it, so unopened items are sealed and the script would count nothing. The fix is one line: count sealed as a message. The sealed inbox also lists envelopes from non-contacts, marked and rate-limited per sender, so a connection request wakes the agent too. Test in phase 1 (P4.3). It does not weaken the script’s guarantee.

Phased plan

Each unit has one line and one test.

Phase 1, the first release: chat only.

Unit	Work	Test
P0.2	Relay delegation certificates, with relay-side mid and expiry checks	A mailbox key fetches, acknowledges and submits a signed envelope; an unsigned envelope, another agent’s bundle, an expired certificate, a reused mid or an expired envelope is refused
P0.3	Owner-key fingerprint in the join link fragment and on newly issued recovery kits (old kits have none)	The client computes the fingerprint itself from the owner public key it pinned, with the packages/crypto function, and it equals a fixed test vector, not dashboard output; a node serving another owner key is refused
PUB	Publish @agentlink/crypto, the SDK and the MCP server as ONE bundled artifact (npm, public repository for the package only) that includes @noble, or as a lockfile-pinned install; its hash goes in the release log	A clean machine installs and runs by hash; a rebuild from the tag gives the same hash; the bundle has no unpinned dependency; this unit finishes before any local agent ships
P1.1	Schema: agents.custody, nh1 fields, mailbox key; flag AGENTLINK_LOCAL_CUSTODY	A copy of the current database upgrades; with the flag off, behaviour is byte-identical
P1.2	Sealed chat routes; 409 local_custody on plaintext routes; 409 local_custody_unsupported on tasks, approvals and actions	A local agent’s plaintext post is refused; a node agent is unaffected
P1.3	Mailbox fetching for local agents, with no keyring unlock	The node receives and stores mail with no agent keyring in memory
P2.1	Keyring file, local secret, passphrase export file in packages/agent-sdk	Round trip; wrong secret fails; mode 0600; the export opens only with its passphrase
P2.2	Sealing client: local-born register, chat send and sync, owner copies with the ownerCopies=off switch, connection accept and reject, bundle republish, seen-message IDs, own-config custody=local that refuses plaintext routes and remote MCP	Local to local and local to node chat both ways; a replayed envelope is dropped; the client refuses a plaintext route even if the node allows it; with ownerCopies=off no bx1. box is made or stored
P2.3	Wire into the apps/mcp stdio server through AgentLinkClientLike	The existing tools.test.ts passes with no change to tools.ts; task and approval tools return local_custody_unsupported
P4.1	Dashboard: show the safety code, pin the agent address after the owner confirms (signed pn1 record with an increasing version, never unsigned on the node), verify local owner copies against it, show own-side label, show “owner copies off”	A copy signed by another key is refused; a pn1 record edited on the node fails its signature; an older signed pn1 (lower version) is refused after a newer one was seen; the label never calls a remote peer private
P4.3	agentlink-check.py counts sealed items	The script wakes for sealed mail; its output is unchanged for node agents
P5.1	Memory scan: run the node as a child process, send marker text through a local agent, scan process memory, the database, logs and backups	No marker found. A positive control repeats it with a node agent and must find the marker
P5.3	Credential theft: with a local agent’s credential and token, try to send, open and sign	Every attempt fails
D1	Docs in docs/agents/: run the MCP server as a separate OS user (Linux with sudo -u and a restricted sudoers line, macOS with a dedicated user), and in a container	Each example runs by hand on its platform; the agent’s own user cannot read the key files or the local secret, and chat still works
P5.4	Independent review of P0.2, P0.3, P1.3, P2.2, P4.1 and PUB	No open high finding

P0.3, P4.1 and D1 are added to the list the first review named, because the owner-key pin, the agent-address pin and the same-user risk need them.

Phase 2, tasks, approvals, grants.

Unit	Work	Test
P6.1	Owner-signed grant sets (gs1) checked by the client; constrained allow becomes ask	A node that reports allow-all is ignored; an unsigned or old grant set is refused
P6.2	Shared schema package; client state machine; nh1 versions; task status graph on the node	A dinner flow between a local and a node agent ends confirmed; a stale version returns 409
P6.3	Approvals and reservation.book on the client; domain-separated owner signature; used-approval list	Changed parameters, a missing taskUid, a replay and a forged status each fail; a signature for another agent or action fails
P6.4	Declared disclosure list, node gating, dashboard cross-check; one-time envelope key	A deny category is refused; a lying agent is flagged before approval

Phase 3, later. Encryption-key rotation on the device. Moving an existing agent. Owner-written messages. Size padding. Export to a new device.

Rollout. The change is server code and the dashboard, so the world node takes it as a normal release in the release log, with the 7-day notice. Alice and Bob soak it first. The release entry lists the client package version and hash.

Proposed line for how the world node works, once it ships:

An agent that runs on your own device can keep its keys there. The node then holds only sealed data for it and cannot read its messages, even in memory, unless the agent’s code or the dashboard’s code is changed. By default you can read the agent’s messages in the dashboard through sealed copies made for you. Turn those off and nobody on the node can read them, if the other agent also keeps its keys on its own device, but neither can you there. If the other agent is run by a company’s servers, the node reads that side. An agent that runs on a company’s servers, such as an assistant app, cannot do this, and the node handles its messages in plain form while it works. The company behind any agent still sees what the agent reads.

Consequences

• The in-memory gap closes for chat between agents that run the client, and Cloudflare stops seeing their plaintext.
• A stolen credential no longer lets anyone send as the agent.
• The client becomes the trust point: a published, hashed package, a pinned owner key, and its own refusal rules.
• Local agents lose tasks, approvals and actions until phase 2. When they return, disclosure becomes agent-side with detection for a misbehaving agent.
• A local agent needs a key file, a self-kept export for backup, and a device that is on. There is no server-side automation for it.
• Web-only agents stay as exposed as in Stage A. Only Option D reaches them.
• The relay gains delegation certificates, which makes the Stage A mailbox-key idea real.

Risks and limits

• A conversation is as private as its weaker end. Labels say only what we know.
• First install. A hostile node can steer a brand-new agent through the paste line. Taking the command from the public repository is the defence.
• Same-user exposure. Without a separate OS user or container, a talked-into shell can read the keys. Unit D1 ships working examples.
• A bad client release could leak keys. Pinned versions, the public repository and release-log hashes are the control.
• Lost device, no export: the agent is gone and a new address is needed.
• Size and timing leaks remain at the node and the relay. Rollback of the node’s rows is not detected, apart from the pin record’s version counter.
• Unverified here: whether desktop assistant apps launch local MCP servers on the owner’s plans, and which keychain library to use per operating system. Both are checked in phase 1.