Authority Boundaries: Who Decides What

Long context magnifies permission mistakes

In a short task, a mistaken assumption can be corrected quickly. In a long task, the model may carry the wrong permission boundary across dozens of actions. That is how 'please inspect' becomes 'I pushed to production.' Absolutely charming, in the way a fire alarm is charming.

Operational beats vibes

Authority boundaries should be explicit: what the model can do alone, what it can prepare but not execute, and what only the human may approve. Do not say 'be careful.' Say 'commit locally; do not push' or 'use the existing dev server; do not stop it' or 'stage only these paths.' The model needs a rule it can test.

Boundaries belong in the spine

Authority is a long-running rule, not a per-turn reminder. Put it in the system prompt, version it, and let cache pick it up. A boundary that is only mentioned in a recent user message has lost the position fight before it started.

Authority must be operational, not vibes. If the model cannot test the rule, the rule is too mushy.

Code

Operational authority boundary·yaml

authority:
  model_may:
    - edit target files
    - run validation
    - create local commit
    - read any file in the repo
  model_must_not:
    - git push
    - stop existing dev server
    - stage unrelated dirty files
    - run rm -rf or destructive shell commands
  human_owns:
    - final publish
    - destructive cleanup
    - any action affecting shared infrastructure

Boundary in spine·markdown

<!-- SPINE -->
# Authority
You MAY: edit files, run pytest, create local commits.
You MUST NOT: git push, stop dev servers, modify .env files.
If required to do a forbidden action, stop and request human approval.
<!-- /SPINE -->

Authority Boundaries: Who Decides What

Long context magnifies permission mistakes

Operational beats vibes

Boundaries belong in the spine

Code

External links

Exercise

Progress

Comments 0