How should you secure an MCP server before connecting it to company data?

Start with the action the tool can take

A tool called search_customer can sound harmless. Its real authority depends on which customer records it can read, whether it can export a full result set, and what a later tool can do with the answer. Map a complete request from the person or service that asked for it through the agent, MCP client, server, downstream API and stored record. Mark every point where data or authority changes hands.

Create a small inventory before adding credentials: tool name, input fields, data class, downstream identity, maximum result size, side effects and owner. Separate read-only discovery from actions that change records or contact people. A server that offers both should not acquire the permissions of its most powerful tool for every request. The NSA's MCP guidance highlights access control, execution isolation and audit gaps that implementers must address.

Evidence: NSA: MCP security design considerations

Verify identity and audience at the server

For a remote server, validate a token's issuer, audience, expiry and intended resource before a tool runs. Then derive the caller's tenant and permitted actions from trusted claims and your own policy store. A user-supplied account ID is a lookup key, not proof that the caller owns that account. Avoid forwarding a broad upstream token to a downstream service just because both speak OAuth; use a token intended for that service and the requested operation.

The July 2026 MCP release tightened authorization around issuer validation and credential isolation. Those protocol changes help the client/server authorization flow, but they do not decide which company record a particular user may read. Keep that business authorization in the server and downstream API, and test it independently of the model's instructions.

Evidence: MCP project: July 2026 specification release · MCP Apps: Authorization

Put policy in the tool handler, not the prompt

A prompt can tell an agent to use a tool responsibly; it cannot enforce a permission. Check the actor, action, resource and current approval state inside the handler. Reject requests for another tenant, excessive date ranges, unbounded exports and write actions outside the assigned workflow. Validate parameters against a strict schema and apply downstream limits even after the tool has been authorized.

Consider a hypothetical support assistant allowed to retrieve one customer's latest invoice. It should be able to fetch that invoice for an authenticated support session, but a request to enumerate all invoices must fail. If it also drafts a refund, a separate human approval should be required before the refund API is called. The model may suggest the next step; the policy engine decides whether it can occur.

• List every tool's data scope and side effects.
• Deny cross-tenant, bulk-export and unexpected write requests.
• Require explicit approval for consequential actions.
• Rate-limit expensive or recursive calls.

Evidence: NSA: MCP security design considerations · MCP Apps: Authorization

Rehearse denials and make the path auditable

Record the authenticated actor, tool, resource class, policy decision, correlation ID and outcome. Keep sensitive payloads out of ordinary logs unless there is a defined need, access policy and retention period. A useful audit trail can reconstruct why a tool was denied or why a permitted action changed a record; a raw transcript alone may expose private data without answering either question.

Before release, run negative tests with expired and wrong-audience tokens, a different tenant's identifier, manipulated tool parameters, repeated write requests and instructions embedded in retrieved content. Confirm that no downstream write occurs after a denial. Start with a limited data set and an operational switch that can disable the server or individual high-risk tools. A green happy-path demo is evidence of connectivity, not evidence of containment.

Evidence: NSA: MCP security design considerations