# Policy as Code and Managed Settings — AI Coding-Agent Guardrails

Source: https://www.geekswithgeeks.com/en/coding-agent-guardrails/hook-policy-as-code

> 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.

```text
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
```

**Quiz:** Why store the agent policy in the repository?

- [ ] So agents can edit it freely
- [ ] Because Git requires it
- [ ] To make it secret
- [x] 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.
