Bind Agent Approval to the Exact File and Recipient

A report assistant prepares an attachment, shows two recipients, and asks whether to send it. The user says yes. Before sending, the assistant refreshes the report and adds a contact found in a retrieved document.

The final message may still look like the same task. It is not the same approved action. A confirmation dialog provides little protection if its permission can silently move to different bytes or different people.

This guide is for developers building agents that share files, send messages, or hand work to another system. Its focus is the gap between preview and execution, not how to make the model ask permission more politely.

Methodology: examine the handoff, not the reassurance

We reviewed OWASP guidance and the explicitly versioned MCP tools specification dated 2025-06-18. The report example and acceptance exercise below are proposed designs, not tests we ran against a product.

OWASP recommends that an execution component independently check an agent's proposed action and that approval identify the actor, tool, resource, parameters, and validity period. That is a stronger boundary than a conversation-level confirmed flag. OWASP AI Agent Security.

The MCP specification requires server-side input validation and access controls, while recommending that clients display inputs and obtain confirmation for sensitive operations. Protocol support does not prove a particular client implements the needed approval interface. MCP tools security considerations, 2025-06-18.

Make the proposed send a specific object

Consider this fictional handoff: send the September supplier brief, revision A, to the two procurement reviewers selected by the user. Preparing the brief and sending it are separate operations.

Before asking for approval, create a preview that identifies:

• The sending account and workspace.
• The actual destination addresses, including copies and hidden copies.
• The subject and message body the recipients will receive.
• The attachment's displayed name and immutable stored version.
• Whether the operation sends a message or merely saves a draft.

Do not make the user compare cryptographic hashes. Show a readable attachment preview and store the technical identity behind it. A filename such as supplier-brief.pdf is useful for orientation but cannot distinguish yesterday's document from today's overwritten file.

Our proposed implementation would freeze the attachment into a versioned object before displaying the preview. If storage cannot preserve that version, the sender needs another way to read the same bytes it checks. Checking a mutable path and reopening it later leaves another change window.

Decide which changes invalidate approval

For this example, changing the attachment, sender, body, or any recipient requires a new preview. Reordering equivalent recipient entries for display need not create a different action, but normalization must not hide a changed address or recipient role.

A design review can use four concrete cases:

The important distinction is between presentation and effect. This is a policy for the fictional report workflow, not a universal definition of harmless changes. An organization may need stricter rules for regulated or confidential correspondence.

Keep source material out of the permission channel

Retrieved material can contain instructions disguised as task context. OWASP identifies indirect prompt injection in sources such as documents, issue descriptions, and external web content. OWASP prompt injection prevention.

In our example, a supplier document might name a new address and ask that reports be copied there. That information can be shown to the user as a proposed change; it cannot update the authorized recipient set by itself. The same applies if a tool response claims that the user already approved the new address.

Keep the approval record in the trusted application layer. Let the agent propose a revision, but do not let generated prose substitute for the application's record of what the user actually approved.

Review execution evidence with a small exercise

Use a test workspace and non-sensitive fixtures. Approve revision A, then replace the draft at its original path with revision B before execution. The expected outcome is either delivery of the preserved A object or a stop for renewed approval, according to the documented design. Sending B under A's approval is unacceptable.

Repeat with an extra recipient and an expired approval. Also interrupt the workflow after the downstream service accepts a send but before your application records its result. The correct recovery is not necessarily another send: first determine whether the message already exists.

Record the preview identifier, chosen artifact version, execution decision, and downstream result reference. Keep message contents and sensitive addresses out of broadly accessible diagnostics. A log saying “approved” without identifying the approved object cannot resolve a disputed send.

These are acceptance criteria to implement and observe, not claims that any listed skill already passes them.

Limitations and where a skill fits

Precise approval cannot make a compromised sender trustworthy, correct a misleading preview, or recover confidential data after delivery. Transport uncertainty also needs its own recovery policy. An approval record is not an exactly-once delivery mechanism.

A reusable skill can explain this workflow and prepare the preview, but enforcement belongs in the application and tool boundary. When evaluating candidates in the skills directory, ask which protections are implemented and which are merely instructions.

The same reasoning applies to changes in a skill package: old evidence does not automatically cover new bytes. Our version-bound review guide covers that separate installation decision. For outbound work, the practical question is simpler: can the executor demonstrate that it sent exactly what the user approved?