Step-by-step guide Your First AI Agent in a Weekend: inbox triage + lead follow-up →
Should an AI assistant send your emails for you? For anything that reaches a customer, a patient or a supplier, our answer is no: let it draft, and let a person press send. You answer for what goes out under your name. An incoming email can carry instructions aimed at the model. A reply can be fluent and wrong. And the mail it reads is full of personal data. We built an inbox assistant from three automations in November 2026, and across every test it sent nothing. This article explains why we designed it that way, what the law and the security record say, and what the extra step costs in minutes.
You answer for what it says
In November 2022 Jake Moffatt asked the chatbot on Air Canada's website about bereavement fares. The chatbot said a reduced fare could be claimed after travel, within 90 days. The airline's own policy page said the opposite. When the refund was refused, the case went to British Columbia's Civil Resolution Tribunal.
Air Canada argued that it could not be held liable for information provided by its chatbot. The tribunal member called that a remarkable submission and wrote: "It should be obvious to Air Canada that it is responsible for all the information on its website." The decision, Moffatt v. Air Canada, 2024 BCCRT 149, issued on 14 February 2024, found negligent misrepresentation and ordered the airline to pay the difference between what he paid and what the bereavement fares would have cost.
Keep the limits in mind. This is a small-claims tribunal in one Canadian province, it binds nobody elsewhere, and it concerned a website chatbot. But the reasoning is simple enough to travel: the airline did not take reasonable care that its automated answers were accurate, and the customer was entitled to rely on them. An email from your own address is, if anything, more clearly yours than a chat window.
An incoming email can carry instructions
A language model reads instructions and content as the same kind of thing: text. That is the root of prompt injection, which the OWASP Top 10 for LLM applications lists first (LLM01:2025). OWASP describes the indirect form as what happens when a model accepts input from external sources and that content changes its behaviour in unintended ways. It adds that such input need not be visible to a person, as long as the model parses it. An inbox is exactly that kind of source: text written by strangers.
This is not theory. On 11 June 2025 Microsoft published CVE-2025-32711, an AI command injection flaw in Microsoft 365 Copilot that allowed an unauthorised attacker to disclose information over a network. Microsoft rated it critical, and its record says the flaw was not exploited and needed no action from customers. A case study published in September 2025, which calls the flaw EchoLeak, describes it as zero-click: a single crafted email, with no action by the user.
OWASP is frank that nobody knows a fool-proof way to prevent prompt injection. Its mitigations include giving the model the least access it needs and requiring human approval for high-risk actions. Draft-only is both at once. If a malicious email does steer the model, the worst result is an odd draft that a person deletes. With a send step in the workflow, the worst result is a message to anyone, containing whatever the model could see. We did not test injection attacks in our build, so we make no claim about how well any model resists them. We only removed the way out.
Fluent is not the same as right
Our own results were good, which is exactly why they need a caveat. On 50 fictional test emails, the assistant filled in lead names and timelines correctly for all 14 leads, left fields empty when the email didn't state them, and invented no lead details in the 36 emails that weren't leads. The one reply draft we checked word by word ran to 93 words, promised no prices or dates and asked two sensible questions.
Fifty tidy test emails are not a real inbox. Real threads are forwarded three times, two people share a first name, and the date that matters changed in the last reply. We also got a lesson by accident: three of our five seeded test emails went out with sender, subject and body mixed up, our own mistake, and the assistant sorted what it was given without complaint. A model does not know that an email looks wrong. A person reading the draft beside the original does.
Two prompt rules reduce the damage a wrong draft can do: tell the model to use only facts written in the email, and forbid prices, fees, availability dates and promises. They lower the risk. They do not replace reading.
The mail it reads is personal data
Every email the assistant reads is sent to an AI model run by another company. Under the GDPR that company is a processor, and Article 28 says you may only use processors that give sufficient guarantees, under a contract that binds them. Article 9 goes further for special categories, health data among them: processing is prohibited unless one of its exceptions applies. A patient describing symptoms in an email has sent you health data.
So health or client data needs a legal basis and a processing agreement before it goes through any AI tool, drafting or not. Many practices keep clinical mail in a separate inbox and point the assistant only at the general one. Because we build to healthcare standards, that separation is our default too.
Sending adds a second risk. An automatic reply that quotes a message back, or answers the wrong address in a long thread, discloses data to someone. A draft that is wrong stays in your mailbox. There is also a transparency question. Article 50 of the EU AI Act, which has applied since 2 August 2026, requires AI systems that interact directly with people to be designed so that those people know they are dealing with an AI system, unless that is obvious. An assistant that answers customers by itself raises that question. A draft that you read, change and send is your email. This is not legal advice; ask your privacy adviser about your own case.
"Draft only" is a design choice, not a permission
It would be comforting if a mailbox could be connected with permission to write drafts and nothing more. Google's list of Gmail API scopes has no such option. The scope that lets an app manage drafts is described as managing drafts and sending emails, and Google classes it as restricted. So when you connect a mailbox to an automation tool, read the consent screen, and assume the connection could send. What keeps it from sending is your workflow.
In Zapier, that means choosing the right Gmail actions. Its Gmail page lists five actions that write or send email:
| Gmail action in Zapier | What it does | For customer mail? |
|---|---|---|
| Create Draft | Creates a draft email | Yes |
| Create Draft Reply | Creates a draft reply to an existing email | Yes |
| Send Email | Creates and sends a new email | Only to yourself |
| Reply to Email | Sends a reply to an email | No |
| Forward Email | Forwards an email to new recipients | No |
Our lead catcher ends with Create Draft Reply, and in the test that step returned a single label: DRAFT. Auditing the rule takes a minute, because you can open each automation and read its list of actions. One more trap: Zapier's help centre notes that testing an action step in the editor performs the action in your app. Test a send step and the email goes out, so build on a test inbox.
What draft-only costs: about ten minutes a day
The routine we wrote for the guide takes about ten minutes each morning. Open Drafts. Read each reply next to the original email, fix a name, a tone or anything that sounds off, and send. Mark the lead as waiting in the sheet. Then look at anything labelled urgent.
The honest cost is that a reply waits until a person looks. If speed matters to you, review drafts two or three times a day instead of removing the reviewer. The studies on lead response time support answering within the hour, not within seconds, and a draft that is already written makes that much easier.
Two things keep the review real. Keep drafts short, so they actually get read: our first replies were capped at 120 words and follow-ups at 70. And ask the model for a one-sentence reason with each decision, so a strange label or draft can be traced. A reviewer who approves everything without reading is not a safeguard.
If you want a formal approval step: Zapier has a built-in app called Human in the Loop. Its help article, updated on 26 October 2026, says the Request Approval action pauses a run until a reviewer approves, declines or edits the data, and that it cannot sit inside or after a Looping step. A draft in the mailbox is the lighter version, and it puts the review where the conversation is.
When automatic sending is reasonable
- To yourself. A morning summary of new leads and waiting drafts can only reach you.
- A fixed acknowledgement you wrote. "We have your message and a person will reply within one working day" contains no AI-written text and reveals nothing. Send it by rule, not by model.
- Nothing else, at first. If months of logged drafts show one narrow, low-stakes category that you never edit, you can reconsider that category alone. Keep sensitive mail out of it for good.
Five checks before you switch anything on
- No send step. Read the action list of every automation that touches customer mail.
- Built on a test inbox. Because testing an action performs it.
- Sensitive mail kept apart. A separate inbox, and a processing agreement on file for every tool that reads the general one.
- A strict prompt. Only facts from the email, empty rather than guessed, no prices, dates or promises.
- People told. Colleagues who share the mailbox should know an assistant reads it.
We turned these rules into a working build in Your First AI Agent in a Weekend, inbox triage and lead follow-up edition: three automations that sort mail, log leads and write replies and follow-ups, none of which can send to a customer. To see the first of them step by step, read how to label Gmail automatically with AI in Zapier, and for the test results behind this article, what 50 test emails taught us. The principle fits in a sentence: the assistant does the reading and the writing, and a person does the sending.
Frequently asked questions
Should an AI assistant send emails automatically? Not to customers, patients or suppliers. Let it write a draft, and let a person read it and press send. Automatic sending is reasonable for a summary to yourself, or for a fixed acknowledgement that you wrote. In our three-automation build the assistant created drafts only and sent nothing.
Is a business liable for what its AI tells a customer? A Canadian tribunal said yes in February 2024. In Moffatt v. Air Canada the airline argued it was not responsible for wrong information given by its website chatbot, and the tribunal held it responsible for all the information on its website. The ruling binds nobody outside British Columbia, but the reasoning travels: a message from your address is your message.
What is prompt injection in email? It is text inside an incoming message that an AI model treats as an instruction. OWASP lists prompt injection first in its top ten risks for language-model applications. Microsoft fixed one such flaw in Microsoft 365 Copilot in June 2025, which researchers describe as triggered by a single crafted email. An assistant that can only draft has far less to give away.
Can I use an AI email assistant with patient or client data? Only with care. Under the GDPR, health data is a special category, and any company that processes mail for you needs a contract that covers it. So health or client data needs a legal basis and a processing agreement before it goes through any AI tool. A common approach is a separate inbox for sensitive mail that the assistant never reads.
How much time does reviewing AI drafts take? The routine in our guide is about ten minutes a morning: open Drafts, read each reply next to the original email, fix what is off, send, and update the lead sheet. Short drafts help. Ours were capped at 120 words for a first reply and 70 for a follow-up.