Draft first, send second

The risky part begins after the draft

An AI assistant can turn a rough note into a calm email in seconds. That is useful. The danger is letting the convenience of drafting erase the decision that follows: whether this exact message should go to this exact person now.

A fluent draft may contain a guessed date, soften a promise into something you did not mean, copy a private detail from the context or sound certain where your notes were uncertain. None of those problems requires a malicious system. OWASP's guidance on misinformation describes model output that is false or misleading while still appearing credible, and warns that overreliance grows when people accept generated content without checking it.

The safe boundary is simple: the model may prepare text, but it does not choose the recipient, approve the claims or perform the send. Drafting is reversible. Sending is an external action that may be impossible to recall completely.

Give the model a writing job, not a sending job

Treat an outbound message as two separate operations. The first transforms approved notes into a candidate draft. The second commits that draft to another person's inbox, chat or public feed. Put a hard human checkpoint between them.

This is more than etiquette. OWASP's guidance on excessive agency recommends limiting tools and permissions to the minimum necessary. Its mailbox example says a system that only needs to read or summarise email should not also have send capability, and its mitigations include a person manually reviewing and sending every AI-drafted message.

For an everyday workflow, that means using a tool that cannot send, or keeping its sending integration disabled. If your product combines drafting and sending, save into drafts and require a deliberate confirmation that displays the full recipient list, subject and body. A prompt such as “do not send” is useful context, but it is not the same control as withholding send permission.

A worked example: the room-change update

Imagine a fictional repair café moving Saturday's session from the library to a community room. The coordinator wants help writing an update for registered volunteers.

Start with an approved fact card, not the whole mailbox:

Ask for a subject line and a short body, with any uncertainty marked rather than filled in. The result is still only a candidate. The coordinator compares every factual sentence with the approved fact card, replaces placeholders in the normal mail tool, checks that recipients belong to the registered list, previews the final message and presses send personally.

The model did the language work. The coordinator retained the authority and the evidence needed to explain the message.

• Purpose: tell registered volunteers that the venue changed.
• Confirmed facts: Saturday, 10:00–13:00; Community Room B; step-free entrance on the east side.
• Unknown: whether parking remains available.
• Tone: direct, warm and brief.
• Prohibited claims: do not say parking is available; do not promise individual assistance.
• Placeholders: use `[first name]` and `[reply address]`; include no volunteer list in the AI input.

Six checks at the send boundary

A useful review is short enough to run every time and specific enough to catch more than spelling.

If any check fails, return to the fact card or message owner. Do not ask the same model whether its own draft is safe and treat the answer as independent verification.

• **Recipient:** Is every person meant to receive this, and are address fields arranged so recipients cannot see one another's details unintentionally?
• **Authority:** Am I allowed to make this statement or promise on behalf of the person or organisation named?
• **Facts:** Can I trace dates, amounts, links, names and commitments to an approved source rather than the draft itself?
• **Privacy:** Did the input and final message use only the personal data needed for this purpose? The ICO's AI guidance says data minimisation requires identifying the minimum personal data needed and processing no more.
• **Tone and ambiguity:** Could a reasonable recipient read urgency, blame, consent or certainty that I did not intend?
• **Final preview:** After substitutions and formatting, have I reread the exact subject, body, attachments, links and recipient list that will be sent?

Keep some messages outside this workflow

This pattern suits bounded, low-consequence communication: scheduling updates, acknowledgements and first drafts that an accountable sender can fully verify. It is not a shortcut for professional judgment.

Keep legal notices, medical guidance, employment decisions, payment instructions, safety-critical alerts and messages involving conflict or safeguarding outside an informal AI drafting flow unless an approved specialist process explicitly covers them. A human glance does not cure missing authority or expertise.

Also check the chosen tool's current data-use terms and your organisation's policy before entering confidential or personal information. Removing names may not be enough if the remaining details identify someone when combined. When the task can be completed with neutral placeholders and a small fact card, prefer that narrower input.

Recovery matters because review is not perfect

Even a checked message can be wrong. Decide the correction path before sending: who owns replies, how an error will be confirmed, who may issue a correction and which record shows what was actually sent.

If the message contains a material mistake, stop any scheduled follow-up, preserve the sent version, verify the correct fact with its owner and send a clear correction through the same channel. Do not quietly edit a web copy and assume every recipient will discover it. If personal or confidential data went to the wrong person, follow the organisation's incident process rather than improvising a reassuring reply.

What we would do next

Take one recurring outbound message and split it into a fact card, a draft step and a send checkpoint. Remove send permission from the drafting tool. Then rehearse one awkward case: a missing fact, a wrong recipient or a correction after sending.

The goal is not to make every email bureaucratic. It is to keep AI in the part of the workflow where speed is useful and mistakes remain reversible—and keep a person at the boundary where words become an action.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends limiting tools and permissions to the minimum needed, keeping send capability out of a read-or-draft workflow, and requiring human approval for high-impact actions.
2. LLM09:2025 Misinformation — OWASP Gen AI Security Project. Describes plausible false or misleading model output and recommends cross-checking, human oversight and fact-checking for critical or sensitive information.
3. How should we assess security and data minimisation in AI? — Information Commissioner's Office. Explains that organisations using AI to process personal data must identify the minimum amount needed for the purpose and process no more.

More from Server Attic

• 2026-09-04

  A web page is not permission for your AI agent

  An agent can use a page, document or message as evidence without treating instructions inside it as authority. Design that boundary before connecting powerful tools.

• 2026-08-26

  Local AI stays private only if the whole workflow does

  Running a model on your own machine can remove one remote data path, but prompts, tools, logs, saved outputs, backups and sharing still decide where information travels.

• 2026-08-03

  Don't ask AI if it's right

  A confident answer is not evidence. Build a small verification plan around the claim, the consequence of being wrong, and the source or test that can actually settle it.