Securing MCP Servers And Tool Access.

MCP servers give AI agents their hands. The Model Context Protocol (MCP) is an open standard that lets agents use outside tools and data. The MCP specification opens its security section with a plain statement: MCP "enables powerful capabilities through arbitrary data access and code execution paths". It adds that "tools represent arbitrary code execution and must be treated with appropriate caution".

Every tool you connect widens what a manipulated agent can do. OWASP lists MCP among the interfaces that form part of the agentic supply chain (ASI04), and MITRE ATLAS covers poisoned tools, including MCP servers, as AML.T0110 AI Agent Tool Poisoning. See top threats to AI agents for the wider map. This article follows the current specification, version 2026-07-28, and its Security Best Practices page.

That last row comes from the specification itself. It says MCP cannot enforce these principles at the protocol level, so implementors are asked to build consent and authorization flows, document security implications and apply access controls.

The authorization page says authorization is optional, but HTTP transports should follow it. Stdio transports should not. They should take credentials from the environment instead. Four rules matter most.

• Check the audience. Servers must validate that access tokens were issued specifically for them. Invalid or expired tokens must get an HTTP 401.
• Never pass tokens through. Servers must not accept or transit any other tokens. The best practices page names token passthrough as an anti-pattern: it lets requests bypass rate limits, validation and monitoring, and it makes auditing and incident investigation harder.
• Keep tokens out of URLs. Access tokens must not be placed in the URI query string. Clients must keep refresh tokens confidential in transit and storage.
• Bind to the resource. Clients must send the resource parameter, naming the MCP server, in both authorization and token requests.

Treat the agent's login like any other non-human identity: give it its own scoped credential, not a shared admin key. Tokens and agent identities are covered in AI agent identity and access.

The Security Best Practices page lists eleven sections. These five are the ones teams hit first.

1. Confused deputy. A proxy in front of a third-party API can be tricked into handing an authorization code to an attacker. The fix is per-client consent, with exact redirect URI matching and a random, single-use state value.
2. Server-side request forgery (SSRF). A malicious server can put internal addresses, such as a cloud metadata address, into the URLs a client fetches. Block private ranges, require HTTPS and use an egress proxy. The page adds: avoid implementing IP validation manually.
3. State handle hijacking. This version has no protocol-level sessions. Servers must not treat possession of a state handle as authentication, and should bind handles to the verified user on the server side.
4. Local server compromise. A malicious startup command can run code on a user's machine. One-click setup must show the exact command and get explicit approval, and local servers should run in a sandbox with minimal privileges.
5. Scope creep. Wildcard scopes such as "files:*" or "admin:*" enlarge the blast radius of a stolen token. The spec recommends a minimal first scope, then step-up challenges for more, and logging each elevation.

Example (illustrative). Acme, at acme.com, runs an internal MCP server for its ticket system. The first token gets a scope for reading tickets only. When an agent asks to close a ticket, the server returns an insufficient scope response, the client asks the user, and the server logs the step-up with a correlation id. A stolen first token can read tickets, not close them.

The specification also tells hosts what to do. Hosts must obtain explicit user consent before invoking any tool, and before exposing user data to servers. It also says descriptions of tool behavior, such as annotations, should be considered untrusted unless they come from a trusted server. A tool description is text the agent reads, so a bad one can steer the agent. This is prompt injection through a different door.

OWASP's Excessive Agency guidance (LLM06:2025, 2025 edition) adds three habits: minimize extensions and their functionality, avoid open-ended extensions, and execute extensions in the user's context, with user approval for high-impact actions. Apply least privilege to each tool, and review the checklist in human in the loop and least agency.

When agents call other agents instead of tools, see securing multi-agent systems and agent-to-agent communication.

A practical pattern to compare against is how the Brandefense MCP server is described. Users sign in with their Brandefense account, read-only tools run directly, tools that change data ask the user to confirm in the chat, and a tool can only do what the user's own role allows. This describes one design. It is not a claim of compliance with the specification.

Use this checklist for every MCP server you build or connect.

Then write the rules down. The AI agent governance policy template has a place for tool approval, and monitoring and logging for AI agents shows what to record. For security teams that connect agents to threat data, see agents in the SOC and threat intelligence, done safely.