Skip to content
MINERVA™Studio

A plain-language guide Updated 26 October 2026

Policy as code for AI agents, explained.

How a bank writes down what an AI agent may do, gets a person to decide it, checks it on every call, and keeps the proof.

01 What it is

A control written as a document a machine can check, instead of a paragraph in a policy binder.

Infrastructure teams have written access and deployment rules as code for years. For AI agents the idea matters more: an agent decides in milliseconds and calls tools that move money, change records and reach customers. A rule nobody checks at the moment of the call is only a hope. Policy as code puts the rule in front of every call, and makes the rule itself something a person reviews, approves and can be held to.

02 The five kinds of statement

Permit
The agent may call this tool on this data. Anything not permitted is refused: the policy denies by default.
Forbid
The agent may never do this. A forbid wins over any permit, whatever order they are written in.
Hold
The call waits until a named person with the right role releases it, for example a payment above a limit or a decision about a customer.
Limit
A ceiling on amounts, volume or spend in a session, counted by the runtime.
Escalate
Who is told, and how fast, when the agent drifts, a call is refused or a held call waits too long.

03 What one looks like

An illustrative policy for a mortgage assistant: it may read mortgage files and move money, every transfer waits for a credit officer, no session moves more than 20,000, it may never browse the web, and drift goes to the kill-switch holder and the owner.

{
  "agent": "mortgage-assistant",
  "statements": [
    { "effect": "permit",   "actions": ["documents.read"],    "resources": ["mortgage-files/*"] },
    { "effect": "permit",   "actions": ["payments.transfer"], "resources": ["accounts/*"] },
    { "effect": "hold",     "actions": ["payments.transfer"], "approvers": ["credit_officer"] },
    { "effect": "forbid",   "actions": ["web.*"] },
    { "effect": "limit",    "actions": ["payments.transfer"], "max_per_session": 20000 },
    { "effect": "escalate", "on": "drift", "to": ["kill_switch", "owner"] }
  ]
}

04 From written rule to proof

Written
The policy is a document: statements anyone can read in plain words or as JSON.
Checked
Before it is proposed, it is checked against the agent's registered tools and data, and against the layers above it.
Decided
A named approver decides it. The agent's own developer cannot.
Signed
The decided policy becomes a signed key that names the decision it came from.
Enforced
The gateway or runtime that dispatches the agent's tool calls checks every call against the key before it runs.
Recorded
Every decision (permitted, refused, held, released) is written to a chained, time-stamped record.
Watched
A monitor checks that the key in use is the one decided, and opens an incident on drift.

05 Layers: the regulator, the institution, the vendor

One agent answers to more than one rulebook. A floor set from the guidelines (for example, that payments wait for a person), the institution’s own ceiling (no session above a set amount) and each vendor’s passport (the tools a supplier’s AI declares it uses) all apply at once. Composed, each layer can only take permissions away. The agent’s effective policy is what is left, and that is what gets decided and checked.

Read more: agentic AI governance · third-party AI vendor risk · OSFI E‑23.

In MINERVA Studio, a team writes an agent’s policy in a visual form or as JSON, sees it validated and its effective permissions after every layer, tries a call before anything is decided, and routes it to a named approver. The decision becomes a signed key, and every call the agent makes is kept on a time-stamped record an examiner can verify offline. The policy is enforced by the gateway or runtime that runs the agent; MINERVA writes, decides, signs and records it.

06 Questions people ask

What is policy as code for AI agents?

Writing what an AI agent may do as a machine-checked document (which tools, on which data, within which limits, and which calls need a person) so the gateway or runtime that dispatches the agent's tool calls checks every call against it before it runs, and the policy itself is versioned, reviewed and approved like any other control.

How is policy as code different from AI guardrails?

Guardrails usually filter what a model says: its inputs and outputs. Policy as code governs what an agent does: which tools it may call, on which data, within which limits, and which actions wait for a person. Banks typically need both; only the second stops an agent moving money it should not.

What does deny by default mean?

Anything the policy does not expressly permit is refused. An agent given a new tool cannot use it until someone writes and approves a permit for it.

Who should approve an AI agent's policy?

A named approver who did not build the agent, ideally the role your model risk framework already uses for approvals. The developer may propose; separation of duties means they should not decide.

Does OSFI require policy as code?

No. OSFI's guidelines name no technique. E-23 asks for controls over models that act on their own, and B-10 for control of third-party arrangements; policy as code is one way to make those written controls enforceable on every call and to keep the evidence.

How do regulators' and vendors' rules fit in?

As layers. A floor set from the guidelines, the institution's own ceiling and a vendor's passport each narrow the agent's policy; a layer can only take permissions away, never add them.

What happens when an agent breaks its policy?

The call is refused or held, and the decision is recorded. Repeated refusals, drift from the approved policy or a held call waiting too long open an incident routed to the owner, and a named person can suspend the agent.

What does MINERVA do for policy as code?

MINERVA lets a team write an agent's policy in a visual form or as JSON, validates it, shows the effective permissions after every layer, lets you try a call before it is decided, routes it to a named approver, compiles the decision into a signed key, and keeps every decision on a time-stamped record. The policy is enforced by the gateway or runtime that runs the agent; MINERVA writes, decides, signs and records it.

This page is a plain-language explanation, not legal advice. The example policy is illustrative.

Agentic AI Policy controls as code

A rule nobody checks is only a hope.

A person replies within one working day.