> ## Documentation Index
> Fetch the complete documentation index at: https://docs.emanate.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Sensitive Data

> The controls that keep sensitive information out of a draft in the first place

An agent only ever works from sources you have connected, and every one of those sources has a switch. This page
is the full list, so you can decide up front what an agent is allowed to look at before it writes anything on
your behalf.

## Control comes before review

Every draft an agent writes lands in a rep's mailbox for them to read and edit. That review matters, but it is
the last line, not the first. The controls below are designed so that sensitive information does not reach a
draft at all, rather than relying on someone catching it on the way out.

There are three layers, and they work in order.

<Steps>
  <Step title="It is never read">
    A source you did not connect, a field you left out of the connection, or a switch you turned off is not read.
    Nothing an agent never saw can appear in what it writes.
  </Step>

  <Step title="It cannot be asserted">
    Even working from what it can see, an agent is held to what it can evidence. Prices, stock and availability,
    lead times, specifications and order status are checked before a draft goes to the rep. A claim the agent
    cannot support is removed and replaced with a question.
  </Step>

  <Step title="The rep reviews">
    A backstop for judgement calls, not the mechanism that keeps sensitive data out.
  </Step>
</Steps>

## Who an agent writes to

Three settings decide whether a draft is written at all. They all live under **Tactics → Agent Inbox →
Settings**.

| Setting | What it does |
| - | - |
| **Only draft for known contacts** | Nothing is drafted for a sender your team has no history with. New and unknown senders are left alone. |
| **Only draft externally** | Nothing is drafted for anyone inside your own company. Internal threads are skipped entirely. |
| **Skip cc'ed emails** | Nothing is drafted for an email you were only copied on. Threads you were already part of still draft, and mail that reaches you through a distribution list or alias is not treated as a copy. |

Turning all three on means an agent writes only to established outside contacts who wrote to you directly,
which is the narrowest setting available.

## What kinds of email an agent replies to

The **Only respond to these kinds of emails** field, on the same Settings tab, is where you describe in plain
language what is in scope. Anything outside that description is left for a person.

Write it the way you would brief a new hire. For example:

> Only reply to pricing and availability questions from existing customers. Leave anything about contracts,
> legal terms, credit, margin, or a complaint for me.

Leaving the field blank means no restriction, so fill it in if you want one. Emanate can suggest a starting
point based on the kinds of email you already reply to yourself, which you can edit or dismiss.

## What an agent may look up

Each source an agent can reach is its own switch, so you can leave one on and another off.

| Source | What it is |
| - | - |
| **Use attachments** | The files and images attached to the email being replied to. See [Attachments](/trust-security/attachments). |
| **Allow ERP lookups** | Order history, pricing and availability from your connected ERP. |
| **Allow document lookups** | Documents from the folders you shared through your document storage connection. |

Switching one off is complete. The agent does not read a summary, a cached copy, or a partial version of that
source. It drafts without it.

## Which CRM fields an agent can see

Field selection happens when the connection is set up, not afterwards. Your team chooses which CRM fields come
across into Emanate, and a field left out of that selection is never read, never stored, and therefore can never
appear in a draft.

This is the strongest control available, because it removes the data rather than asking an agent to be careful
with it. If a field holds margin, cost, credit terms, contract language or anything else that should never reach
an outbound email, leave it out of the connection.

The [CRM integration](/integrations/crm) page lists the fields Emanate reads by default. If any of them should
not leave your CRM, say so during setup and they will be dropped from the connection.

<Tip>
  The same applies to whole objects. If your team would rather Emanate never see opportunities or activity
  history, those can be left off the connection entirely.
</Tip>

## What an agent will not state

Some information is not sensitive because of where it is stored, but because of how it could be used. An
internal cost is a normal number in your ERP and a serious problem in a customer email.

Before a draft reaches the rep, it is checked for claims that carry that risk:

| Claim | What happens |
| - | - |
| A price or quote | Kept only if it is backed by a source the agent is allowed to quote from |
| Stock, availability or lead time | Kept only if a lookup actually returned it |
| A specification or capability | Kept only if it came from your own material |
| Order status | Kept only if the order was found |

An unsupported claim does not survive into the draft. It is replaced with a single specific question, so the
reply asks for the missing fact instead of inventing it.

Internal cost and inventory figures are explicitly excluded from being presented as a customer price. An agent
may use them to understand a situation. It will not put them in an outbound email as a quote.

## Confidential and protected email

Not every sensitive thread looks sensitive from the outside. Your team already marks the ones that are, and an
agent respects those marks.

**Email your platform has labelled confidential, or its equivalent in your own labelling scheme, is excluded
from drafting.** An agent does not reply to it, does not draft from it, and does not carry its contents into a
reply on another thread. The label is treated as an instruction, not a hint.

**Encrypted and rights-protected mail is not readable.** Where a message's contents are protected, they are not
available to a connected application at all, so nothing inside one can reach a draft.

Which labels count as confidential is yours to set. Label schemes differ between organisations, so the mapping
from your labels to "exclude this" is agreed during setup rather than assumed.

Two further controls stack on top:

* **Mailbox scope.** Connect only the mailboxes an agent should work in. An unconnected mailbox is never read.
* **Your scope description.** The **Only respond to these kinds of emails** field is enforced per message, so an
  instruction such as *never reply to anything about contracts, legal terms, or credit* keeps that category of
  thread out of drafting even when the mail itself carries no label.

<Note>
  Bring your label scheme to setup. Tell us which labels mean confidential in your organisation and they are
  wired into the exclusion before any agent starts drafting.
</Note>

## What an agent learns your writing style from

An agent writes drafts that sound like the rep rather than like a template. Reps ask a fair question about how
that is learned, because a working inbox is not only customer conversations. It also holds suppliers, peers,
managers, and internal threads that have nothing to do with a customer.

The customer-facing voice is learned only from the rep's own correspondence with customers and prospects.
Internal communications and non-customer correspondence, including supplier threads and conversations with
colleagues and managers, are excluded from that learning.

This is about voice, not facts. Learning how someone writes is separate from what an agent is allowed to say,
and the controls above govern the second. A style learned from customer mail cannot carry an internal detail
into a draft, because the facts in a draft come from the sources you connected and are held to the checks in
[What an agent will not state](#what-an-agent-will-not-state).

## Review as the backstop

With the above in place, review is what it should be: a rep applying judgement to a draft that was already
built inside the boundary, not a person scanning for leaks.

Every draft lands in the rep's own mailbox. Nothing is sent without them. See
[Autonomy & Approvals](/trust-security/autonomy-approvals) for where that can be tightened further.

## Next steps

<CardGroup cols={2}>
  <Card title="Attachments" icon="paperclip" href="/trust-security/attachments">
    Turning attachment reading on and off
  </Card>

  <Card title="Data retention" icon="clock" href="/trust-security/data-retention">
    What is stored and for how long
  </Card>

  <Card title="Autonomy & approvals" icon="check" href="/trust-security/autonomy-approvals">
    What an agent may do without asking
  </Card>

  <Card title="CRM integration" icon="database" href="/integrations/crm">
    The fields read from your CRM
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.