Skip to content
be-human.ai
← Back to the journal

Human oversight

Does Your AI Agent Read Employee Messages? Set Privacy Rules

An AI agent sees only what you connect it to. Learn what it can read in email and chat, which privacy rules to set, and how to tell employees clearly.

A small oak model of a house on a travertine slab with only one window open to the sunlight while the other walls stay closed.
Conceptual illustration created with AI · Be Human

An AI agent reads employee messages only when someone connects it to a mailbox or chat workspace and grants it permission to open that content. What it can see is set by the account it uses, the permissions it holds and the folders or channels you include, so privacy is a design decision made before launch, not a trait of the software. Set the scope narrowly, write the rules down, and tell employees plainly what the agent does and does not read.

Key takeaways

  • An agent sees nothing by default. Its view of email and chat is defined by the account, permissions and sources you connect.
  • Prefer a dedicated agent identity and shared sources, such as a team inbox or named channels, over access to personal mailboxes and direct messages.
  • Reading is only the first step. Decide what is stored, summarized and logged, and who can open those records.
  • Write rules for purpose, exclusions, retention and log access, and require written approval before the scope changes.
  • Tell employees before launch, in plain language, including what the agent does not do and where to raise concerns.

What can an AI agent actually see in email and chat?

An agent does not browse your systems. It acts through an account, and that account holds permissions, usually granted through an authorization flow such as OAuth 2.0. Mail and chat platforms let an application request narrow permissions, often called scopes. One scope may allow reading message metadata such as sender and date. Another allows reading full bodies and attachments. Others allow sending, deleting or searching the entire organization. The agent's view is the sum of what was granted, not what its job description implies.

Two connection patterns matter most:

  • Delegated access: the agent acts as a specific person and sees whatever that person sees, including private threads and direct messages. It is convenient, but it quietly extends one person's private view to a system.
  • Dedicated identity: the agent has its own mailbox or chat account and sees only what is shared with it, such as a forwarded message, a team inbox or a channel it was added to. This is easier to explain and easier to audit.

Chat deserves extra care. Channels feel open inside a company, but direct messages and small private groups carry an expectation of confidence that email often lacks. Workspace-wide search permissions can expose all of it at once, so avoid them unless a role truly needs them and you can justify that in writing. For the email side in more depth, see Connect an AI Agent to Email Without Risking Your Inbox.

Where do messages go after the agent reads them?

Opening a message is one event. Several more follow, and each needs an owner:

  • Working context: the content is placed in front of the model so it can draft, classify or answer.
  • Memory: facts or summaries the agent keeps so it behaves consistently next week.
  • Logs and traces: records of what the agent did, which often include message excerpts.
  • Provider handling: the retention and review terms of the model and tooling vendors involved.
  • Human review: people who read samples to check quality or investigate an error.

An employee who accepts that an agent reads a support inbox may not expect a summary of their phrasing to sit in its memory indefinitely, or a log viewer to be open to a wide group. For each of the five items, ask what is kept, for how long and who can open it. The principle in Data Minimization for AI Agents: Share Less, Keep Control applies directly: give the agent the least content that lets it do the job, and keep less afterward.

Which privacy rules should you set?

Good rules are short enough to remember and specific enough to test. A workable starting set:

  • Purpose: the agent reads messages only to perform its named task, and for nothing else.
  • Sources: shared inboxes and named channels. No personal mailboxes or direct messages unless approved in writing.
  • Exclusions: HR, legal, health, finance and employee representation topics are not processed. The agent flags them instead.
  • No people analytics: the agent does not rate, rank or profile individual employees from their messages.
  • Retention: raw message content is not copied into long-term memory, and summaries and logs have a stated lifetime.
  • Log access: only named roles can open records of the agent's work, and that access is itself recorded.
  • Change control: widening the scope needs approval from the scope owner and an updated notice before it takes effect.

Put these next to your other expectations for AI use, as described in How to Write an AI Acceptable Use Policy for Employees, so people see one consistent set of rules rather than scattered promises.

A blank ivory map on an oak table with a loop of linen thread around one small area, a brass compass and a green marble paperweight beside it.
Conceptual illustration created with AI · Be Human

A step-by-step plan to set the scope

Use this sequence before connecting anything. Common authorization guidance recommends least privilege and deny by default. Treat the agent like a new staff account that starts with nothing.

  • Step one, name the job: write one sentence describing the task and the decision it supports. If a message source does not serve that sentence, it is out of scope.
  • Step two, list the sources the job needs: a shared inbox, specific folders, named channels. Be concrete.
  • Step three, list the exclusions: personal mailboxes, direct messages and the sensitive categories above.
  • Step four, choose the connection: prefer a dedicated identity with the narrowest permissions, read-only first, and sending only with approval.
  • Step five, decide storage: what goes into memory, what is summarized, what is discarded and how long logs live.
  • Step six, assign owners: one person approves scope changes, one reviews access on a schedule, one receives employee questions.
  • Step seven, test with realistic cases: include a message containing personal information the agent should not use, and confirm that it stops and flags the item.
  • Step eight, announce, launch and review: revisit permissions regularly, because added integrations tend to widen access slowly.

If you cannot fill in a step, the setup is not ready to connect.

How should you tell employees?

Employees should hear about the agent from you, before it starts, in words that need no technical background. A good notice covers:

  • What the agent reads and for which task.
  • What it does not read, stated explicitly.
  • What it stores and for how long.
  • Who can see the records of its work.
  • Whether it is used to assess individual performance (the safer rule is that it is not).
  • Where to ask questions or raise a concern, and what happens next.

Illustrative notice wording:

The agent reads the shared support inbox to draft replies for review. It does not read personal mailboxes or direct messages, and it is not used to evaluate anyone's work.

Say it in a meeting and in writing, then invite questions. Rules on monitoring and personal data differ by country, and some places require a specific legal basis or consultation with employee representatives. If you operate in Brazil, LGPD and AI Agents: What Brazilian Companies Should Check is a useful starting point, and your counsel should confirm the details for each location.

A notice only works if it stays true. If the agent later gets wider access, update the notice before the change, not after. And do not promise what the setup cannot keep: if logs may be reviewed during an incident investigation, say so.

Illustrative scenario: access that widens one request at a time

This is an illustrative scenario, not a real case. A regional logistics company gives an agent the job of drafting replies to delivery-status questions in a shared dispatch inbox. At launch, the agent has its own identity, read access to that inbox, and permission to propose drafts that a dispatcher approves. Direct messages and personal mailboxes are out of scope, and the notice says so.

A few weeks later, a manager asks to add her own mailbox because customers sometimes write to her directly. Under the rules, the request goes to the scope owner. The owner asks a better question: why are customers writing to a personal address? The team sets up forwarding so those messages reach the shared inbox, and the manager's mailbox stays private. The agent gets the content it needs without a new category of access, and employees see that the rules held when tested.

The lesson is procedural. Scope rarely breaks in one dramatic step. It widens through reasonable requests, so the approval step and the updated notice matter more than the original list.

How Be Human handles message privacy in managed operations

A first engagement with Be Human defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Message access is written into that role definition: which sources are connected, which are excluded, what is stored and who can read the records. The agent runs under its own identity with permissions that stay under your control. Managed operations include monitoring, permission review and incident response, so any widening of scope goes through a named owner on your side first. The aim is not zero contact with personal content, which a shared inbox cannot always avoid, but explicit boundaries, clear handling rules and a record you can inspect.

Frequently asked questions

Can an AI agent read private direct messages? Only if it has been given access to them, for example through a person's delegated account or broad workspace permissions. Most roles do not need this, so the safer default is to exclude direct messages and personal mailboxes entirely. If a role truly requires them, document the reason, limit the scope and notify the people affected first.

Do employees have to consent before an agent reads shared work messages? It depends on the country, the data involved and your legal basis, so ask counsel instead of assuming. Whatever the legal minimum, advance notice in plain language is good practice and prevents surprise. Where the agent touches personal data, record the purpose and the people responsible.

Can we use the agent to measure employee productivity or sentiment? It may be technically able to, but that is a different purpose from the one employees were told about. Treat it as a separate decision with its own review, legal check and notice, not as a bonus feature. Many companies choose to prohibit it outright for the agent that handles daily operations.

What should the agent do if it finds sensitive personal content by accident? It should stop using that content, avoid summarizing it and flag the item to a named owner. Define this behavior in the rules and test it before launch. The owner then decides whether to remove the item from logs or memory and whether the source should be excluded.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.

Less busywork. More room for you.

Bring us the work you wish you had time for.

Try a personalized AI agent free for 7 days on WhatsApp ↗