GOV-DSN-01Tier IGovernance-by-Design

Policy-as-Code for Agents

Express organisational policy as executable, versioned, tested code that the runtime enforces, not prose in a governance PDF.

Runtime: Reason / PlanAgentOps: Design & ScopeSee on the matrix →
POLICY-AS-CODE VS PAPER POLICYPAPER POLICY Word document · approved No runtime reference Drifts from reality Audit by interviewPOLICY-AS-CODE Declarative rules in git Evaluated per tool call Covered by unit tests Audit by log replay
In Plain English

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.

Placement

Where this pattern acts in the two lifecycles

Runtime Cognitive
01Perceive
02Reason / Plan
03Decide
04Act
05Observe
06Reflect / Learn
07Terminate

02 Reason / Plan. Interpret goal, decompose, select strategy. 13 of 61 catalogue patterns act at this stage.

AgentOps Lifecycle
01Design & Scope
02Build & Integrate
03Evaluate & Red-Team
04Deploy
05Operate & Monitor
06Iterate & Adapt
07Decommission

01 Design & Scope. Use-case assessment, autonomy tier, risk bounding. 11 of 61 catalogue patterns act at this stage.

Stages and counts from the catalogue data. The Runtime lens is the loop the agent runs each turn; the AgentOps lens is the lifecycle the team runs the agent through. See the Matrix for every pattern at each stage.

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