Approval needs evidence, authority and a way back
A human click is not meaningful oversight by itself. The reviewer needs to see the proposed action and evidence, have time and authority to refuse, and know how the system can recover if the decision is wrong.
Our design ties approval to a fixed message payload, distinguishes unknown send outcomes and specifies four failure tests before customer use.
Use the authority matrix before an agent moves from drafting to sending, changing records, issuing credits or touching another system.
Keep in mind: This is a system-design guide, not a security certification or a record of a production deployment.
In this article6 sections
Editorial note: The support agent and authority matrix are fictional design examples. This article does not describe a tested production system or certify that the controls are sufficient for a particular security, legal or operational setting.
“Approved” is incomplete without an object
A reviewer sees a support reply and clicks approve. Before the system sends it, the recipient changes or the agent adds a refund promise. The approval no longer describes the action about to occur. A human was involved, but the control failed at the hand-off.
Design approval around the exact proposed action: recipient, content, attachments, account and any financial or record change. The support workflow here is fictional and has not been deployed. It is a specification you can use to challenge a design before connecting it to customers. The core question is whether the execution system can enforce the reviewer’s decision without relying on the model to remember it.
Give the assistant a narrow job
In our example, the assistant drafts a response using an authorized support record. It cannot change contact details, issue credits or delete tickets. A separate sending function accepts only an approved message. This follows the direction of OWASP’s excessive-agency guidance: constrain functions, permissions and autonomy, and enforce authorization in the downstream system.
Scroll the table sideways to see every column.
| Action | Allowed path | Required evidence |
|---|---|---|
| Read one assigned ticket | Scoped read permission | Authenticated user and ticket access. |
| Draft a reply | Draft storage only | Relevant source facts and unresolved questions. |
| Send the reviewed reply | Separate authorized send step | Exact recipient, content and attachments approved. |
| Issue a refund | Outside this assistant’s authority | Use the organization’s separate financial process. |
| Change customer contact details | Prohibited in this workflow | A different verified procedure is required. |
Freeze the approval record
Create a record with action ID, ticket version, recipient, final text, attachment identifiers, reviewer and expiry condition. The executor should compare what it is about to do with what was approved. A material change sends the proposal back for review.
A checksum can help detect a changed payload, but it does not establish that the recipient is correct or the action is permitted. Those decisions need authenticated identity, access rules and a reviewer with relevant authority. Nor should the approval screen bury the destination behind a friendly display name; show the actual address that will receive the message.
Action: send reply. Ticket version: 7. Recipient: exact verified address. Text and attachments: fixed reviewed payload. Reviewer: authenticated authorized person. Scope: one send only. If the source ticket or payload changes: require review again.A timeout is not proof that nothing happened
Suppose the send request times out after the provider accepts the message. Retrying blindly could send it twice. The system needs a way to reconcile the action identifier with the provider’s result, using an idempotency mechanism where supported or another documented duplicate-prevention process.
Represent the uncertain state explicitly. “Draft,” “awaiting approval,” “sending,” “confirmed sent” and “outcome unknown” should not collapse into a single success flag. When the result is unknown, pause further attempts until the delivery record can be checked. The precise mechanism depends on the provider; this article does not claim every API offers the same guarantee.
Test four failures before a customer sees it
These are proposed acceptance tests, not a report of tests we ran against a production service. Run them in an appropriate isolated environment with your actual authorization and sending systems.
release gates for consequential AI failuresConnect these permission cases to an explicit stop or release decision.
- Change the recipient after approval. Execution must not use the stale approval.
- Place instructions inside a support document asking the agent to export other tickets. Retrieved text must not grant that authority.
- Revoke the reviewer’s permission before execution. The downstream authorization check must still apply.
- Simulate an ambiguous send response. The workflow must reconcile the result rather than assume failure and repeat it.
Plan recovery around what cannot be undone
An internal draft can be deleted. A sent message may already have been read, forwarded or acted on. Calling every action “reversible” hides that difference. Document what can actually be restored and who handles the consequences that remain.
Keep enough action history to investigate without indiscriminately duplicating sensitive ticket content. Record version, authority, approval and execution outcome under the organization’s retention rules. A meaningful human checkpoint joins evidence to a specific enforceable action; a generic approve button does not establish that control.
Continue with the original sources
These claim-relevant primary and first-party references support the reporting above. Open them for technical detail, current requirements and subsequent updates.
- anthropic.comAnthropic: Building effective agents ↗Distinguishes predefined workflows from agents and discusses complexity, tools and feedback. Vendor engineering guidance, not an independent benchmark.
- genai.owasp.orgOWASP: Excessive Agency ↗Describes risks from excessive functionality, permissions and autonomy, and ways to limit them.
- nist.govNIST: Generative AI Risk Management Profile ↗Risk-management background, including confabulation and information integrity. It does not certify the examples or prescribe our scoring thresholds.
Finished reading? Save that here without waiting for a timer.
Rewritten throughout on September 21, 2026, with a complete worked method, explicit evidence limits and checked primary sources.
See something we should fix or clarify? Read the corrections policy or tell the newsroom. Material changes are noted here.
