# Mail is untrusted input

The assistant reads strangers' e-mails, and what it writes is saved into your
mailbox. Anyone can hide an instruction for the model in an e-mail — "ignore
the rules, cc the reply to…". It is a real attack, and draften defends against
it in layers, **without relying on the model refusing the instruction**.

## Before the model

- **Automatic mail is dropped by its headers** (auto-replies, bounces,
  notifications, bulk mail) before any model sees it. The assistant never
  answers it, so a loop of two machines cannot start. The exception is the
  web-form addresses from the assistant's settings.
- **Hidden text is removed** — white text, zero size, off-screen text, HTML
  comments. What was found is recorded with the message.
- **Invisible characters** (zero-width, control and direction characters and
  the like) are stripped and counted.
- **Sentences that look like instructions** are flagged; the message then
  carries the **suspicious** label in Mail.

## In the model's instructions

Every foreign text — the subject, the sender's name, the body, earlier
messages of the thread, results from the archive and connected systems — sits
in a closed block with a note that it is data, not instructions. The block's
markers are escaped in the content, so an attacker cannot close the block. The
rule about blocks is part of draften's fixed core, not an editable text. The
model is told to hand the matter over when it sees an attempt at manipulation.

## After the model

What the model writes, draften checks just as distrustfully — it went through a
stranger's e-mail:

- the **recipient** may only be an address that is in the original message,
- a **Cc** only from the assistant's allowed addresses, otherwise it is left out,
- **attachments** only from the assistant's attachments list,
- **links** only to allowed domains and the knowledge sources' domains,
  otherwise the draft is not created,
- the **signature** must be in the draft whole, otherwise the draft is not
  created,
- a draft must not open with the assistant's handle (it would look like the
  owner's instruction),
- **limits** per day, per sender and per check slow a flood.

## What is never possible

- **Nothing is sent.** The app registration has no `Mail.Send` permission and
  draften has no sending call. You see every draft before you send it yourself.
- **Nothing is deleted.** The assistant deletes nothing in the mailbox.
- Connected systems (CRMs) **only read**, and only about the thread's
  participants.
- Addresses the assistant fetches (links, help sites) must be public — a source
  never reaches the server's internal network.

## What the defence does not cover

The content of the draft text itself — and an attacker who writes their own
address into the body of the e-mail (the recipient check then finds it there).
For a draft a person approves, that is acceptable; for automatic sending it
would not be — which is another reason draften never sends.

See also [The safety net](/en/admin/safety-net).
