How to Prevent an AI Agent from Emailing Client Files Through the Microsoft 365 MCP Mail Send Tool

Map the paths to the Mail Send tool

An agent connected to a Microsoft 365 MCP server with a send tool can attach or paste client files into an outgoing message. The tool call is legitimate and authorized, so the failure is not a broken credential. It is an authorized action taken for the wrong reason, or with the wrong content.

NIST's agentic security material describes this pattern: agents misuse legitimate tools through prompt manipulation or privilege control problems, resulting in data exfiltration, unsafe operations or workflow hijacking. Its example is an agent that shifts from "summarise this thread" to compiling previous emails and attachments and sending them externally. Because the model treats text as intent, instructions can sit inside PDFs, emails, retrieved content or output from other agents.

Before choosing controls, list every route by which a send could happen in your deployment. Four are worth testing explicitly.

• Indirect prompt injection: Content the agent reads, such as an inbound email or document, carries an instruction to send data out.
• Over-broad delegated scope: The agent inherits roles, cached credentials or delegated scopes that allow more than its task requires.
• Task drift: A benign request such as summarising a thread expands into collecting and sending attachments.
• Poisoned or impersonated tools: A malicious or spoofed MCP server or tool receives data or issues instructions the agent trusts.

Apply preventive controls at the identity, permission and tool layers

Start with identity. Give the agent its own identity rather than running it under a user's account, so that its access can be scoped, reviewed and revoked independently. Review inherited roles and cached credentials, since these are the privilege paths that let an agent do more than intended. Assign a named owner for the agent identity, its delegated scopes and tool approvals.

Next, permissions. Grant only what the agent's tasks require. If the task is to read and summarise, it should not hold a permission to send mail at all. Where sending is required, check whether the grant lets the agent send as users or mailboxes beyond the one it needs, and narrow it. Separate agents that read untrusted content from agents that can send, so a poisoned input cannot reach a send capability in the same context.

Finally, tool configuration. Expose the Mail Send tool only to agents and tasks that need it. Vet MCP servers and tools for provenance, because a poisoned or impersonated tool is a different risk from over-broad permissions on a legitimate one. Test the result against the task-drift scenario: ask a summarising agent to send its findings externally and confirm the call is not possible.

Understand where native controls stop

Mailbox permissions, tenant mail-flow rules, data loss prevention and sensitivity labels each address part of the problem. They are built around who may use a mailbox, how mail is routed and what content it contains. None of them was designed to judge whether an agent's decision to send was within the scope of the task it was given.

The core limit is that an authorized call looks like any other authorized call. Review after the send is too late for client files, because the message has already left. Test how each native control behaves for mail submitted by your agent identity through the tool in your own tenant, and do not assume parity with mail sent by a person in a mail client.

This is why the control point has to be the call itself and its parameters. Prompt engineering alone is not enough either. NIST material treats prompt injection as manipulation of model input and does not present model-layer defenses as sufficient, which supports controls outside the model.

Define runtime policy on each send call

Runtime policy evaluates the parameters of each call before it reaches the mail system and returns a decision. Define the conditions first, then map each to an outcome. Begin with a deny-by-default posture for external recipients and loosen it deliberately.

Recipient domain is the simplest condition and usually the most valuable. Attachment presence is the second: for client files, most teams will block attachments to external domains outright and permit only named internal workflows. Content sensitivity applies to the body and any extracted attachment text, using the classifiers your organization already trusts. Send volume limits the damage of a looped or hijacked agent.

Redaction suits body content where a match is partial and the message is otherwise valid. For attachments, block or escalate is usually the safer choice, since a modified file may be misleading. Human approval should show the approver the recipient, the attachment names and the content that triggered the policy, and the call should wait rather than proceed by default.

• Allow: Internal recipients or approved domains, no attachments, no sensitive content, volume within limits.
• Redact: Sensitive values in the message body, where removing them leaves a valid message.
• Block: Attachments to external domains, unapproved recipient domains, or content classified as client data.
• Rate limit: Send counts per agent identity and time window that exceed the expected pattern for the task.
• Escalate for human approval: Ambiguous cases, such as an approved partner domain with an attachment, held until a named approver decides.

Retain evidence that shows what was permitted and what happened

An auditor will ask two questions: what was the agent allowed to do, and what did it do. The first is answered by configuration records: the agent identity, its scopes, the tools exposed to it and the policy version in force. The second is answered by a record for every send call, including those that were blocked.

Define the fields against your own control framework, and make the record tamper-resistant and retained for as long as your obligations require. A practical minimum for each call follows.

Also prepare an incident response step for the case where sensitive data does leave by email: who is notified, how the recipient is contacted and how the evidence record is used to scope the exposure.

• Who and when: Agent identity, requesting user or task, timestamp and the MCP server and tool called.
• What was requested: Recipient domains, attachment presence and names, and message size.
• What was assessed: Content classification result and which policy conditions matched.
• Decision: Allow, redact, block, rate limit or escalate, with the policy version applied.
• Approval: Approver identity, decision time and any stated reason for escalated calls.
• Outcome: Whether the message was sent, and what was changed by redaction.

Where Trussed fits

Trussed is the point in this design where policy is enforced on MCP tool calls. It sits in the execution path, so a Mail Send call is evaluated at runtime, not reviewed after the fact. Trussed can allow, redact, block, rate limit or escalate a call for human approval, at the level of the individual tool call. Enforcement generates audit-ready evidence of each decision, and deployment is self-managed in the customer cloud with configurable retention and data residency.

Trussed does not replace the identity, permission and tool-configuration work above. Those layers reduce what the agent can attempt, and runtime enforcement decides what is actually allowed to leave. A regulated enterprise needs both, along with a clear owner for each.