AI Agent Approval Policy Template

An approval policy defines, in advance, which agent actions pause for human review, who is responsible for reviewing them, how long they have to act, and what happens if they do not. Without a written policy, approval gates get configured inconsistently across workflows, reviewers are uncertain of their role, and SLA breaches go unnoticed.

This template covers four risk levels — low, medium, high, and critical — with a decision table and a ProvenanceOne workflow configuration snippet for each. Fill it in once, review it with your compliance and operations leads, and reference it every time you configure an approval step.

---

When to use this template

• When setting up a new workspace and defining your approval governance before any agents are deployed
• When adding a new high-risk action to an existing workflow
• When a compliance audit asks for documented human-in-the-loop controls
• When an approval.sla_breach event fires and you realise the SLA and escalation path were never formally defined
• When onboarding a new team to ProvenanceOne so they have a starting point for their own policy

---

The blank policy table (copyable)

# Agent Approval Policy

**Workspace:**
**Owner:**
**Last reviewed:**
**Reviewed by:**

## Policy table

| Action category | Risk level | Approval required | Reviewer role | SLA (minutes) | Escalation path | Audit event |
|---|---|---|---|---|---|---|
| | | | | | | |

## Escalation paths

| Risk level | Primary reviewer | Escalation contact | Escalation trigger |
|---|---|---|---|
| low | — | — | — |
| medium | | | SLA breach |
| high | | | SLA breach |
| critical | | | SLA breach or primary reviewer unavailable |

## SLA breach procedure

When `approval.sla_breach` fires:
1. [Action 1]
2. [Action 2]
3. [Action 3]

---

Completed policy table by risk level

Low risk — no approval required, or auto-approve

Low-risk actions have no external side effects and are fully reversible. No approval gate is required. Log the action for audit purposes.

Action category	Risk level	Approval required	Reviewer role	SLA (minutes)	Escalation path	Audit event
Read-only data retrieval	low	No	—	—	—	run.completed
Internal Slack notification	low	No	—	—	—	connection.accessed
Jira ticket creation (unassigned)	low	No	—	—	—	connection.accessed
Knowledge base article retrieval	low	No	—	—	—	run.completed
Draft generation (no send)	low	No	—	—	—	run.completed

Medium risk — single reviewer, 4-hour SLA

Medium-risk actions modify internal records or send communications that are visible outside the immediate team. A single reviewer with a generous SLA is sufficient. The approvers platform group is the default reviewer role.

Action category	Risk level	Approval required	Reviewer role	SLA (minutes)	Escalation path	Audit event
CRM record update	medium	Yes	editor or named assignee	240	Operations manager	approval.granted / approval.rejected
Outbound email send (after draft review)	medium	Yes	CX team lead	240	CX operations manager	approval.granted / approval.rejected
Ticket status change	medium	Yes	editor	240	Engineering manager	approval.granted / approval.rejected
Team notification (external-facing)	medium	Yes	Communications lead	240	Department head	approval.granted / approval.rejected
Lead score update	medium	Yes	Sales operations	240	Sales manager	approval.granted / approval.rejected

High risk — multiple reviewers, 1-hour SLA

High-risk actions affect accounts, reach external audiences at scale, or modify production systems. Require at least two named reviewers. If one reviewer does not respond within the SLA, escalate immediately.

Action category	Risk level	Approval required	Reviewer role	SLA (minutes)	Escalation path	Audit event
Account modification (user data change)	high	Yes — 2 reviewers	Data owner + admin	60	CISO	approval.granted / approval.rejected
Outbound communication to >100 recipients	high	Yes — 2 reviewers	CX lead + Compliance	60	VP Customer Experience	approval.granted / approval.rejected
Supplier or vendor action	high	Yes — 2 reviewers	Procurement + Legal	60	CFO	approval.granted / approval.rejected
Production configuration change	high	Yes — 2 reviewers	Platform lead + admin	60	Engineering director	approval.granted / approval.rejected
Budget approval >$500	high	Yes — 2 reviewers	Finance + department head	60	CFO	approval.granted / approval.rejected

Critical risk — multiple reviewers, secondary sign-off, 30-minute SLA

Critical actions are largely irreversible, financially material, legally binding, or involve regulated data. No agent should take these actions autonomously under any circumstances, even with high trust. Every critical action requires a full approval gate with a short SLA and a named secondary approver.

Action category	Risk level	Approval required	Reviewer role	SLA (minutes)	Escalation path	Audit event
Financial transaction or refund	critical	Yes — 2 reviewers + secondary sign-off	Finance manager + CFO	30	CFO + CEO	approval.granted
Account deletion or suspension	critical	Yes — 2 reviewers + secondary sign-off	Account owner + admin	30	CISO	approval.granted
Legal commitment	critical	Yes — 2 reviewers + secondary sign-off	Legal counsel + signatory	30	General counsel	approval.granted
Access credential change	critical	Yes — 2 reviewers + secondary sign-off	Security engineer + CISO	30	CISO	approval.granted / secret.accessed
Production database write	critical	Yes — 2 reviewers + secondary sign-off	Data owner + Engineering director	30	CTO	approval.granted
Action on regulated data (GDPR-tagged or PII)	critical	Yes — 2 reviewers + secondary sign-off	Data protection officer + admin	30	DPO + Legal	approval.granted / policy.violation

---

SLA breach procedure

When approval.sla_breach fires, the approval has not been actioned within the defined window. The ProvenanceOne platform emits the event and notifies assignees. The approval remains pending — the run does not auto-reject.

Recommended procedure by risk level:

Medium risk breach (240-minute SLA exceeded):

1. The platform notifies all assignees via Slack and email.
2. If no response within 30 minutes of the breach notification, the operations manager is paged.
3. The operations manager either actions the approval or reassigns it to an available reviewer.

High risk breach (60-minute SLA exceeded):

1. The platform notifies all assignees immediately on breach.
2. If no response within 15 minutes, escalate to the department head.
3. Department head actions or escalates to VP level within 15 minutes.
4. If total elapsed time exceeds 90 minutes from breach, the workflow is paused and the incident is logged.

Critical risk breach (30-minute SLA exceeded):

1. The platform notifies all assignees and the CISO immediately on breach.
2. If no response within 10 minutes, page the CISO and secondary approver directly.
3. If total elapsed time exceeds 45 minutes from breach, the workflow run is cancelled and a policy.violation event is emitted.
4. The cancelled run is flagged for post-incident review within 24 hours.

---

ProvenanceOne approval step configuration

YAML config template (copyable)

# Approval step in a workflow definition
approval:
  action: "[Describe the action the agent is about to take]"
  risk: medium          # low | medium | high | critical
  slaMinutes: 240       # 240 for medium, 60 for high, 30 for critical
  assignees:
    - [email protected]
  rationale: "[Why this action requires human review]"
  evidence:
    - label: "[Evidence label]"
      value: "[Evidence value]"
      tone: slate        # slate | amber | red | emerald | blue

Example: bulk email campaign approval

This is a high-risk outbound communication to more than 100 recipients. It requires two reviewers, a 60-minute SLA, and evidence showing the recipient count and content classification.

approval:
  action: "Send campaign email to 5,000 subscribers"
  risk: high
  slaMinutes: 60
  assignees:
    - [email protected]
    - [email protected]
  rationale: "Outbound bulk email — requires review before send"
  evidence:
    - label: "Recipients"
      value: "5,000"
      tone: amber
    - label: "Contains Promotional Content"
      value: "Yes"
      tone: amber
    - label: "Agent Confidence"
      value: "88%"
      tone: emerald

Example: financial refund approval

A critical action with a 30-minute SLA and red-toned evidence to signal urgency and financial materiality.

approval:
  action: "Issue refund of $1,250.00 to customer account ACC-88421"
  risk: critical
  slaMinutes: 30
  assignees:
    - [email protected]
    - [email protected]
  rationale: "Financial transaction above $500 threshold — requires two-person sign-off"
  evidence:
    - label: "Refund Amount"
      value: "$1,250.00"
      tone: red
    - label: "Customer Account"
      value: "ACC-88421"
      tone: slate
    - label: "Original Charge Date"
      value: "2026-04-15"
      tone: slate
    - label: "Agent Confidence"
      value: "94%"
      tone: emerald
    - label: "Dispute Reason"
      value: "Service not delivered"
      tone: amber

Example: low-risk auto-proceed (no approval step)

For low-risk actions, do not insert an approval step. Use a notify step instead so the action is visible without requiring a blocking review.

# notify step (not an approval step)
notify:
  channel: slack
  recipients:
    - "#cx-ops"
  message: "Agent created Jira ticket {{ ticketId }} for inbound request {{ requestId }}"

---

Evidence tone guide

Evidence tones signal the significance of a data point to the reviewer at a glance.

Tone	When to use
slate	Neutral context — identifiers, dates, names
amber	Caution — values that warrant attention but are not alarming
red	High concern — large financial amounts, regulatory flags, error signals
emerald	Positive signal — high confidence, verification passed, clean result
blue	Informational — reference data, links, additional context

---

How to customise this template

Replace the default SLA values with ones that match your organisation's response capacity. A team with 24/7 on-call coverage may set critical SLAs to 15 minutes. A team that operates in a single timezone may set medium SLAs to 480 minutes (8 hours, covering a working day).

Assign named individuals, not just roles. Role-based assignees (such as editor) work for initial setup, but named email addresses ensure the right person is notified and accountable. Update assignees when personnel changes.

Define escalation contacts in the workflow, not just in this document. The escalation procedure in this document is for human coordination. The ProvenanceOne notify step after an approval.sla_breach event should route to the named escalation contacts automatically.

Add organisation-specific categories. If your organisation handles HIPAA-regulated data, add an explicit row for "action on PHI" at the critical level. If you operate in multiple jurisdictions, add rows for jurisdiction-specific compliance requirements.

---

Common mistakes

Setting the same SLA for all risk levels. A 4-hour SLA for a critical financial transaction means a potential 4-hour exposure window. Match SLA tightness to the cost of delay.

Listing the same person as both the primary and escalation contact. If the primary reviewer is unavailable, the escalation path needs a different person.

Not including evidence in approval requests. An approval request that says "Agent wants to send an email — approve?" gives the reviewer nothing to assess. Use the evidence field to provide the data they need to make a real decision.

Treating approval as the only control for critical actions. Approval gates are a human-in-the-loop control, not a security control. For critical actions, combine approval gates with principle-of-least-privilege tool access (see the tool permission matrix) and audit logging.

Leaving slaMinutes unset. If no SLA is configured, the platform has no basis for emitting approval.sla_breach. Define an SLA for every approval step, even if it is generous.

---

---

Related pages

• Tool Permission Matrix — defines which tools require approval and at what risk level
• Risk Assessment Checklist — full deployment risk assessment before an agent goes live
• Approvals — ProvenanceOne approval configuration reference
• Workflows — how approval steps fit into the workflow DAG
• Audit — audit events emitted by approval actions