What is policy as code for AI?
Policy as code for AI is the practice of writing agent authorization rules as declarative, version-controlled files that a runtime engine evaluates against each tool call. The rules live in your repo. They get reviewed in PRs. They move with the rest of the application. There is no separate place to look for what the agent is allowed to do.
Key facts
- Rules are declarative, machine-readable, and human-reviewable: typically YAML or a similar format.
- Used by teams who need agent policy to be reviewable, testable, and auditable like the rest of their code.
- Without it, agent policy lives in workspaces, prompts, or scattered if/else statements that nobody can review consistently.
- Veto's policy format is YAML, lives in your repo, and is enforced by an in-process engine.
In plain English
Teams start with agent policy as imperative code: if (args.amount > 500) throw new Error("too big") scattered through tool implementations. That works until the team grows past one person, the rules multiply, and nobody knows which file holds the actual policy. Policy as code says: put it in one declarative file, give it a clear schema, treat it like configuration.
The benefit shows up in code review. A new rule is a small, readable diff. A deleted rule is a small, traceable diff. A wrong rule can be reverted with git revert. The infrastructure-as-code movement won this argument a decade ago for AWS; the same logic applies to AI agent authorization.
How it works
A Veto policy file is a list of rules. Each rule has a match block (which tool, which agent, which event) and a list of conditions with outcomes. The engine evaluates rules in order on each tool call and returns the first matching outcome: allow, deny, or require_approval.
The file lives with the application. CI can run schema validation on policy PRs. Shadow mode lets you observe a new policy in production without enforcing it. Declarative format, schema validation, shadow rollout, and a decision record keyed to git commits make the rules trustworthy enough to rely on.
# veto/policy.yaml: checked into the repo
- name: refunds_have_a_ceiling
match:
tool: refund_order
rules:
- if: args.amount_cents > 50000
then: require_approval
- name: prod_database_writes_blocked_during_freeze
match:
tool: db.write
rules:
- if: context.env == "prod" and context.freeze_active
then: denyOperational consequence
A policy nobody can find is a policy nobody can enforce. When agent rules live in a workspace, a few people know they exist; when they live in imperative code, only the authors know they exist. Policy as code makes the rules a first-class artifact that the rest of the engineering culture already knows how to handle.
Audits ask for this directly. SOC 2, ISO 27001, and EU AI Act reviews often ask the same kind of question: show me the controls, show me the changes, show me who approved them. Policy as code gives reviewers one file, one commit history, and one set of code-review records to inspect. The alternative, taking screenshots of workspaces or grepping through prompts, does not scale and leaves auditors asking for stronger evidence.
Related terms
FAQ
Why YAML and not a workspace?⌄
Both, but YAML is the reviewed artifact. A workspace helps with controlled edits. YAML is what survives team turnover, code review, and audit. A policy that lives only in a UI can drift outside review unless the system records changes.
Is this the same as Open Policy Agent?⌄
Same idea, different surface. OPA pioneered policy as code for infrastructure with Rego. Veto specializes the pattern for AI agent runtime: tool calls, agent identities, argument-aware rules, and human approval as a first-class outcome. You can use OPA alongside Veto; teams often do.
How do I test a policy before deploying it?⌄
Shadow mode. The same policy file runs against live traffic but only logs decisions instead of enforcing them. You see what would have been allowed, denied, or escalated. Once the numbers look right, you flip the switch. This is also the answer to the 'will this break my agent?' question.
What does the decision record look like?⌄
Governed decisions can be recorded with the policy snapshot, the rule that matched, the input arguments, the agent identity, and the outcome. Combined with git history on the policy file, you can answer 'what was the rule on Tuesday at 3pm?' which is the question auditors ask.
Move your agent policy into the repo.