How to write, test, enforce and prove the rules that decide what every AI agent may do, one tool call at a time.
In my last article, Identity as Code, we gave every AI agent a file that says who it is, who owns it and what it exists to do. That answers who is acting. It does not answer the harder question: should this specific action happen right now?
That is the job of Policy as Code. Most organizations already have rules for their agents, but those rules live in documents and system prompts while the agents act in milliseconds.
In this article, you will learn:
The gap: why written policies and system prompts cannot control agents
The concept: what Policy as Code means and how a policy decision works
The enforcement point: where policies must run so the agent cannot get around them
The practices: seven practices for writing, testing and changing agent policies safely
The first steps: how to start in any organization
1. Why Written Policies Cannot Control Agents
A policy nobody can enforce is not a control. It is a hope with a version number.
Kiteworks surveyed 225 security, IT and risk leaders across 10 industries for its 2026 Data Security and Compliance Risk Forecast Report:
Agents are already here: 51% already have agents in production.
Rules without enforcement: 63% cannot enforce purpose limits on what their agents are authorized to do.
No way to stop them: 60% cannot terminate a misbehaving agent.
No proof: 33% lack evidence-quality audit trails entirely.
The pattern is familiar. A policy says the agent may not send customer data outside the firm, and the system prompt repeats it. Then a prompt injection hidden in an email tells the agent to ignore its instructions, and nothing outside the model says no.
Rules written for people and pasted into prompts will never be strong enough to govern software that acts on its own.
2. What Policy as Code Means
When a rule is written as code, it can be reviewed, tested, versioned and enforced the same way every single time.
Policy as Code means writing the rules that govern agents in a machine-readable language, keeping them in version control, testing them like software and enforcing them through a policy engine that sits outside the model. The model can propose any action it likes. The policy engine decides.
The anatomy of a policy decision
Before every tool call, the runtime sends the policy engine a request with five inputs:
The person: the human who started the task and whose authority the agent borrows.
The agent: the identity from its Identity as Code file, including its risk tier and owner.
The tool: what the agent wants to call, such as a payment, a database update or an email.
The arguments: the details, such as the amount, the recipient or the data classification.
The context: time, location, the task's running totals and any open approvals.
The engine returns one of three answers: allow, deny or route to a named human, always with a reason.
The four points of a policy architecture
This design has a well-established blueprint. The XACML standard defined four components two decades ago, and modern policy engines still follow the same split:
Policy Administration Point (PAP): the repository and pipeline where policies are written, reviewed, tested, versioned and published to the decision point.
Policy Enforcement Point (PEP): the gateway that intercepts every tool call, asks for a decision and enforces it. It blocks or allows, but never decides.
Policy Information Point (PIP): the sources that supply facts the request does not carry, such as the user's current role, the data's classification, the agent's risk tier or the task's running totals.
Policy Decision Point (PDP): the policy engine that evaluates the request against the rules and returns allow, deny or escalate, with a reason.
An easy way to remember the flow: the PAP writes the rules, the PEP catches the request, the PIP adds the facts and the PDP makes the call. Keeping the four separate is what makes the design trustworthy. The agent can reach the enforcement point, but it can never change the decision point or the rules behind it.
Four kinds of rules agents need
Access rules: which tools and data this agent may ever touch.
Limit rules: amounts, data classes, destinations and time windows.
Escalation rules: which actions need a human to approve them first.
Sequence rules: limits on the whole task, so one large payment or data export cannot be split into many small ones.
The languages
OPA and Rego: a general-purpose, open source policy engine widely used in cloud and platform teams.
Cedar: an open source language built specifically for authorization, whose specification is formally verified, and which joined the CNCF as a Sandbox project in early 2026.
The model may propose anything it likes. Only a tested, versioned policy should decide what actually happens.
3. Where Policies Must Run
If the agent can reach the tool without passing the policy, the policy does not exist.
The Policy Enforcement Point belongs in a gateway between the agent and every tool it can call, never inside the agent's own code or prompt.
Design principles for the enforcement point
Deny by default: no tool is available until a policy explicitly allows it.
Forbid wins: when one rule allows an action and another forbids it, the action is blocked.
Fail closed: if the policy engine is unreachable, high-impact actions stop rather than proceed unchecked.
Hide what is never allowed: tools the agent can never use should not even appear in its list, so it cannot be talked into trying them.
Defense in depth: sensitive systems run their own check too, so a compromised runtime cannot approve itself.
The platforms are moving this way
Amazon Bedrock AgentCore Policy: generally available since March 2026, it checks every tool call at a gateway, denies by default, and converts plain-language rules into Cedar, then validates them.
Microsoft Agent Governance Toolkit: released as open source in April 2026, it intercepts agent actions before they run and supports YAML rules, Rego and Cedar.
Put the policy between the agent and the world, and even a manipulated agent can only ask. It can never simply act.
4. Seven Practices for Managing Agent Policies
Policies change as often as the business does, so they need the same discipline as any other production code.
These practices are what turn the Policy Administration Point from a folder of rules into a controlled release process.
Translate obligations into rules with owners: risk, compliance or legal states the intent, engineers turn it into code, and both sign off.
Review through pull requests: no policy reaches production without a reviewer, a reason and a record.
Test both directions: prove the agent can do what it needs and is blocked from what it must never do.Every incident becomes a test case.
Analyze before you deploy: automated analysis can flag contradictory rules, rules that allow everything, and whether a new version is more permissive than the last.
Run in shadow mode first: log what a new policy would have blocked on live traffic before it enforces anything.
Log every decision with its version: record the person, the agent, the tool, the decision, the reason and the policy version, so you can prove which rule was in force when an action happened.
Review policies when anything changes: a new model, a new tool or a new regulation should trigger a policy review, just as it triggers an identity review.
A word on writing policies in plain language
Letting AI draft a policy from a plain-language description is a real productivity gain. But the AI that drafts the rule must never be the one that approves it:validation, tests and a human reviewer still stand between the draft and production.
Every rule an agent obeys should be traceable to a requirement, a test, a reviewer and a version.
5. Getting Started in Any Organization
Begin with the actions that would keep you awake at night, and write the rules for those first.
This works whether the agent approves refunds at a retailer, updates patient records at a hospital or prepares payments at a bank.
List the high-impact actions: moving money, changing records, deleting data and sending information outside the organization.
Write the first ten rules: cover those actions with clear limits and escalation paths.
Start in shadow mode: learn what the rules would block before they block anything.
Enforce for one agent: turn on deny by default for your highest-risk agent.
Connect the decision logs: send them to the teams who answer to auditors and regulators.
Turn success into templates: reuse proven policy sets for every new agent of the same type.
You do not need a perfect rulebook to begin. You need ten good rules running in front of the riskiest agent.
Key Takeaways
Identity tells you who the agent is. Policy decides what it may do, every single time.
Written rules are not controls: most organizations cannot yet enforce purpose limits or stop a misbehaving agent.
Policy as Code makes rules executable: versioned, tested and enforced by an engine outside the model.
Four points, four jobs: the enforcement point blocks, the decision point decides, the information point supplies facts and the administration point governs the rules.
Enforcement belongs at the gateway: deny by default, forbid wins, fail closed and hide what is never allowed.
Seven practices keep policies trustworthy: owners, reviews, tests, analysis, shadow mode, versioned logs and reviews on change.
Start with ten rules: cover the riskiest actions for the riskiest agent, then scale.
When every agent action passes through tested, versioned policy, autonomy stops being a risk you accept and becomes a capability you can prove.
Where do your agent rules live today: in a policy document, a system prompt, or in code that runs before every action? Share your experience below.
This is Part 2 of the five-part series Governing AI Agents as Code. Previous: Identity as Code. Next: Configuration as Code.
Explore more: Start Here · Topics · Archive · About