Policy-as-Code for Agents
Express organisational policy as executable, versioned, tested code that the runtime enforces — not prose in a governance PDF.
This page is the complete instruction page for one pattern called "Policy-as-Code for Agents." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
"The system shall maintain appropriate logging" is a sentence. "Every tool invocation emits a structured trace with user ID, tool name, input hash, and authorisation decision, retained for 90 days in an append-only store" is a control. The gap between the two is where governance programmes fail first audits.
Problem
Paper policy cannot be enforced, tested, or evidenced. Policies written only in prose always drift from implementation.
Forces
- Regulatory clarity vs engineering specificity
- Flexibility for exceptions vs deterministic enforcement
Solution
Encode policy as declarative rules (OPA/Rego, Cedar, or purpose-built DSL). Rules are versioned in source control, covered by unit tests, deployed as part of the agent runtime, and evaluated per tool call. Exceptions go through a policy-review process that updates the code, not an email.
Applicability
- All regulated-sector deployments
- Multi-agent platforms
- Any organisation expecting external audit
Anti-Patterns
- Policy lives only in a Word document
- "Compliance by reminder" — training slides instead of enforcement
Consequences
- +Policies become testable artefacts
- +Uniform enforcement across agents
- −Requires policy-engineering skill
- −Rules must be maintained as law changes