Agent policy (YAML)

AGENT_POLICY.yaml — the one machine-readable policy every checkpoint reads. If a rule isn’t here, it isn’t enforced.

engineering-standards/AGENT_POLICY.yaml is the canonical, machine-readable policy for every coding agent on this VPS — Claude Code, Codex, the Morpheus drain, and any future dashboard-coding agent. HARD RULE 11 names it the single source of truth. Everything else in the enforcement plane is, in a sense, just a different reader of this one file.

Why one file

If each agent carried its own copy of “what’s allowed,” the copies would drift and a gap in one would be an escape hatch for all. One policy, read by every checkpoint, means a rule added once applies everywhere at once — and there is exactly one place to audit.

What the policy contains

Section	What it defines
protected_paths	Globs that need a token to write, each with a category and a required scope (possibly null = never grantable).
scope_tokens	The set of recognised token names (auth, compose, meta, migration, …).
code_paths_requiring_task_approval	The middle tier: code paths that need an approved task plan (the task-approved token), even though they aren’t operator-only.
denied_commands	Shell-command patterns that are blocked, each with a reason and an optional unlocking scope or exception substring.
approval_required_commands	Commands that trigger the approval queue rather than an outright deny (e.g. build/recreate, HARD RULE 6).
approval_required	Which protected-path categories are approval-eligible, and the kind of approval they map to.

Who reads it

The policy has many consumers, and that is the point:

• The gate loads it before every write or command to decide allow / deny / approval-required.
• Landlock reads it to build the kernel-level allow-list for a process.
• The post-hoc sweep reads the protected-path list to check the diff after a run.
• PROTECTED_PATHS.md is generated from it for humans to read.
• The Morpheus drain’s scope guard reads it to build each task’s out-of-scope list.

Editing the policy is itself gated

Changing the policy is one of the most sensitive actions in the repo, so it is protected by the very system it defines:

• It is a protected path requiring the meta scope — you cannot edit it without an operator-issued token.
• It is routed by CODEOWNERS to the operator, so the change cannot merge without review.
• A CI consistency check (check-agent-policy-consistency) verifies the derived PROTECTED_PATHS.md still matches, failing the build on drift.

The lesson behind rule 11

Documents alone proved insufficient — the 2026-05-23 secret-cache incident broke three written rules at once. Moving the rules into this single machine-readable policy is what let the gate and the fitness tests turn each one from prose into a refusal.

See also

• The gate — the primary reader of this policy.
• Protected paths — the derived, human-readable view.
• Architecture invariants — the CI-time companion to write-time policy.
• Hard rules — rule 11 names this the single source of truth.
• Operator authority — how every agent’s gate consumes this policy.