Email MCP Authorization Boundaries: A Security Checklist

An email MCP connection can expose several actions—reading, drafting, sending, deleting—but a working connection alone does not prove that each action is authorized. The key review is the boundary between the client, the MCP server, and the mail provider.[3]

This checklist focuses on that protocol-level boundary. It is not another email-provider comparison; see email API vs. inbox API for the mailbox choice and safe AI-agent tool access for the wider connector model.

1. Map each credential to its owner

Before connecting a real mailbox, record the MCP client, server and transport, authorization issuer, mailbox account, requested permissions, and revocation owner. Separately identify the credential the client presents to the MCP server and any credential the server uses with the mail provider.[2]

Do not treat “connected” as a blanket grant. Know which identity each credential represents and which system enforces its permissions.[2]

2. Confirm the deployed authentication path

MCP authorization is optional.[1] For HTTP-based implementations that support it, the specification describes the MCP authorization flow.[1] STDIO implementations should not reuse that HTTP flow; they should obtain credentials from the environment instead.[1]

Check the deployed transport and auth configuration, not just the setup guide or a successful tool listing.[1] For a local process, review the executable, package version, process owner, environment variables, and update path.[2] For remote HTTP, verify the server origin and the issuer/account actually selected.[1]

3. Validate what an HTTP token is for

In the MCP HTTP authorization flow, the client must identify the intended MCP server as the resource, and the server must validate that a presented token was issued for it.[1] Access tokens must not be placed in a URI query string.[1]

Test the boundary with a token issued for a different resource; the MCP server should reject it.[1] Also check that tokens are not written into URLs, application logs, or diagnostic output.[2]

4. Do not forward the client token to the mail API

If the MCP server proxies requests to an email provider, do not pass the client’s bearer token through unchanged. MCP’s security guidance calls token passthrough an anti-pattern, and the authorization specification says MCP servers must not accept or transit tokens not issued for the MCP server.[1][2]

Trace the provider-side credential separately.[2] Confirm the account it represents, the permissions it carries, and whether the provider independently rejects an unauthorized operation.[2] Test a missing or invalid provider permission instead of assuming the MCP client’s login covers the downstream call.[2]

5. Treat tool discovery as inventory—not authorization

The MCP tools interface returns tool names, descriptions, and input schemas; a server may also signal that its tool list changed.[3] Save a tools/list snapshot during deployment review and compare it before enabling a changed or newly added tool.[3]

A listed tool is discoverable, not automatically authorized.[3] Keep action policy at the server or provider boundary; hiding a tool in one client or asking the model not to call it is not a substitute.[3][4] OWASP identifies excessive functionality, permissions, and autonomy as contributors to excessive agency.[4]

6. Run negative tests before enabling mail

Use a test account and verify that:

1. A token intended for another resource is rejected by the MCP server.[1]
2. A disabled or unauthorized email action is rejected even when a client attempts a direct tool call.[3][4]
3. An invalid or over-broad client token is not forwarded to the provider as authority.[2]
4. Confirm the documented revocation behavior and test when access actually stops.
5. No bearer token appears in a URL, log, or exported diagnostic.[1][2]

Record the server version, transport, account identity, tool-list snapshot, policy decision, test result, and provider response.[1][2][3] Redact secrets and avoid retaining message bodies unless there is a defined business need.

Before go-live, the owner should be able to answer: Which identity does each credential represent? Which server validates it? Which actions are allowed? How is access revoked? Which negative tests passed? If any answer is unknown, keep the integration in a test environment. For a broader email-agent workflow, see the email-agent build guide.

Sources

[1] https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization — MCP Authorization Specification [2] https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices — MCP Security Best Practices [3] https://modelcontextprotocol.io/specification/2025-11-25/server/tools — MCP Tools Specification [4] https://genai.owasp.org/llmrisk/llm062025-excessive-agency — OWASP LLM06:2025 Excessive Agency

Explore Neuro OS →