Policy as code is arriving in AI agent governance, and most of what is being published about it describes 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 issues a signed receipt for each decision.
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 began as a DevOps practice: rules written as code that a machine evaluates, rather than prose a person interprets, so that a change can be checked against policy before it is applied. Policy engines built for that job are mature and widely used, and this page does not compete with them.
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"
That string is the default: it is stored as an environment variable on the enforcement worker and applies only when a request declares no step_order of its own. Whichever order applies, the gate locks it on the first allowed call and signs it into every receipt (step_order), so the record carries the order the step was judged against. A receipt for a step that has its own policy map also carries that map’s identifiers (policy_map_ids, in the receipt metadata), and every receipt names the signing key (key_id). The policy that judged the step is stamped into the receipt of the decision.
The function/action_type map declares which action categories each function permits:
// AgenticRail's production policy for the MSMD spine "intake": ["VALIDATE_INPUT", "CHECK_STATE", "CLARIFY_NEXT_STEP"] "execution": ["SELECT_NEXT_STEP", "PAUSE_CYCLE"] "settle": ["CHECK_STATE", "RECORD_RESULT", "PAUSE_CYCLE", "WAIT_FOR_SIGNAL"]
An agent attempting to call RECORD_RESULT during execution — regardless of what its prompt or reasoning said was appropriate — receives DENY: ACTION_NOT_ALLOWED before the write executes.
The two halves of that contract sit in different places, and it matters which is which. The step order is the caller’s: every request declares its own step_order, and the gate enforces exactly the sequence declared. The action-type map is the enforcement layer’s: the map above is AgenticRail’s production policy for the MSMD spine. A sequence declaring custom step names is evaluated against one fixed set of action types — CHECK_STATE, CLARIFY_NEXT_STEP, SELECT_NEXT_STEP, RECORD_RESULT, WAIT_FOR_SIGNAL, VALIDATE_INPUT, PAUSE_CYCLE, REDUCE_STIMULUS — rather than a per-step map of its own, so that check does not constrain a custom sequence — what binds it is the declared order, replay, freshness, sealing and chain integrity. Its receipts name the rule set that judged them, policy_generic_custom_v1, so the record says which applied rather than leaving it blank. A caller-supplied action-type map is deliberately not accepted: holding a customer's policy would make this a configured, versioned part of their system rather than something independent of it, and policy engines are a well-served category already. This is sequence enforcement, and the policy referred to throughout this page is the enforcement layer's own.
That policy carries a sharper rule worth copying: the execution step (the doer) permits only SELECT_NEXT_STEP and PAUSE_CYCLE — it cannot record its own results. Witnessing happens at the following step (boundary), and a result recorded there must carry a verifiable link to the receipt of the work it attests to, or it is denied (ARTIFACT_UNBOUND). The doer cannot self-attest; that separation is policy, enforced.
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 the downstream action. In the integration this requires, the agent does not call tools directly — it calls the gate, which evaluates the declared policy and decides whether the action may proceed, and the system runs the action only on ALLOW. Within that integration the agent cannot modify the policy at runtime, and it cannot bypass the nonce check or the step order constraint. What the gate cannot do is govern a call that never reaches it: keeping every consequential tool behind the gate is the integration’s job, and a step taken around the gate leaves no receipt — which is itself what the chain shows missing.
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, issued before the action executes:
{
"pack_id": "24449424694a3f...e020", // SHA-256, 64 hex
"decision": "ALLOW",
"reasons": [],
"executed": true, // permitted — not proof the downstream action performed
"sealed": false,
"meta": {
"model_id": "client:acme-bank",
"sequence_id": "loan-approval-20261008-001",
"step": "execution",
"function": "execution",
"action_type": "SELECT_NEXT_STEP",
"policy_map_ids": ["policy_execution_clear_entry", "policy_execution_direction_change_test"]
},
"payload_hash": "9080bd2ac4da...86cb",
"prev_receipt_id": "5d0c71e2a9f4...7b13",
"prev_receipt_hash": "b6a18d234e38...338d",
"step_order": ["intake", "disruption", "instability", "state_read", "internal_driver", "execution", "boundary", "settle"], // the order this step was judged against
"ts_ms": 1791417600000, // asserted by the caller, bounded by the gate's clock
"key_id": "k2_2026-06-07_ed25519",
"signature_alg": "Ed25519",
"signature": "TpQr8f3aXz9c2b1d..." // base64, over the canonical receipt
}
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 — tamper-evident evidence, issued before execution, that the policy ran and what it rejected. These receipts are the operational exhibits that compliance auditors, EU AI Act documentation, and ISO 42001 evidence packages cite.
Because the policy is expressed as code — not embedded in a prompt — it has all the properties of code:
step_order), the identifiers of the action-type map that applied (policy_map_ids), and the signing key (key_id). An auditor reading a sequence’s receipts can see which policy judged each decision.| Framework | Requirement | What policy as code evidences |
|---|---|---|
| EU AI Act Article 9 | Risk management system — identify, analyse, mitigate risks | The declared risk boundary plus proof it was enforced — the evidenced core of a risk management system, not the whole system |
| EU AI Act Article 12 | Logging capabilities that record events relevant to identifying risk, post-market monitoring and monitoring operation | A receipt issued at each decision, before the step runs, for permits as much as refusals — a record of the control operating, not a post-hoc observation |
| ISO/IEC 42001 A.6.2.8 | AI system recording of event logs — determine at which phases of the life cycle event logging is enabled | A signed event record of every gate decision, during operation, chained so that any later alteration is detectable |
| NIST AI RMF Manage 2.4 | Mechanisms in place to supersede, disengage or deactivate an AI system whose outcomes are inconsistent with intended use | A mechanism applied at every step: an action outside the declared order or the permitted action types is refused before it runs, and the refusal is signed |
| OWASP ASI01 (Goal Hijack) | Prevent agent from being redirected to unauthorised objectives | Step order and action type policy evaluated outside the agent — a prompt injection can change what the agent attempts, not what the gate permits |
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