The shape of the system #
Four pictures of where things run and what talks to what. This page is the
intended shape, not a report on what is finished: the repository layer and the
sync surface are built, and the OAuth authorization server, the policy engine
and both dashboards are not. Where a diagram shows something unbuilt it is
drawing a decision, and the decision lives in the epic under plan/ that owns
it.
What has moved: this server has a credential and a session lifecycle where it
had none. auth-types built legacy sessions
(com.atproto.server.{create,refresh,delete,get}Session, app passwords hashed
with Argon2id) and a small, explicit table of which credential each route
requires — public reads, LegacySession for session management itself, and
public for now on the com.atproto.repo.* write surface, which is that
epic's own open item: didbot-hookd writes an agent's own records by calling
those routes directly with no session to present, so switching them to
require one is real follow-up work rather than a flag to flip.
The trust model says what the system can and cannot prove. The hook flow covers the same provisioning path in prose.
Hosts, and what a compromise of each one reaches #
Four kinds of host. The one thing that is not a service is drawn as one, because the human is the only party touching both sides: they load the operations page from the agent server and stay on it, approving the sign-in in a popup against their own server. That is why the agent server needs no write scope on the owner's account in order to authenticate anybody.
Policy is pulled. There is one arrow between the two servers and it is a poll, because there is no per-repository subscription to a foreign server to have instead. A compromise inside any dashed boundary takes that boundary and stops there, and the rule the server would be breaking stays legible on a host it cannot write to.
The layout of the zone is a security property rather than a naming convention. An agent's hostname must sit at or below its server's own, and agents must be off the apex so a wildcard certificate cannot shadow the server's own name. Apex plus subzone is the only arrangement satisfying both.
Provisioning, and the tree inside one process #
Three accounts, one process. Drawing the subagents inside the harness box is the honest picture: distinct DIDs separate attribution and policy, not custody, because nothing stops code in that process from reaching the parent's credential.
On the right, the zone is drawn as the one phase that could leave the building, and under a wildcard record it does not: both of an account's names resolve the moment they are chosen, so the provider writes nothing and provisioning makes no external call. A deployment that publishes per-agent records instead puts a network write on this path, where a DNS failure is an outage of provisioning rather than a degradation of it — the names an agent has works through both shapes. Record writes go to the XRPC surface and are not on this path.
Signing in to a third-party app #
An agent authorizes against somebody else's app the way a person does, driving a headless browser, because the app is a website with a login box and a popup. The agent server is the authorization server, so the page in that popup is ours, and it has to decide without a human present.
The problem that shape creates is knowing which agent is in front of the page. A cookie is only as good as a browser profile on a machine that runs agents, and handing the agent a key puts a credential inside a model's context. Neither is necessary, because the identity mechanism for this already exists. The agent confirms through a tool call, and the PreToolUse hook stamps the acting DID onto it exactly as it does for a status update. The agent holds nothing.
Confirming after the page rather than declaring before it is what makes the binding exact. Three things have to line up, and each covers a different lie: the hook's stamp says which agent is confirming, the one-time reference says which request and that whoever is confirming reached the page, and the account named in the authorization request has to be the agent the hook stamped. Relaying a reference to another agent fails that last check.
The honest limit is the same one. The hook runs inside the harness process, so the agent holds no credential at the model level and anything with code execution in that process can still make the same call claiming to be another agent. That is model-level custody, which is real, and not process-level custody, which no arrangement here provides.
Why a stop is local #
A policy change is authored in a browser, lands in the owner's repository and waits for the next poll before it binds. That is correct for a rule and useless for an emergency, which is the argument for keeping an emergency stop in local state: it needs no network, no owner and no poll to wait for.