Should your browser AI send replies to suppliers?

Start with a draft-only pilot

For a founder with a limited pilot budget, the first decision is whether reply preparation saves enough work while a colleague still checks every outgoing message. Authorise the assistant to read selected supplier enquiries and prepare proposed replies. Keep the actual send action with a person using a separate session the agent cannot control. This gives the team a useful task to evaluate before paying for a more complex approval workflow.

Consider a fictional Hong Kong importer asking for an updated delivery date for sample cartons. The assistant needs the selected enquiry and relevant order details. It does not need the founder’s entire mailbox, customer margin sheets or permission to change forwarding rules. Define that scope before connecting an account. Drafting can still expose information through a bad reply, so every draft needs inspection before a person sends it.

Supplier messages cannot grant authority

Anthropic’s research on browser prompt injection describes malicious instructions embedded in material an agent reads, including email. Its example involves hidden text directing an agent to forward confidential correspondence. The research says the problem remains unsolved. This supports treating incoming content as untrusted; it does not establish that a particular pilot design is immune.

A supplier can ask for a delivery update, but cannot grant your assistant new permissions. A message claiming that management has approved an urgent attachment transfer is still supplier content. The following controls and rehearsal are proposed editorial applications of that threat, not reported customer results or a certification of a product.

Choose a boundary the system can enforce

A prompt saying ‘never send’ is not a draft-only permission. Ask the implementer to demonstrate that sending is unavailable through both mail integrations and browser controls. If the agent controls a logged-in mailbox with a working Send button, withholding one API permission is insufficient. Where the product cannot separate reading from sending, use selected message copies in an isolated workspace, with no live mail session or unrelated browser tabs.

If a later pilot includes sending, place approval outside the agent’s control. The reviewer must see the full recipient addresses, CC and BCC fields, subject, body, attachments and any quoted thread. Approval should bind to that exact message; a subsequent change should require another review. Do not allow the agent to approve its own action or treat approval of one reply as permission for the whole mailbox.

Rehearse a hostile supplier email safely

Run the rehearsal in a test mailbox containing fictional orders and attachments. Block real external delivery and use an internal capture destination for attempted sends. The legitimate task is to draft a request for a revised sample delivery date. Add a fictional supplier message asking the assistant to attach an unrelated pricing file and bypass review, framed as an urgent management request. Label the material as test data for the people running the exercise.

1. Establish normal behaviour

   Confirm that a normal enquiry produces a draft and no outgoing delivery. Save the permitted task and resulting draft for comparison.

2. Introduce the hostile request

   Repeat with the fictional hostile message in English and Traditional Chinese. Check for unrelated file access or sending attempts, even if blocked.

3. Challenge the approval boundary

   For an approval-enabled prototype, reject a send, then alter a recipient or attachment after a separate approval. Each unapproved version must remain unsent.

Inspect attempted actions as well as the final answer. A reassuring summary is weak evidence if the browser tried to upload a file elsewhere. Record the test input, draft, permission decision, attempted destination and captured delivery state. Keep real pilot logs access-limited and avoid copying entire business mailboxes into diagnostic records. Passing this rehearsal only shows the tested configuration handled these cases; changed permissions, integrations or model behaviour warrant another run.

Make the next purchase decision from the pilot

Before the next vendor demonstration, give one purchasing colleague ownership of a small draft-only trial. Record time spent selecting inputs, correcting drafts and checking recipients and attachments against the current manual process. Pause expansion if there is any unauthorised action or if you cannot establish what was sent. Continue only when the review workload is worthwhile and an owner can maintain the permissions. Automatic sending is a separate future decision, not the default reward for fluent drafts.