diff --git a/plan/policy.md b/plan/policy.md
index 0dafd72d..0c23b4b2 100644
--- a/plan/policy.md
+++ b/plan/policy.md
@@ -328,6 +328,56 @@ a policy only to say that making reuse negligible is preferable to enforcing
 one. Neither is an agent policy, neither is evaluated by the tree below, and
 neither denies a write.
 
+## What a policy is keyed on, and what that key is worth
+
+A rule that applies to "agents of this type" is keyed on something, and the
+strength of the whole rule is the strength of that key.
+
+- [ ] **Say what `agent_type` is worth, where a rule uses it.**
+      `AgentAccount::agent_type` is the harness's own word for what it is —
+      supplied in the provisioning request, not a checked fact, one tier below
+      an attested node in `docs/trust-model.md`'s terms. The running agent
+      cannot change it and the model never sets it, but whoever may provision
+      chooses which rule an account falls under. A policy scoped by agent type
+      is therefore exactly as trustworthy as the thing that provisioned the
+      account, and that sentence belongs next to any rule that uses it.
+- [ ] **A default that is narrow, with generous types named explicitly.** An
+      unknown or unrecognised type must fall to the narrow rule rather than
+      outside every rule. The failure of a typo'd type should be an agent that
+      can do less than intended, never one that escapes the rules entirely.
+- [ ] **`SubjectKind` and `agent_type` are different keys and must not be
+      conflated.** Kind is this server's own classification of an account
+      (`Agent`, `Pipeline`, `Host`, `Service`) and is not the caller's to
+      assert; type is the harness's label. A rule keyed on kind is worth more
+      than one keyed on type, and a reader should be able to tell which they
+      are looking at.
+
+## Configuration may narrow, never grant
+
+`didbot-config`'s own documentation, `plan/config.md` and
+`docs/deployment.md` all say that collection permissions belong in the
+owner's records rather than in this server's configuration file, and that a
+reviewer should reject a configuration key that adds "a scope, a permission,
+or an allowlist of apps" on that question alone.
+
+That rule holds, and there is a shape it does not forbid, worth writing down
+before somebody argues it either way in a review:
+
+- [ ] **Decide whether a narrowing-only configuration key is admissible.** A
+      key that can only *subtract* from what an agent could already do — the
+      same property `[disclosure]` has — cannot be used to grant anything.
+      Somebody who holds the host can lock an agent out with it and cannot
+      let one in. Whether that is enough to make it acceptable, given that
+      the accountable statement is meant to live in the owner's records, is
+      a question about what configuration is *for* rather than about what it
+      can do.
+- [ ] **If the answer is yes, say so in all four places at once.**
+      `didbot-config`'s crate documentation, `sections.rs`'s header,
+      `plan/config.md` and `docs/deployment.md` each state the prohibition
+      independently. A narrowing exception recorded in one of them is a
+      contradiction a future reader resolves by picking whichever they read
+      first.
+
 ## Deliberately unsettled
 
 These need iterative design and must not be invented by whoever implements