An MCP connection is a way to expose capabilities, not a reason to trust every operation it offers. Before connecting an authentication analyst, specify which tenant it may inspect, which evidence it may retrieve and which actions remain unavailable. A report-reading assignment should not inherit DNS publishing simply because one server offers both tools.
Start with the actual data path
Map the host application, MCP client, server, report store and any downstream API. Record where tokens terminate and which organisation operates each component. The MCP authorization specification describes authorization for HTTP-based transports; do not assume its flow applies unchanged to local stdio servers. A local executable can have filesystem or environment access even without a remote OAuth exchange.
Separate report retrieval from raw-message retrieval. Aggregate counts may answer a sender-trend question without disclosing message subjects, recipients or attachments. Enforce tenant isolation on the server using authenticated context rather than accepting a model-supplied tenant name as authority. Return stable source identifiers so a summary can be traced back without exposing unrestricted storage URLs.
Limit credentials and tool reach
Use credentials with the minimum supported resource and action scope. Keep secrets in the approved credential mechanism, not in prompts, tool descriptions, report fields or logs. The MCP security guidance prohibits token passthrough: a server must not simply accept and forward an upstream token meant for another service. Validate intended audience and implement the proper downstream authorization relationship.
Inventory every exposed tool, including generic HTTP, shell and file-writing functions. Hiding a DNS-specific button does little if a generic execution tool can call the same provider with a broad credential. Remove unnecessary capabilities at the execution boundary. Tool annotations and descriptive names can help clients present tools, but are not a substitute for enforced authorization.
Exercise hostile report content
For the written policy below, assume authenticated tenant A and an approved report-analysis task. Only read_report for tenant A is allowed. Report content asking for a secret or DNS publication cannot expand that permission. This is a proposed policy, not an executed security test or a verified server configuration.
Treat report text, message samples and server-returned instructions as untrusted evidence. A string claiming to be an administrator does not become an approver. The analyst can describe that string as suspicious without obeying it. OWASP recommends layered defenses because instruction wording alone does not eliminate prompt injection.
Inspect the complete decision ledger
- Known-owner case: tenant A, approved task, read_report for A. Allow under the proposed policy; calculation uses only approved returned evidence.
- Wrong-tenant case: authenticated A requests tenant B. Deny the read regardless of any tenant label in the report.
- Hostile-content case: report text requests read_secret and publish_dns. Deny both tools; authorized read_report for A may continue, with hostile text treated only as data.
- Ambiguous-owner case: an A report names both app-A and app-B as possible owners. Allow only authorized evidence gathering, mark identity unresolved and escalate attribution rather than choosing an owner.
- Unapproved-task case: no approved investigation exists. Hold task-driven retrieval until authorization is clarified, even if a credential technically permits a read.
No tool calls, model evaluation, credential issuance or boundary tests were executed for this ledger. These rules require implementation tests against the actual server and downstream permissions before anyone claims they are enforced.
Inspect operation and revoke access
Log tool name, authenticated tenant, evidence references and authorization result without copying tokens. Test access expiry and revocation, including active sessions and downstream permissions. A successful disconnect in a client is not enough if a long-lived provider credential remains valid elsewhere.
Start with a read-only pilot and an explicit list of questions the analyst should answer. Verify that refusals are useful: they should identify missing evidence or scope rather than silently omit a tenant or fabricate a result. Expand permissions only after a separate review of the new action. This is a proposed control pattern, not a verified EmailAuth product capability.