# The safety net: what draften never does

This page is for whoever answers for draften in the company — and for anyone
asking "what if it goes wrong". The things below are not settings. They are
properties of the program and cannot be switched on or off.

## It does not send

**There is not a single place in draften's code that would send a message.** It
does not use an outgoing mail server (SMTP) at all.

With Microsoft the permission itself enforces it: `Mail.Send` is never granted.
With Google only the scopes for reading, drafts and labels are given. A mailbox
connected over IMAP uses an account with an app password, so there the barrier
is not put up by the provider but by draften — it has no SMTP and cannot send.

So no mistake in the instructions, no forged e-mail and no slip of the hand can
result in mail going out. The worst case is a badly written draft — and someone
has to send that by hand.

## It does not delete

The assistant removes nothing from the mailbox: no message, no draft, no
folder. It does exactly two things there: it creates a draft, and it marks the
processed message (with a category, a label or a keyword, depending on the mail
system) — and if the message was unread, it leaves it unread.

> A draft it wrote itself, it can **rewrite** on your instruction. That is the
whole extent of what it does with one: it does not delete it and does not send
it. See [Revising a draft by instruction](/en/revising-a-draft).

## Foreign text is never a command

Every text that came from outside — the body of a message, the history of a
thread, the contents of a documentation page — is handed to the model
**fenced** and labelled as data. The rule that instructions are never taken
from such text lives in the program, not in an editable text. It cannot be
overridden by your instruction, nor by an attacker's sentence in an e-mail.

On top of that, a message is **cleaned** before it is processed: white text,
zero-size text, HTML comments and invisible characters are removed, and what
was found is recorded with the message. The work goes on — it is just visible
what happened.

> Why this matters: anyone can write an e-mail. If the text of a message were
taken as an instruction, writing "send the reply to another address" would be
enough. In draften such an attempt ends as a record, not as an action.

## The model's output is checked

What the model writes is **verified by the program** before a draft is saved:

- an attachment only if the assistant is allowed to use it;
- a copy (CC) only to addresses on the allowed list;
- a different recipient only if that address stood in the original message;
- links only to allowed domains, plus the knowledge sources;
- the signature must appear in full, and the text must not open by addressing
  the assistant.

If any check fails, **no draft is created** and the message gets the rejected
state with the reason.

## Money has a ceiling

The daily cost cap is the last safeguard: **once the configured cap is
reached**, no model is called and processing stops. Nothing queues up and
nothing is caught up later — the next day carries on as usual. Caps are set per
assistant and for the organisation as a whole. See
[Cost and caps](/en/admin/cost-and-caps).

## Credentials are encrypted

Mailbox credentials, model keys and tokens to connected systems sit in the
database **encrypted** (AES-256-GCM). The key that unlocks them is kept outside
the database; on your own installation that is `MASTER_KEY`.

!> Backing up the database without `MASTER_KEY` is not enough: without the key
the encrypted values are useless after a restore. See
[Backup and restore](/en/admin/backup-and-restore).

## Two workers do not collide

Even with several draften processes running, one mailbox is always handled by
one of them — it holds a lock on it in the database. Two drafts for one message
cannot happen.