# AI Agent Approval Workflow Playbook

Version: 1.0
Published: 2026-07-28
Owner:

Use this playbook to define when one AI-agent action can proceed, needs review, or must stop. Copy
it into your control repository, ticket system, or operating procedure and complete every field.

This is general implementation guidance. Confirm applicable legal, regulatory, contractual, and
sector requirements for the system and action.

## 1. Scope one consequential action

- Agent:
- Accountable owner:
- Requesting principal:
- Action:
- Tool and destination:
- Business purpose:
- Environment:
- Data Boundary:
- People or systems affected:
- Expected downstream effect:
- Maximum rate or aggregate exposure:
- Applicable laws, contracts, and internal controls:

## 2. Define the decision precedence

When several rules match, the strongest result wins:

1. `block`
2. `require_approval`
3. `warn`
4. `allow`

| Outcome | Execution behavior | Rule for this action |
| --- | --- | --- |
| `allow` | Execute inside current authority and record the ordinary decision. | |
| `warn` | Execute, record the signal, and create the defined follow-up. | |
| `require_approval` | Hold the exact request until an eligible reviewer decides before expiry. | |
| `block` | Stop before the governed side effect and record the reason. | |

Never treat a missing policy result, unavailable identity source, expired request, or evidence-write
failure as implicit approval.

## 3. Map the approval inputs

For every input, define testable allow, warn, require-approval, and block conditions. Use concrete
values, destinations, data classes, and reason codes.

| Input | Allow | Warn | Require approval | Block |
| --- | --- | --- | --- | --- |
| Risk and affected rights | | | | |
| Amount or aggregate exposure | | | | |
| Reversibility or compensation cost | | | | |
| Data sensitivity, purpose, and region | | | | |
| Novel Release, tool, destination, or sequence | | | | |
| Confidence, evidence completeness, and freshness | | | | |
| Downstream legal, financial, safety, or operational effect | | | | |

### Explicit exceptions

- Conditions that can never be approved:
- Break-glass action classes:
- Break-glass authority:
- Maximum break-glass duration:
- Required retrospective reviewer:
- Required incident or change reference:

## 4. Choose the oversight arrangement

Select one primary arrangement and document the acceptance test.

- [ ] Human in the loop: a person decides on this action before the side effect.
- [ ] Human on the loop: a person monitors bounded execution and can intervene within:
- [ ] Human in command: the named owner can change authority, stop, recover, and commission review.

Acceptance test:

## 5. Define maker-checker separation

### Maker side

- Agent identity:
- Accountable owner:
- Requesting principal:
- Service identity:
- Maximum maker authority:

### Checker side

- Required role:
- Minimum competence:
- Required training:
- Maximum checker authority:
- Conflicts that disqualify a checker:
- Can the requester or sponsor check this request? Yes / No
- Two-person rule conditions:

### Enforcement

- Identity source checked at decision time:
- Role and delegation source:
- Requester-checker comparison:
- Action and parameter binding method:
- Evidence-package binding method:
- Revalidation before execution:

## 6. Build the reviewer context package

- [ ] Short narrative: proposed action, reason for review, open uncertainty, requested decision
- [ ] Exact action, target, amount, material parameters, and downstream systems
- [ ] Requesting principal, agent, accountable owner, and required checker role
- [ ] Policy outcome, version, matched rules, reason codes, and evaluated values
- [ ] Source evidence, freshness, missing facts, conflicts, and limitations
- [ ] Confidence or uncertainty when it affects routing
- [ ] Alternatives available to the reviewer
- [ ] Expiry, response target, escalation route, and current assignee
- [ ] Reversal, compensation, and safe-state procedure

Presented-evidence digest or immutable reference:

## 7. Set the service level and expiry

- Requested at:
- Response target:
- Escalate at:
- Expires at:
- Early-expiry triggers:
- Safe state at expiry:
- Replacement role:
- Reassignment rule:
- Delegation scope and end time:
- Queue-unavailable behavior:

Expiry invalidates approval authority. Re-evaluate the action and issue a new request before any
execution.

## 8. Define reviewer actions

| Reviewer action | Required reason | Resulting system state |
| --- | --- | --- |
| Approve | | |
| Reject | | |
| Request changes | | |
| Escalate | | |
| Invoke emergency stop | | |

No decision is complete until the record contains reviewer identity, authority snapshot, outcome,
reason, rationale reference, evidence digest, and decision time.

## 9. Define override, appeal, and emergency-stop paths

### Override

- Permitted action classes:
- Required authority:
- Two-person rule:
- Maximum duration:
- Required reason and evidence:
- Resulting action binding:

### Appeal

- Who can appeal:
- Appeal reviewer:
- Independence rule:
- Safe interim state:
- Response target:
- Notification and remedy:

### Emergency stop

- Authorized operators:
- Stop scope:
- Worker and queue propagation:
- Tool-call and retry behavior:
- Credential or lease action:
- Downstream reconciliation:
- Declared safe state:
- Restart approver:

## 10. Record minimum evidence

Use the public KLA AI Agent Audit Log Schema:

- Reference page: https://kla.digital/resources/ai-agent-audit-log-schema
- JSON Schema: https://kla.digital/ai-agent-audit-event/v1/schema.json
- Complete example:
  https://kla.digital/ai-agent-audit-event/v1/examples/complete-execution.json

Required record groups:

- [ ] Stable event, correlation, execution, and lineage identifiers
- [ ] Organisation, environment, retention, and privacy handling
- [ ] Requester, agent, service identity, accountable owner, and versioned components
- [ ] Exact action, purpose, resource, destination, amount, and arguments digest
- [ ] Policy ID and version, outcome, matched rules, reasons, inputs digest, and decision time
- [ ] Decision Request, expiry, required role, evidence digest, reviewer, decision, and rationale
- [ ] Tool receipt, idempotency key, result digest, and downstream effects
- [ ] Business outcome, rollback or incident reference, and unresolved residue
- [ ] Evidence manifest, artifact digests, record hash, signature, and verification result

## 11. Test the failure paths

- [ ] Reviewer is unavailable
- [ ] No eligible replacement exists
- [ ] Request expires
- [ ] Request is reassigned
- [ ] Requester attempts self-approval
- [ ] Amount, destination, evidence, or policy changes after approval
- [ ] Approval is replayed
- [ ] Execution retry arrives after success
- [ ] Required evidence cannot be written
- [ ] Tool succeeds but downstream confirmation is missing
- [ ] One step in a multi-system action fails
- [ ] Emergency stop leaves work in flight
- [ ] Recovery begins without current approval

For each test, record expected state, observed state, evidence reference, owner, and remediation date.

## 12. Worked control record

- Action:
- Policy outcome:
- Matched rule and reason:
- Decision Request:
- Evidence shown:
- Required role:
- Requested at:
- Expires at:
- Reassigned from:
- Reviewer:
- Decision and reason:
- Decided at:
- Execution started at:
- Tool receipt:
- Downstream effect:
- Business outcome:
- Lineage record:
- Integrity verification:
- Exceptions or residue:

## 13. Sign-off

- Control owner:
- Risk owner:
- Technical owner:
- Operations owner:
- Approved policy version:
- Effective date:
- Next review:
- Drill date:
- Evidence location: