Lesson 19 / 25

Policy as Code and Managed Settings

Keep guardrail configuration versioned, reviewed and enforced consistently across a team.

One policy, reviewed like code

Store permission files, hook scripts and the project guide in the repository so changes go through pull requests. For organisations, many tools support managed or enterprise settings that individual developers cannot override, giving a non-negotiable baseline (for example "never read .env*", "no network except these hosts"). Individuals may then add stricter personal rules but not weaker ones.

Layering policies

Stricter always wins: deny anywhere beats allow elsewhere. Exact file locations and precedence differ by tool, so check the documentation.

Organisation (managed)   cannot be overridden: deny secrets, restrict network
  v
Project (in the repo)     reviewed by the team: commands, protected paths, hooks
  v
Personal (local only)     may add stricter rules, never weaker ones

Quick check: Why store the agent policy in the repository?

So agents can edit it freely
Because Git requires it
To make it secret
So changes are reviewed and shared like code

Answer

So changes are reviewed and shared like code — Version control gives history, review and a single shared baseline.