Quick answer

Secure agent approval binds an authorized person's decision to a specific action and target. A confirmation button alone does not provide this property. Changing the recipient or document should invalidate the earlier approval. Permission must be checked again at execution. An uncertain outcome should not trigger blind retries.

This guide proposes design and acceptance criteria for agents that send messages or modify business records. It complements the excessive agency guide. The focus here is the relationship between a particular approval and the operation actually executed.

Show the decision that matters

When an agent proposes sending a document the approval view should identify the recipient and document version. Explain whether information leaves the organization. The approver must also have authority over that action.

OWASP transaction authorization guidance emphasizes meaningful transaction details and server enforcement. Changing those details should reset the approval process. Applying these principles to agent workflows is the design proposal developed here rather than an endorsement of a particular agent product.

A proposed transaction envelope

Create a record containing the verified user and customer. Include the tool version and action. Bind the target and significant parameters to the record. Identify the document version when an attachment is involved. Associate a policy version and an expiry time.

Trusted application logic should translate the model's proposal into validated fields. Generate the approval summary from those same fields. A free text summary written by the model can disagree with the eventual API request.

Suggested fields are transaction identifier; user; customer; tool version; target; significant parameters; document version; policy version; creation time; expiry; approver; execution state. This is an application design template rather than a protocol standard.

A hash can help detect a content change. It does not establish the identity of an approver or prove that the decision came from an authorized source. Protect the record through trusted server mechanisms and keep secrets out of it.

Design the lifecycle before the happy path

A proposal begins pending. Rejection and expiry prevent execution. A material change requires a new proposal. Before execution check current permission and relevant target state. The result can be successful or failed. If the downstream reply is lost the correct state may be unknown.

A disconnected request does not prove that an email was never sent. Retrying can create a second effect. The system needs a way to query the transaction or reconcile the outcome. RFC 9110 explains HTTP method idempotency. Application transaction guarantees require additional design.

Eight acceptance tests

Use synthetic mailboxes and test records. Inspect backend state rather than only the confirmation screen. This is an original worksheet proposed for the guide.

No Test Expected behavior Evidence
1 Recipient changes after approval New approval required Comparison of transaction summaries
2 File content changes under the same name Old approval excludes the new version Document version and transaction record
3 Approval expires No execution Server timestamps
4 Approver loses permission Execution denied under current policy Authorization decision
5 Same transaction starts concurrently twice One logical effect or controlled reconciliation Backend transaction identifiers
6 Connection fails before the result returns Unknown outcome investigated Query and reconciliation record
7 A document contains a fake approval statement Document text grants no approval Verified approval source
8 A batch gains additional targets Earlier approval excludes extra targets Approved and executed counts

Download the agent approval worksheet.

Fictional case: the approved attachment changes

A sales agent proposes sending a quotation. The user approves its price and recipient. While the job waits in a queue a new file replaces the attachment under the same name. It contains another customer's discount conditions.

Approval attached only to a path may treat two contents as one object. A version bound record exposes the change. The expected outcome is a stop and a request to review the new version. This is a teaching scenario rather than a client incident or a measured product result.

Retries need a service contract

An idempotency key is useful but does not automatically guarantee exactly one effect across every downstream service. Control concurrent consumption of the key. Retain durable outcome records. Define key lifetime and what happens if parameters differ on reuse.

Some APIs return a saved result when a key is reused. Retention and error behavior depend on the provider. Stripe's idempotent request documentation illustrates an explicit contract. Do not assume an undocumented email or file API behaves identically.

Collect evidence without creating another data leak

The transaction identifier should connect proposal and approval to the final outcome. This does not require copying every confidential document into general logs. Limit collected fields and control access and retention. The OWASP logging guide addresses both event correlation and sensitive information handling.

A useful finding identifies which parameter changed and what the backend did. A useful retest also shows that the legitimate action still works. Disabling every operation is not acceptance of a functioning agent workflow.

Frequently asked questions

Must every agent action require human approval?

No. Define policy according to the operation's effect. Sensitive external sharing and difficult to reverse changes need tighter controls. Low impact actions can have a defined standing scope.

Is saying yes in a conversation enough?

Only if the system reliably binds the decision to the right transaction and identity. A yes inside a document or another session grants no authority.

Can a stronger model replace these controls?

No. Enforcement should not depend on the model making the right prediction. Proposal and execution authority are separate responsibilities.

Does hashing make the record secure?

Not by itself. Hashing supports content comparison. Identity verification and authorization and record integrity remain necessary.

Scope a DSET assessment

Identify the three agent actions with the greatest business effect and describe their approval views. State who may approve them and what an incorrect action would cause. DSET cybersecurity scoping can begin with this inventory. MCP acceptance tests cover connected tool boundaries.

This guide does not attest that KAOS or another product implements every proposed control. The envelope and worksheet are original design proposals. Sources were checked on 11 October 2026.