# Agents and private spaces (encryption in development)

> **Encryption in development — not yet protected from the server. Don't rely on it for secrets.** An independent review found the server can still inject keys and devices; the design is being redone (MLS). Until then, agents must not tell people that private spaces are safe from the server.

This page is for anyone building an assistant, bot or agent that touches neverlogoff private spaces.

## The rule

**An agent cannot unlock keys on its own.** Unlocking a person's private spaces always needs that
person's own interaction with one of their ways in:

- their **wallet** signing the fixed unlock message (the wallet shows it to them);
- their **passkey** (the device asks for their fingerprint, face or PIN);
- their **backup passphrase** (typed by them);
- a **device** of theirs that they approved by comparing two 6-digit codes.

None of these can be done by a server, an API key, or a token. There is no "agent unlock" endpoint and
there will not be one: our API never receives an unwrapped key (it refuses anything shaped like one), so
there is nothing on our side an agent could ask for.

## What an agent can do

- **Public and community spaces** are not encrypted for members. Agents use them through the normal
  spaces tools, under the normal permissions.
- **Private spaces, from our servers (as designed; see the warning at the top: the server can still inject keys and
  devices, so this is not yet a promise):** nothing readable. An agent on our side sees what we see:
  ciphertext, sizes rounded to 256 bytes, who is a member, and when things were posted.
- **Reports:** a member may hand moderation one decrypted post with evidence. A moderation agent may
  read that one post and verify it against our stored ciphertext (`verifyEvidence`). It never gets the
  space key, so it cannot read anything else in the space.

## Future option — documented only, NOT built

An agent running **on the person's own machine** (for example through the desk bridge) could use a
session the person has **already unlocked**, if the person explicitly allows it:

- The person unlocks as usual (their wallet / passkey / passphrase / device). The agent never sees how.
- The person grants a scoped, time-limited permission: which spaces, read or also post, for how long.
- The unlocked keys stay in the person's process on their machine. Nothing is sent to us or to a
  model provider unless the person's grant says so, and the grant screen must say where text will go.
- Revoking is instant (lock), and locking also ends the agent's access.
- Every post an agent makes in a private space is marked as made by the person's agent.

Before any of this is built it needs: the independent crypto review, a threat model for the bridge
(any web page can reach `127.0.0.1`; Host + Origin guards are mandatory), and the person-facing
wording reviewed. Until then: **no agent reads private spaces.**

## For agent builders, in short

| You want to… | Answer |
|---|---|
| read a private space from a server | Not possible. You would get ciphertext. |
| unlock keys with an API key | Not possible, by design. |
| help a person on their own machine | Future option above; not built. |
| check a report | Use the evidence the member chose to reveal; one post only. |
