# AI agent governance policy template

Version: [VERSION]  
Policy owner: [ROLE OR NAMED OWNER]  
Approved by: [DECISION AUTHORITY]  
Effective date: [YYYY-MM-DD]  
Next review: [YYYY-MM-DD]

> Replace every bracketed field. Delete guidance that does not apply. This
> operational template is not legal advice and does not assign regulatory risk.

## 1. Purpose and scope

This policy defines how [ORGANIZATION] inventories, authorizes, operates,
monitors, changes and retires AI agents that can access business data or tools.

It applies to:

- [BUSINESS UNITS AND TEAMS]
- [PRODUCTION, TEST AND OTHER ENVIRONMENTS]
- [EMPLOYEES, CONTRACTORS AND SERVICE PROVIDERS]
- [INCLUDED AGENT TYPES]

For this policy, an AI agent is [ORGANIZATION'S TESTABLE DEFINITION]. Systems
that only generate text without tool or data access are [IN SCOPE / OUT OF
SCOPE / COVERED BY ANOTHER POLICY].

Policy questions go to [CONTACT]. Suspected incidents go to [INCIDENT CHANNEL].

## 2. Inventory and ownership

An agent must not enter production until it has one current inventory record
containing:

- business purpose and affected process
- lifecycle state and environment
- named business owner and technical owner
- non-human identity or identities
- models, procedures and policy versions
- connected tools and allowed actions
- data categories and external audiences
- risk tier and maximum autonomous action
- required approvals and escalation owner
- last review, next review and exception expiry

The business owner is accountable for [PURPOSE, PROCEDURE AND OUTCOMES]. The
technical owner is accountable for [DEPLOYMENT, IDENTITY, LOGGING AND RECOVERY].
[ROLE] reassigns or suspends agents whose owner leaves or no longer has the
required authority.

## 3. Risk tier and human approval

[ORGANIZATION] classifies deployed uses by consequence, reversibility, affected
people, data sensitivity and maximum action. A model name does not determine
the tier.

| Tier | Maximum action | Required control | Decision authority |
| --- | --- | --- | --- |
| [0] | [READ OR INTERNAL DRAFT] | [LOGGING AND SAMPLED REVIEW] | [ROLE] |
| [1] | [REVERSIBLE INTERNAL UPDATE] | [SUPERVISED RELEASE / ROLLBACK] | [ROLE] |
| [2] | [EXTERNAL OR CONSEQUENTIAL ACTION] | [BLOCKING APPROVAL] | [ROLE] |
| [3] | [PAYMENT, RIGHTS OR OTHER MATERIAL ACTION] | [PERMANENT / DUAL APPROVAL] | [ROLE] |

Every action above [AUTONOMY LINE] stays pending until an eligible person
reviews the exact proposal and approves, edits or rejects it. An approval
expires after [INTERVAL] and becomes invalid when the proposed payload changes.

## 4. Identity and access

Each production agent uses a distinguishable, managed non-human identity. It
must not borrow a person's session or use a shared login.

The approved permission envelope names:

1. agent identity and delegated principal
2. permitted systems and records
3. permitted read, propose, create, update, send and delete actions
4. permitted fields or data classes
5. required run, purpose, network and approval context
6. issue, expiry and revocation conditions

Access is least-privilege, time-bound where supported and reviewed every
[INTERVAL]. Allowed, denied and approval-required authorization decisions are
logged with the agent identity and policy version.

## 5. Run records and monitoring

Every production run receives a unique run ID. The audit trail records:

- initiator, agent identity and delegated principal
- procedure, model and policy versions
- input and source references
- proposed tool actions and normalized payload references
- authorization decisions and matched rules
- approval requests, exact proposals, reviewer decisions and edits
- executed actions, provider receipts, errors, retries and rollback
- final status and exception owner

Records are retained for [INTERVAL] in [SYSTEM]. Access is limited to [ROLES].
[ROLE] reviews [POLICY DENIALS, OVERRIDES, FAILURES, ACCESS CHANGES AND OTHER
EXCEPTIONS] every [INTERVAL].

Sensitive payloads remain in [AUTHORITATIVE RESTRICTED SYSTEM]; the audit trail
stores [REFERENCE OR HASH]. Audit-record access, export and deletion are logged.

## 6. Incidents and exceptions

[ROLE OR ROLES] may immediately pause an agent or process when [STOP
CONDITIONS]. Pausing prevents new runs, preserves queued work where safe and
revokes [CREDENTIALS OR SCHEDULES].

The manual fallback is [OWNER AND PROCEDURE]. Incident records include affected
runs, observed impact, containment, recovery, notification, root cause and
control changes.

Exceptions must name:

- the exact policy clause
- business reason and affected process
- compensating control
- accountable owner
- approval authority
- start and expiry
- evidence reviewed at renewal

Expired exceptions deny or suspend the affected action; they do not renew
silently.

## 7. Change and retirement

The following are material changes and require review before production:

- a new tool, action type or data category
- a new external audience
- wider record or field scope
- movement of the autonomy line
- changed business purpose or owner
- changed procedure that affects approvals, evidence or recovery
- [ORGANIZATION-SPECIFIC EVENTS]

Retirement disables schedules and entry points, revokes credentials, settles or
transfers queued work, preserves records for the required period and changes
the inventory state to `retired`.

## Policy-to-evidence register

| Policy clause | Enforcement mechanism | Evidence location | Control owner |
| --- | --- | --- | --- |
| Unique agent identity | [DEPLOYMENT OR IAM CONTROL] | [LINK] | [ROLE] |
| Approval above autonomy line | [POLICY OR WORKFLOW CONTROL] | [LINK] | [ROLE] |
| Material change review | [DEPLOYMENT OR CHANGE CONTROL] | [LINK] | [ROLE] |
| Run audit trail | [EVENT OR LOGGING SYSTEM] | [LINK] | [ROLE] |
| Timely retirement | [LIFECYCLE CONTROL] | [LINK] | [ROLE] |

## Awkward-case acceptance test

Before approval, use this policy to decide:

1. An existing read-only agent requests a new state-changing tool.
2. A reviewer rejects an action and gives no alternative.
3. An approval expires while the process is paused.
4. An exception reaches its expiry date.
5. The business owner leaves the organization.
6. A retry follows an ambiguous external-system timeout.

For each case, record who decides, what stops, which fallback runs, and what
evidence remains. Rewrite any clause that does not produce one clear answer.

## Revision history

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | Initial draft | [NAME OR ROLE] |