id: write-policy title: Which agents may write which record types status: open crates: [didbot-pds, didbot-serve] dependsOn: [pds-writes] exitCriterion: > An agent whose profile does not permit a collection is refused when it writes one, and the refusal names the policy. #

write-policy #

Superseded. policy settles the model this epic assumed — denials only, evaluated at the write, from three sources — and where the two disagree, this file is wrong. Read that one first.

The server refuses collections it does not define and records that fail their lexicon. Neither is policy: both give the same answer for every agent. Missing is the per-agent question — this one may record and not remember.

The natural key is the agent's type, which is what distinct subagent DIDs are for.

• A collection permission per agent, attached at provisioning.

• Who may write an account's own profile, and its picture. The server draws an avatar at provisioning and writes app.bsky.actor.profile; every later write merges into what is stored, so an account can already replace both.

  **The factual half of this changed and this item used to say
  otherwise.** There *is* authentication on a repo write now:
  `createRecord`, `putRecord`, `deleteRecord` and `applyWrites` all go
  through `auth::require_agent_token_or_dpop`, which resolves an agent
  token or a DPoP-bound OAuth access token to a DID, and
  `routes::write_record` refuses with `repo_mismatch` when the resolved
  DID is not the repository named. So today's answer is "the account
  itself, holding a credential this server issued" — not "anyone who can
  reach the server". What is still undecided is the policy on top of
  that: whether an agent *should* be able to set its own picture and its
  own profile fields at all. Whether an agent may set its own
  picture, and through what, is a policy question rather than a drawing
  question: an avatar arriving from outside is a claim about an identity,
  and the rule that a profile is identity and never comes from the model
  is written in `didbot-pds`'s profile module. Settle it here before
  any tool offers it.
  

Done #

• Enforce it at the write, not only in the token. A rule about what an account may ever write has to hold for sessions issued before the rule changed. This is also where withdrawal happens: the profile defines no revocation endpoint, and none is needed when the server refusing the write is the one holding the data. The policy gate judges every write, so a denial refuses a token issued before it: crates/didbot-serve/tests/denied_app.rs holds a login across a denial and sees its next write refused, with nothing revoked.
• A distinct refusal, so "your policy forbids this" is not read as "this record is malformed". A policy refusal is 403 PolicyViolation, carrying the policy's own reason, where a malformed record is 400 InvalidRecord (crates/didbot-serve/src/error.rs); crates/didbot-serve/tests/cedar_write_routes.rs reads it back from every route that writes a record.
• From server configuration first, from the operator's records second (policy-store). The server's own half is the floor compiled into the binary (crates/didbot-policy-records/floor/), and crates/didbot-serve/src/policy_poll.rs builds the operator's bot.did.policy and bot.did.policyBinding records into the gate every write is judged by.
• Collections outside this deployment's namespace are refused.
• $type inside a record may not contradict its collection.
• Records validated against their lexicons, explicitly, on write.