Policy as code is arriving in AI agent governance — Kyndryl, Microsoft, and Altimetrik are all publishing on it in 2026. Most of what they describe is declaration: expressing agent policy as structured configuration rather than prose. The part most implementations leave out is enforcement: a runtime gate that evaluates the policy against every action before execution and produces a signed receipt as proof.
Most AI agent "policies" today live in the system prompt. The prompt tells the agent what it's allowed to do, what steps to follow, what data it may access. This is policy-as-natural-language: readable by humans, interpretable by the model, unenforceable by anything.
A system prompt is a probabilistic instruction. The model reads it and approximates compliance on each generation. There is no mechanism that prevents a non-compliant action from executing — if the model generates a bad output, the action runs. If a prompt injection overwrites the instruction, the agent follows the injection. If the model simply hallucinates a step that isn't in the policy, nothing stops it.
| Policy expression | Machine-readable | Versioned | Enforced before execution | Auditable evidence |
|---|---|---|---|---|
| System prompt / guidelines | No — natural language | No — lives in model context | No — probabilistic | No — model output only |
| Post-hoc evaluation (LLM judge) | Partial — structured prompt | Partial — prompt versioning | No — runs after execution | Partial — evaluation records |
| Policy as code — enforcement gate | Yes — structured contract | Yes — versioned with deployment | Yes — gate fires pre-execution | Yes — signed receipt per decision |
Policy as code in the DevOps sense (Open Policy Agent, HashiCorp Sentinel) evaluates infrastructure configuration at deploy time — checking whether a proposed change conforms to policy before it is applied. That is useful, but it is a one-shot check at a single point in a deployment pipeline.
Agent policy as code is a continuous runtime check. The policy is evaluated on every action, during a live session, in the critical window between the agent's decision to act and the action's execution. The enforcement point is not "before deploy" but "before each tool call."
Three components are required:
The policy is not "what the agent believes it should do." The policy is what the gate evaluates against. The agent's understanding is irrelevant — the gate's decision is authoritative.
AgenticRail implements policy as code as a two-part contract: the step order and the function/action_type map.
The step order is declared as an ordered list. For an 8-step MSMD spine:
SLP8_STEP_ORDER_MSMD="intake,disruption,instability,state_read,internal_driver,execution,boundary,settle"
This string is the policy. It is stored as an environment variable on the enforcement worker, deployed as part of the worker version, and auditable via the deployment history. Every receipt written by the gate references the key_id of the signing key in effect at decision time — tying the receipt to the policy version that produced it.
The function/action_type map declares which action categories each function permits:
// intake permits state checks — not writes "intake": ["CHECK_STATE", "READ_INPUT"] // execution permits writes and external calls "execution": ["WRITE_DB", "CALL_EXTERNAL_API", "EMIT_EVENT"] // settle permits only finalisation "settle": ["SEAL_SEQUENCE", "WRITE_SUMMARY"]
An agent attempting to call WRITE_DB during intake — regardless of what its prompt or reasoning said was appropriate — receives DENY: ACTION_NOT_ALLOWED before the write executes.
The gate is what separates policy-as-code from policy-as-documentation. Without a gate, you have a policy document. With a gate, you have enforcement.
The gate sits between the agent and every downstream action. The agent does not call tools directly — it calls the gate, which evaluates the declared policy and decides whether the action may proceed. The agent cannot route around the gate; it cannot modify the policy at runtime; it cannot bypass the nonce check or the step order constraint.
The agent is the regulated system. The gate is the regulator. A system cannot regulate itself — the independence of the gate is what makes the policy enforceable rather than advisory.
Every gate decision produces a signed receipt, written before the action executes:
{
"sequence_id": "loan-approval-20260512-001",
"step": "execution",
"function": "execution",
"action_type": "WRITE_DB",
"decision": "ALLOW",
"policy_version": "k1_2026-02-22_01",
"ts_ms": 1715508000000,
"hmac_sig": "sha256=9e2f4b..."
}
When the policy is violated, the gate returns a specific reason code. Each code maps to a distinct policy rule:
Each denial produces a signed receipt — immutable, pre-execution evidence that the policy ran and what it rejected. These receipts are what compliance auditors, EU AI Act Article 9 documentation, and ISO 42001 evidence packages require.
Because the policy is expressed as code — not embedded in a prompt — it has all the properties of code:
| Framework | Requirement | How policy as code satisfies it |
|---|---|---|
| EU AI Act Article 9 | Risk management system — identify, analyse, mitigate risks | Policy contract is the declared risk boundary; gate receipts prove it was enforced |
| EU AI Act Article 12 | Automatic logging enabling reconstruction of events | Pre-execution receipts are the reconstruction anchors — not post-hoc observations |
| ISO/IEC 42001 A.6.1.6 | Controls for AI system operation — documented and evidenced | Policy document + receipt chain = documented control + evidence it ran |
| NIST AI RMF Govern 1.2 | Accountability mechanisms for AI system decisions | Every gate decision attributed to a policy version, signed, and stored immutably |
| OWASP ASI01 (Goal Hijack) | Prevent agent from being redirected to unauthorised objectives | Step order and action type policy enforced externally — prompt injection cannot override |
The industry conversation about policy as code for AI agents tends to stop at declaration. Expressing agent governance as structured configuration rather than prose is valuable — it is readable by tools, comparable across versions, and unambiguous in intent.
But declaration without enforcement is documentation. A policy document does not prevent a non-compliant action from executing. It describes what should happen; it does not guarantee what does happen.
The enforcement gate is what makes the code operative. Without it, "policy as code" is a better way of writing the same unenforceable guidelines that used to live in the system prompt.
Run a sequence through the AgenticRail gate — submit a step out of order and inspect the SEQUENCE_VIOLATION receipt.
Open Demo Read Docs