AIAgentsApprovalAutomation

Technical guide: AI agent budget and approval workflow

This guide supports [Give an AI agent a budget, not a blank check](./2026-08-31-ai-agent-budget-not-blank-check.md). It describes a small implementation pattern for limiting what an assistant can do, what needs approval, and how to record the result.

The goal is not to make an agent autonomous. The goal is to make its authority explicit and reviewable.

Architecture and responsibility boundaries

Use four separable stages:

1. **Define the budget** — list what the assistant may read, draft, propose, and never do on its own.

2. **Prepare a proposal** — let the assistant draft the change without executing it.

3. **Review and approve** — let a person accept, edit, reject, or request more detail.

4. **Execute and log** — perform the approved action, record what happened, and keep rollback information when possible.

Keep the main article reader-facing. Keep this guide implementation-focused. Do not let the implementation details change the tone of the mainstream piece.

Minimal permission budget

Store the budget as a small, explicit record:

{
"task": "Email draft and review",
"allowed": {
"read": ["inbox labels", "draft folder"],
"draft": true,
"send": false,
"publish": false,
"delete": false,
"spend": false
},
"requires_approval": ["send", "publish", "delete", "spend"],
"dry_run": true,
"log": true
}

The budget should be specific to the task. A general "be helpful" budget is not enough.

Proposal contract

When the assistant prepares a proposal, require this behavior:

Use only the approved budget for the task.
Do not send, publish, delete, or spend without approval.
Show the exact action before executing it.
Distinguish draft, proposal, and confirmed action.
Do not hide side effects.
Do not invent permissions.

A proposal should make the consequence visible. If the assistant cannot describe what it is about to do, it should not do it.

Approval payload

An approval request should answer a few concrete questions:

Action: send draft reply
To: recipient
What changes: proposed reply text
Risk: medium
Approval: APPROVE / EDIT / REJECT
Notes: waiting on client confirmation

This is not paperwork for its own sake. It is how you keep the human decision tied to the specific action.

Dry run

For anything consequential, prefer a dry run first:

• show what would change,
• show what would be sent,
• show what would be deleted,
• show what would be published,
• show what external side effect would occur.

A dry run is useful because it separates "this looks okay in principle" from "this is the exact thing I am about to allow."

Logging

Keep a short log for each approved action:

{
"task_id": "task-001",
"budget": "email draft and review",
"proposal": "Draft reply to client question",
"approval": "approved with edits",
"action": "send draft",
"result": "sent",
"reviewer": "human owner",
"notes": "Checked recipient and tone before sending"
}

The log is not for surveillance alone. It is for reviewability. If something goes wrong, the record helps you tell whether the issue was the budget, the proposal, the approval, or the execution.

Rollback and failure handling

Design the workflow so a bad action is not the end of the world:

• keep the original state when possible,
• keep the proposed action visible until it is approved,
• allow cancellation before execution,
• note how to undo the action if the system supports it,
• prefer reversible actions during early use.

If an action cannot be reversed, it should usually require a higher approval threshold than an action that can be.

Trust progression

Start narrow and expand only after proof:

• first: draft only,
• next: draft plus human-reviewed send,
• later: approved automation for repeated low-risk actions,
• never: broad authority without explicit boundaries.

Trust should be earned task by task. If a task proves risky, narrow the budget again rather than pretending the assistant is "good enough."

What the assistant should not do

Without explicit owner approval, an assistant should not:

• send messages to real people,
• publish public content,
• delete shared records,
• spend money,
• change permissions,
• act as the final authority on anything consequential.

This list is not a joke. It is the line between assistance and delegation.

Verification checklist

Before the workflow is used with real actions:

• the budget matches the task,
• the assistant cannot bypass approval for consequential actions,
• dry runs are available for risky actions,
• logs are recorded for approved actions,
• rollback or cancellation is possible where practical,
• the owner has approved the budget and the first real use.

Sources

[1] https://www.nist.gov/itl/ai-risk-management-framework — NIST AI Risk Management Framework

[2] https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf — NIST Generative AI Profile