Start from decisions, not principles. A workable AI agent governance policy names who approves an agent, what every agent must prove before it acts, what no agent may ever do, and what record each step leaves. Write each clause so an auditor could find evidence it was followed. Then test the draft on one real agent before you publish it.
What should the policy cover, and what should it leave out?
The policy governs the organisation's agents as a class. It sets decision rights, the lifecycle, the floor, and the evidence. It does not describe any single agent's job; that belongs in each agent's own brief and policy, which our guide on how to write an AI agent policy covers.
Leave out model selection, prompt style and vendor preferences. Those change often and belong in standards beneath the policy. If a clause would need rewriting every time a model changes, it is in the wrong document.
Who does what in writing it?
- Accountable executive: sponsors and owns the policy. One named senior person, not a committee. Evidence: the ownership line on the policy and their sign-off.
- Risk and operations: define what counts as an agent. The useful line is action. Software that only answers questions is covered by general AI policy; software that reads, drafts, changes or pays inside your systems is an agent. Evidence: the definition and a first inventory against it.
- Policy owner: set decision rights. Who proposes an agent, who approves it for production, who may raise its depth, who may switch it off. Evidence: a decision-rights table in the policy.
- Operations and risk: write the lifecycle. Register, qualify, test on real cases, start at low depth, widen on evidence, recertify on a fixed cycle, retire. Evidence: the lifecycle stages and the record each produces.
- Risk: write the floor. Actions no agent may take regardless of performance, and the limits a business unit may set more tightly. Evidence: the list, with a reason for each item.
- Internal audit: review for testability. For each clause, ask what evidence would show compliance. Rewrite any clause that has no answer. Evidence: audit's review notes.
- Board or risk committee: approve. Evidence: the minute.
What does a decision-rights table look like?
| Decision | Proposes | Approves | Record |
|---|---|---|---|
| Deploy a new agent | Process owner | Risk and the accountable executive | Approval with test results attached |
| Raise an agent's depth | Process owner | Risk, on certification evidence | Certification record |
| Add a source or credential | Process owner | Security and risk | Change log entry |
| Grant a temporary exception | Process owner | Risk, with an expiry date | Exception register |
| Switch an agent off | Anyone on the team | No approval needed | Incident or change record |
The last row matters. Stopping an agent should be easy and unilateral. Starting one should not.
How do you test the draft before publishing?
Take one agent already in use, or one about to launch, and run it through the policy as written. Can you produce each record the policy demands? Does every approval have a named person? Do the floor items map to controls that actually refuse the action?
Take a payments company drafting its first policy. It walks its reconciliation agent through the draft and finds three gaps. The policy says held actions go to "an appropriate approver", which names nobody. It says certificates are reviewed "periodically", which no auditor can test. And it has no clause for approver absence, so held items would sit with someone on leave. Each gap gets a concrete rewrite before the policy goes to committee.
What mistakes make a policy unenforceable?
- Principles without mechanisms. "Agents will be fair and transparent" is a value. "Every refusal to a customer carries a stated reason drawn from the refusal library" is a control.
- Relying on the model's own restraint. A model's built-in filters are not decision rights; see guardrails are not governance.
- No expiry. Approvals, exceptions and certificates without end dates become permanent by default.
- No link to the record. If the policy demands decisions be explainable but nothing files them, it cannot be met.
A template helps with layout. The AI agent policy template gives fields you can adapt, but the decision rights have to be yours.
Where Pryme fits
Pryme gives a policy something to point at. An agent's certified depth and the depth each action needs, certificates that lapse after 90 days, five bounds checked at the moment of action, and every verdict filed in an append-only record are concrete mechanisms a clause can name. The policy still decides who approves what; the platform enforces and records it. Background is in our guide to agent governance and what AI agent governance means.
Questions people ask
How long should the policy be?
Short enough that a process owner reads it. Many organisations keep the policy to a few pages and put detail in standards and procedures beneath it.
Should the policy differ by business unit?
The policy should not. Business units set their own limits within it, tighter where their risk is higher, and record those limits as their own.
How often should it be reviewed?
At least annually, and after any significant agent incident. An incident that the policy did not anticipate is the best evidence of what to add.