Your AI Agents Need a Policy Document: How to Write Governance Rules Before You Deploy

Two things happened in the last ten days that should change how you think about deploying AI agents.

First: Stanford published CLAUDE.md for their CS336 course — a plain-text file telling AI coding assistants exactly what they are and are not allowed to do when helping students. Not a model card. Not an alignment paper. A short, specific document with hard lines: don’t write code, don’t complete assignments, don’t run bash commands. Do explain concepts, do review student-written code, do ask guiding questions.

Second: Microsoft used Build 2026 to ship the Agent 365 SDK with governance baked in from the first line of code — audit trails, access controls, and policy enforcement that fires while an agent is being designed, not after it misbehaves in production. As one analysis of the announcement put it, Microsoft is now telling its largest customers that capability is table stakes and the thing standing between a pilot and a deployment is control.

These signals are coming from both ends of the market. The message is the same: write the rules before you deploy.

Why This Is Urgent

Agents aren’t tools anymore. Tools produce output and wait for your decision. Agents take action. When they go wrong, they don’t just give you a wrong answer — they send the wrong email, modify the wrong record, or make the wrong API call in a downstream system.

A 2026 survey found that 80% of organizations already report risky behaviors from their deployed AI agents, including unauthorized data access and unexpected system interactions. McKinsey found that 42% of companies have abandoned AI initiatives specifically because of governance failures — not technical failures, governance failures. And Gartner warned this year that applying uniform governance across AI agents will lead to enterprise AI agent failure, because different agents carry fundamentally different risk profiles.

The pattern is consistent: teams that define what an agent can do before it goes live succeed. Teams that figure it out after the first incident don’t always get a second chance.

Anthropic published research this year showing that Claude Code now runs autonomously for over 45 minutes per session on average, up from under 25 minutes three months ago. That trend will continue across all agents, not just coding assistants. The longer an agent runs without human checkpoints, the more consequential your governance decisions become.

What Stanford Actually Did

Stanford’s CLAUDE.md isn’t technically sophisticated. It’s a short markdown file. What makes it notable is the format and the specificity. The course team didn’t trust the AI to infer appropriate behavior from the general context of a coding assignment. They wrote it down. And they distinguished between what the agent should do (explain, guide, review) and what it must not do (write code, complete assignments, edit files).

That distinction — permitted versus prohibited, with explicit examples — is the structure every agent deployment needs.

Most organizations deploying agents in 2026 have some version of an intent: “the agent helps our sales team draft follow-up emails.” What they often lack is the written inverse: “the agent cannot send emails without human review, cannot access contracts, and cannot modify CRM records.” The permitted behavior is obvious from the use case. The prohibited behavior has to be specified.

The Five Sections Your Agent Policy Document Needs

You don’t need a 40-page governance framework to start. You need a document that any engineer or manager on your team can read and act on. Here’s the structure that covers the meaningful ground:

1. Scope: What Is This Agent Allowed to Do?

Define the agent’s job in one sentence. Then list the systems and data sources it can access, and — more importantly — the actions it can take autonomously versus the actions that require a human step.

Example:

• Can access: Salesforce read-only, company knowledge base, shared inboxes (read)
• Can act autonomously: Draft email responses, create task records in project management
• Requires human review: Sending any external email, modifying existing contact records, escalating a case to a manager

The point of this section is to make the implied scope explicit. “Drafting emails” sounds contained. “Sending emails” changes the risk profile entirely.

2. Autonomy Thresholds: When Does It Stop and Ask?

As agents run longer and handle more complex tasks, you need specific triggers that pause execution and surface a decision to a human.

Write these as conditions, not principles:

• If the task will spend more than $X
• If the action would modify a record not touched in the last 90 days
• If the agent encounters a state it wasn’t designed to handle
• If the action affects more than N records at once

These thresholds feel obvious in writing. They are not obvious at runtime. The agent that deletes 300 records “because the task said to clean up duplicates” is an agent that ran without explicit thresholds.

3. Data Access Rules: What Can It See?

Treat agent data access the same way you treat employee data access: least privilege by default.

Which context files and documents does the agent need to do its job? Which categories of data should it never ingest — PII, legal privileged communications, board materials, compensation data? If you’re in healthcare or finance, this section is where your HIPAA and SOC 2 requirements translate into concrete access rules.

This is also where you specify what happens to the data the agent generates. Outputs, conversation logs, cached context — where do they go, how long are they retained, and who can see them?

4. Incident Protocol: What Happens When Something Goes Wrong?

This section exists to answer three questions you don’t want to be asking at 2am:

1. Who gets notified when the agent behaves unexpectedly or fails?
2. How is the agent suspended immediately if something is wrong?
3. What is the rollback procedure for agent-created artifacts — emails sent, records modified, documents generated?

If you don’t have this written down before you need it, you will write it under pressure, in a partial state of information, while the problem is ongoing. Write it now.

5. Review Cadence: When Do the Rules Get Revisited?

Agent behavior changes with model updates. New integrations expand what the agent can reach. Team workflows change what you actually need the agent to do. Put a quarterly review of the policy document on your governance calendar now — the same cycle as your security review or vendor audit.

The policy document isn’t a one-time deliverable. It’s a living document that needs to keep pace with the agent it governs.

Making the Policy Enforceable

A policy that lives only in Notion is a policy that gets ignored the moment something goes wrong. The organizations that govern agents successfully close the gap between the written rules and the technical controls that enforce them.

Four things that make the document operational:

Access controls: If your policy says the agent cannot access HR data, the platform should enforce that — not rely on the agent reading the document and choosing to comply. Permissions should be scoped at the identity layer, not assumed from the prompt.

Audit logs: Every action the agent takes should be logged with enough detail to reconstruct what happened, in what sequence, and why. This isn’t just for incident response — it’s for compliance reviews, vendor audits, and the inevitable “what did the agent actually do?” conversation with a regulator.

Model routing: Different agents carry different risk profiles. A customer-facing support agent doesn’t need the same frontier model as a research summarization agent. Routing agents to appropriate models by risk and cost is a governance decision, not just an optimization.

Structured checkpoints: The autonomy thresholds you define in section two need to be enforced by the platform, not by the agent’s judgment. Interruption logic has to be architectural.

The gap between the written policy and the enforced policy is where most governance failures happen. Teams write good policies and then deploy on platforms that can’t enforce them.

Start This Week

Don’t try to govern your entire agent fleet at once. Start with one agent:

1. Pick the agent with the most access or the most autonomous action rights
2. Spend 30 minutes writing its scope and three things it must never do
3. Verify your platform actually prevents those three things — don’t take it on faith
4. Add one incident protocol step: who gets notified if this agent fails?
5. Put a 90-day review on the calendar

That’s not a governance program. It’s the minimum to avoid being caught without a plan.

The window for “we’re still figuring it out” is closing. Stanford, Microsoft, Gartner, and McKinsey are all pointing to the same gap: governance isn’t what you add after the agent goes live. It’s the gate you install before it does.

If you’re deploying agents and your governance documentation doesn’t exist yet, start with the document. Then make sure your platform can enforce it. Auxot was built to close that gap — governed agents, audit logs, access control, and model routing out of the box. You bring the policy; the platform makes it operational.

Get started at /install or see how it works in /tutorials.