How to write an AI agent policy

Every rule in the policy should be enforceable and checkable. A usable AI agent policy says what counts as an agent, who owns each one, how capabilities and depths are approved, what no agent may do, when people must approve, and how agents are recorded, changed and stopped. Beside every rule, name its control and evidence.

What is an AI agent policy, and who owns it?

An AI agent policy is the firm's rulebook for software that acts. It differs from a general AI policy, which often focuses on staff using chat tools, and from an agent's brief, which tells one agent how to do one job. The policy sits above both: it sets the rules every agent and every agent owner must follow.

A senior executive owns it, usually the chief operating officer or chief risk officer. A small drafting group writes it: agent operations, risk, compliance, security, data protection and legal. The executive committee or board approves it. The difference between this policy and wider governance documents is discussed in how do you write an AI agent governance policy?

What should the policy cover?

• Scope: what counts as an agent, including vendor agents and agents embedded in other products.
• Roles: policy owner, agent sponsors, approvers, agent operations, risk.
• Registration: no agent acts without an inventory entry and its own identity.
• Classification: how agents are tiered by risk, and what each tier requires.
• Capabilities and depth: approval per agent, at a depth backed by evidence, with expiry.
• Prohibited actions: the firm-wide list no agent may take.
• Data: what agents may see, keep and send outside.
• Human approval: when actions must be held for a named person.
• Transparency: telling people when they deal with an AI system. For EU-facing services, Article 50 of the EU AI Act applies; see Article 50 and AI agents that write to customers on your behalf.
• Change, incidents and suspension: how agents are changed, how problems are reported, who may stop an agent.
• Records: what is recorded, for how long, and who may see it.
• Review: how often the policy is reviewed and by whom.

What are the steps, and who acts at each one?

1. Person, policy owner: commissions the policy and names the drafting group.
2. Agent, depth 1: maps the current state, listing agents in use, existing related policies and controls already in place.
3. Agent, depth 2: drafts sections from the drafting group's decisions and existing policy language. The group edits every section.
4. Person, drafting group: maps each rule to a control and its evidence. A rule with no control is either removed or flagged as a gap with an owner and date.
5. Person, legal and data protection: review for regulatory alignment in each market the firm operates in.
6. Person, business owners: are consulted on whether rules are workable.
7. Person, executive committee: approves the policy.
8. Person, agent operations: publishes and trains, and updates templates for briefs, approvals and charters to match.
9. Person, policy owner: reviews yearly and after significant incidents or rule changes.

What evidence does each step leave?

The commissioning memo; the current-state map; drafts with tracked edits; the rule-to-control map with gaps; legal and data protection notes; consultation comments and responses; the approval minute; training records and updated templates; and dated review records. The rule-to-control map is the most valuable of these, because auditors will test the policy through it.

How do policy, acceptable use and briefs fit together?

Three documents, three audiences. The agent policy binds the firm and agent owners. An acceptable use policy tells staff how they may use agents in their work; the acceptable use policy template for staff using AI agents is a starting point. Each agent's brief tells that agent its role, sources and limits; how do you write a brief for an AI agent? covers it. The policy should require briefs and acceptable use rules, not repeat them.

Which controls make the policy real?

Registration enforced by access. No inventory entry, no identity.

Approvals in the workflow. Capabilities cannot go live without the recorded approval the policy requires.

Prohibited actions encoded. The never-list is in every agent's scope, not only in the document.

Records kept automatically. The policy's record requirements are met by the platform, not by manual logs.

What should you measure?

Rules with a working control, gaps open past their date, agents operating outside policy found by reconciliation, exceptions granted and expired, and staff trained. Measure the policy by how much of it is enforced, not by how complete it reads.

Where does it usually go wrong?

It reads well and binds nothing. Rules such as "agents must act ethically" cannot be enforced or tested. Write rules a control can check.

It copies a template wholesale. A policy written for a different firm describes roles you do not have. Use the AI agent policy template for structure, not content.

It is too long to use. Agent owners cannot find what applies to them. Keep the policy short and put detail in standards and templates.

It ignores vendor agents. Agents embedded in purchased software act on your data too.

Where Pryme fits

In Pryme, policy rules such as the depth each action needs, held actions, prohibited actions and record-keeping become bounds checked at the moment of action, so the policy's controls produce evidence as agents work. See agent governance is a bound, not a model.