← Back to blog AI Safety

How to Write Policies for Autonomous AI Agents (Plain English Guide)

Sep 7, 2026 · 7 min read · AnterisLab Team

Most teams write their first agent policy the wrong way: as a 40-page compliance document nobody reads, or as a YAML config file nobody understands. Both fail for the same reason — the people who know the business rules can't read the policy, and the people who can read it don't know the business rules.

The fix is simpler than you'd expect: write policies in plain English. Not because it's trendy, but because a policy your product manager can read is a policy your product manager will actually maintain.

Why plain language beats config files

A policy engine's job is to translate intent into enforcement. If your policy is already written in the language of intent — English — the translation is direct and auditable. If it's written in YAML, you've added a lossy translation layer maintained by whoever wrote the config.

Compare these two expressions of the same rule:

The second version can be read by your CEO, your lawyer, and your on-call engineer. When something goes wrong at 3am, the person debugging can read the rule that fired and understand it immediately. That's not a nicety — it's the difference between a 5-minute fix and a 5-hour investigation.

The 4 policy types every team needs

After reviewing hundreds of agent deployments, we've found that nearly every useful policy falls into one of four types. Start with these four and you'll cover the vast majority of real incidents.

1. Rate limits

Cap how often an action can happen. This is your first line of defense against runaway loops and budget burn.

2. Value thresholds

Block or pause any action above a monetary or volume threshold. This catches the expensive mistakes before they're expensive.

3. Scope boundaries

Restrict which resources an agent can touch. This prevents scope creep — the slow drift from "send email" to "send email to everyone".

4. Time windows

Restrict when actions can happen. High-risk operations rarely need to run at 3am on a Sunday.

The 3 mistakes that cause real incidents

• Writing policies after the incident. Teams wait until something breaks. Your audit trail tells you exactly where the boundaries should be — read it before the incident, not after.
• Policies with no owner. A policy nobody owns is a policy nobody updates when the business changes. Every policy needs a named owner who reviews it quarterly.
• Warn-only mode left on forever. A guardrail that only warns is a suggestion. Run warn-only for two weeks to tune thresholds, then switch to enforce. Teams that stay in warn-only get zero protection and full alert fatigue.

Test your policies before you deploy them

A policy is code. Treat it like code: test it before it ships. The fastest way is to replay your last 7 days of agent actions against the new policy in warn-only mode and read the report. You're looking for two things:

• False positives: legitimate actions the policy would have blocked. If there are many, your thresholds are too tight.
• True positives: actions the policy would have blocked that you agree should be blocked. These are your incidents-that-almost-weren't.

If the replay shows zero true positives, your policy is probably too loose. If it shows hundreds of false positives, it's too tight. Tune until the report matches your intuition about what should be blocked.

The bottom line

Write policies in the language your business speaks. Start with the four types — rate limits, value thresholds, scope boundaries, time windows. Give every policy an owner. Test in warn-only, then enforce. That's the entire discipline. Everything else is detail.

Teams that follow this pattern ship autonomous agents with confidence, because they can answer the only question that matters: "what is this agent not allowed to do?" — in one sentence, in plain English, right now.