Source: https://cli.nylas.com/guides/mcp-email-server-security-checklist

# MCP Email Server Security Checklist

MCP email servers put private inbox data, untrusted message content, and external send actions in the same agent loop. This checklist gives reviewers a practical way to verify least privilege, local server safety, token boundaries, webhooks, and outbound controls.

Written by [Qasim Muhammad](https://cli.nylas.com/authors/qasim-muhammad) Staff SRE

Reviewed by [Caleb Geene](https://cli.nylas.com/authors/caleb-geene)

Updated May 14, 2026

> **TL;DR:** Treat an MCP email server as a privileged integration, not a chat add-on. Review the exact startup command, account grant, read tools, send tools, token handling, webhook signatures, and revocation path before giving an agent inbox access.

Command references used in this guide: [`nylas mcp status`](https://cli.nylas.com/docs/commands/mcp-status) for local configuration review, [`nylas mcp install`](https://cli.nylas.com/docs/commands/mcp-install) for assistant setup, [`nylas auth whoami`](https://cli.nylas.com/docs/commands/auth-whoami) for grant checks, [`nylas agent policy create`](https://cli.nylas.com/docs/commands/agent-policy-create) and [`nylas agent rule create`](https://cli.nylas.com/docs/commands/agent-rule-create) for connector-layer rules, [`nylas webhook verify`](https://cli.nylas.com/docs/commands/webhook-verify) for signatures, and the full [command reference](https://cli.nylas.com/docs/commands).

## Why is an MCP email server sensitive?

An MCP email server is sensitive because it combines private data, untrusted content, and external communication. That is the lethal trifecta pattern: an agent reads secrets in email, receives attacker-controlled instructions inside the same mailbox, and may have a send tool that can exfiltrate data.

The Model Context Protocol security guide calls out several risks that matter directly to email servers: confused-deputy OAuth flows, token passthrough, local MCP server compromise, SSRF, session hijacking, and over-broad scopes. Email raises the stakes because the input channel is adversarial by default. A message body can contain prompt injection, a calendar invite can carry instructions, and an attachment can try to steer the model. Start with the official [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices), compare the threat model with the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/), and use the [Nylas webhooks documentation](https://developer.nylas.com/docs/v3/webhooks/) for signature expectations before applying the checklist below to the email tool surface.

## How do you review the MCP startup command?

Review the MCP startup command before the assistant runs it. A local MCP server executes as a process on the user's machine, so the exact binary path and arguments are security-relevant. The MCP security guide says local server config can be abused with malicious startup commands.

The Nylas local server command is intentionally small: `nylas mcp serve`. Install helpers write that command into supported assistant config files, and `nylas mcp status` shows which clients are configured. During review, capture both the status output and the assistant config diff. A startup command that includes `curl`, `npx`, shell chaining, or a path outside the expected binary location deserves a separate 15-minute review before anyone runs it.

```bash
nylas mcp install --assistant claude-code
nylas mcp status

# Review the exact authenticated account before using tools
nylas auth whoami --json
```

## How do you limit the account an agent can use?

Limit the account by choosing the smallest mailbox that can complete the workflow. A support triage agent should not use a founder's personal inbox. A product-owned automation should use an Agent Account or a dedicated shared mailbox rather than a human mailbox with years of unrelated mail.

The first review command is [`nylas auth whoami`](https://cli.nylas.com/docs/commands/auth-whoami); it prints the active grant. The second is [`nylas auth list`](https://cli.nylas.com/docs/commands/auth-list); it shows other connected accounts that could be selected by mistake. If the agent should own its mailbox, create an Agent Account and attach a policy at creation time. That gives the automation a separate address, thread history, and rule set.

```bash
nylas auth whoami --json
nylas auth list --json

nylas agent policy create --name "MCP email policy" --json
nylas agent account create support-agent@yourapp.nylas.email --policy-id <policy-id> --json
```

## How do you minimize MCP email tools?

Minimize MCP email tools by splitting read, search, and write capabilities into separate approval tiers. An agent that only summarizes unread mail needs search and read tools; it does not need a send tool, attachment download, folder delete, or bulk update path on day 1.

The MCP security guide warns against wildcard or omnibus scopes because broad tokens increase compromise impact and hide audit intent. Apply the same rule to tool exposure. Start with 3 read-only checks: list recent messages, search by query, and read one message by ID. Add calendar list only when scheduling is required. Add send only after the team has reviewed confirmation behavior, logging, and a rollback path. This staged approach keeps the first agent launch under 5 tool families instead of an all-purpose mailbox session.

```bash
# Read-only smoke tests before exposing tools to the agent
nylas email list --limit 10 --json
nylas email search "urgent" --unread --limit 10 --json
nylas email read <message-id> --json
```

## Which 5 log fields should an MCP email server keep?

An MCP email server should keep 5 log fields for every sensitive action: timestamp, assistant client, grant identifier, command or tool name, and outcome. Those fields let reviewers reconstruct behavior without storing full message bodies, prompts, attachments, or access tokens in logs.

Keep logs useful but small. For read actions, record the message ID and whether the body was read, not the body itself. For search actions, record the query category if possible, not the full user prompt. For send actions, record the recipient domain, sender grant, approval source, and request ID. That gives incident responders enough context to answer "what happened in the last 24 hours?" without creating a second private mailbox in the logging system.

The log policy should be written before the first production run. If log retention is 30 days, say that. If message IDs are personal data under your policy, treat them accordingly. Security reviews move faster when retention, redaction, and ownership are decided in advance.

## How do you revoke MCP email access in 3 steps?

Revoke MCP email access in 3 steps: remove the assistant server config, revoke or switch the mailbox grant, and rotate any API key used by automation. Revocation should be tested before launch because a broken offboarding path becomes a production incident during a real investigation.

Local MCP makes the first step visible: remove the `nylas mcp serve` entry from the assistant client config and restart the client. The second step depends on ownership. For a human mailbox, remove or replace the grant. For an Agent Account, detach the policy, disable sends, or delete the account if the workflow is retired. The third step is key rotation when a shared API key was present in a CI job or desktop environment.

Write the revocation owner into the same runbook as the install command. The person who can approve a new MCP email server should also know who can shut it off within 15 minutes.

## How do you control send actions?

Control send actions outside the model prompt. Prompt instructions are useful, but a malicious email can tell the model to ignore them. Connector-layer rules and human confirmation make outbound controls visible in code review and harder for prompt injection to bypass.

For connected human mailboxes, require the assistant to show the recipient, subject, and body before send. For Agent Accounts, add rules to the policy attached to the account. The verified rule command below blocks inbound messages from a high-risk domain before they enter an agent reply loop. Use the same rule review process for outbound policies your application owns.

```bash
nylas agent rule create \
  --name "Block high-risk sender domain" \
  --trigger inbound \
  --condition from.domain,is,example.com \
  --action block \
  --priority 10 \
  --json

nylas agent rule list --all --json
```

The exact rule command surface is documented at [`nylas agent rule create`](https://cli.nylas.com/docs/commands/agent-rule-create). Keep action names limited to documented values such as `block`, `archive`, `mark_as_read`, and `mark_as_starred`.

## How do you handle tokens and secrets?

Handle tokens as service credentials, not prompt context. The MCP security guide says token passthrough is an anti-pattern and that servers must not accept tokens that were not issued for the MCP server. Email agents should never paste API keys, refresh tokens, or webhook secrets into chat.

For headless jobs, use [`nylas auth config --api-key`](https://cli.nylas.com/docs/commands/auth-config) from a secret manager. For local agents, rely on the CLI's credential store and inspect account state with `nylas auth whoami`. Logs should record 4 safe fields: command name, grant ID, message ID, and exit status. Do not log full message bodies, raw authorization headers, or webhook secrets. A 30-day retention window is enough for many debugging workflows; compliance teams can set a longer window in their own logging system.

```bash
export NYLAS_API_KEY="nyk_..."
nylas auth config --api-key "$NYLAS_API_KEY" --region us
nylas auth whoami --json
```

## How do you verify webhook-driven agents?

Verify webhook-driven agents with signature checks, duplicate handling, and bounded retries. Nylas webhook notifications use at-least-once delivery, so an agent that replies to inbound email must deduplicate events before sending a response.

The Nylas webhook docs say endpoints must verify signatures with the raw request body and the `x-nylas-signature` header. The CLI includes [`nylas webhook verify`](https://cli.nylas.com/docs/commands/webhook-verify) so a developer can test verification without reimplementing HMAC logic in the first pass. Store processed webhook IDs or message IDs with a 24-hour TTL to prevent duplicate replies after retries.

```bash
nylas webhook verify \
  --payload-file ./incoming-webhook.json \
  --signature "$X_NYLAS_SIGNATURE" \
  --secret "$WEBHOOK_SECRET"
```

## What is the launch checklist?

The launch checklist has 8 items: exact startup command, active grant, tool list, send confirmation, token storage, webhook verification, audit log fields, and revocation path. A reviewer should be able to verify each item in under 30 minutes.

1. Run `nylas mcp status` and capture configured clients.
2. Run `nylas auth whoami --json` and confirm the grant is intended.
3. Start with read-only tools before adding send.
4. Require user confirmation for recipient, subject, and body.
5. Store API keys and webhook secrets outside prompts.
6. Verify webhook signatures against the raw payload.
7. Log message IDs and command status, not full bodies.
8. Document how to remove the grant or uninstall the MCP config.

## Next steps

- [Give AI agents email access via MCP](https://cli.nylas.com/guides/ai-agent-email-mcp) - install local MCP for supported assistants
- [Stop your AI agent from going rogue](https://cli.nylas.com/guides/stop-ai-agent-going-rogue) - apply connector-layer containment patterns
- [Audit AI agent activity](https://cli.nylas.com/guides/audit-ai-agent-activity) - trace MCP and command activity for reviews
- [Test email webhooks locally](https://cli.nylas.com/guides/test-email-webhooks-locally) - verify webhook payloads and signatures before production
- [Full command reference](https://cli.nylas.com/docs/commands) - exact syntax for MCP, auth, agent rules, and webhooks