Model Context Protocol (MCP) servers give AI agents standard access to the enterprise systems where data lives, including code repositories, databases, and cloud consoles. A developer can connect one to Cursor or Claude Desktop by editing a JSON configuration file, often without a procurement step.
MCP server security best practices exist because that convenience carries privilege. An agent reaching an MCP server uses the access granted to that server, at machine speed, and often outside the visibility of legacy security controls that rely on packets, keywords, or regex rather than understanding conversational context and intent.
If you’re already fielding developer requests to hook up new agents, you’ve probably seen how quickly that access spreads. Controls for tool descriptions and endpoint authentication help keep a productivity integration within its intended data boundaries. Treated as part of an enterprise AI governance program, the practices below close that gap across employees and agents.
Key takeaways
- MCP server security best practices span identity, server access, runtime tool invocation, and durable audit trails because agents can trust poisoned descriptions and inherit broad server privileges.
- Ten core practices reduce MCP risk: inventory connections, enforce least privilege, prohibit token passthrough, approve servers, vet the supply chain, re-verify tools at runtime, sandbox execution, require human checkpoints, monitor for drift, and preserve attributable audit trails.
- Authentication and discovery must reflect the transport: HTTP servers should follow OAuth 2.1 guidance, while local stdio servers rely on environment credentials and require configuration-file inspection because network controls can’t see them.
- Effective governance depends on linking every agent action to a human identity, supporting regulatory evidence, risk reviews, and decisions about moving agent pilots into production.
What is MCP server security?
MCP server security controls what an AI agent can discover, invoke, and extract through a Model Context Protocol server. Anthropic open-sourced MCP as a standard for connecting AI assistants to content repositories and development environments. The specification defines three MCP architecture roles: a host application, client, and server.
Through runtime capability discovery, an MCP server advertises its capabilities, and the model reads those natural-language descriptions to decide what to invoke. The specification warns that tools can execute arbitrary code and require appropriate caution.
Effective MCP security requires governance across four control layers. They cover the identity and scopes an agent holds, the servers it may connect to, what happens at tool invocation, and what record survives afterward. The NSA’s May 2026 design guidance notes that MCP authorization is optional. The specification itself acknowledges protocol enforcement limits and says that MCP “cannot enforce these security principles at the protocol level.”
You Can’t Secure What You Can’t See
WitnessAI gives you network-level visibility into every AI interaction across employees, models, apps, and agents. One platform. No blind spots.
Explore the PlatformWhy MCP servers widen the enterprise attack surface
MCP risk comes from two places: the tool descriptions and outputs a model trusts, and the privileges a server holds when the model acts on them. Keyword-based DLP and CASB proxies weren’t designed to match either pattern, so standard perimeter controls miss most MCP abuse until it shows up in downstream systems. The two subsections below take each source in turn, starting with the inputs the model reads and then the traffic paths security teams rarely see.
- Tool descriptions and tool outputs are attacker-controlled input: The MCPTox benchmark recorded an average tool-poisoning success rate of 36.5% across 45 live MCP servers and 20 models. Researchers have also shown that a tool description can be quietly modified after approval, so the agent then collects and exfiltrates data while each individual action still appears authorized.
- Agents inherit server privileges in traffic security teams rarely inspect: A developer adds a server to an IDE configuration file, and the agent inherits that server’s permissions, often a service account broader than the developer’s own. Local agents often use stdio transport, which generates no network traffic for a proxy to inspect, and the protocol prioritizes interoperability and ease of use through flexibility.
These two gaps mean an MCP server can quietly expand both what an agent is told to do and what it’s allowed to do, which is why the practices in the next section have to cover inputs, permissions, and audit trails at the same time.
Your Employees Use 5x More AI Tools Than You Think
WitnessAI scans your entire network to catalog every AI app, agent, and conversation. No endpoint clients or browser extensions are required.
See How Observe WorksMCP server security best practices for enterprise risk management
The ten practices below help organizations securely scale agent adoption by combining governance, runtime protection, and operational controls. Start with visibility and identity, then layer on runtime controls and durable audit trails.
1. Inventory MCP servers and agent sessions before writing policy
You’ll struggle to assign an owner or budget line to a connection you haven’t recorded. Catalog the MCP servers and exposed tools in use, along with each agent that connects to them. Agentic sessions advertise the tools they can reach in their traffic, which gives security teams a detection point independent of a developer request.
Pair the traffic view with a scan of IDE and desktop configuration files, because local stdio servers stay off the network. The CSA’s agentic adoption guidance advises teams to conduct these reviews through existing architecture review boards so a new MCP connection gets the same scrutiny as any other integration. The output is a living catalog with an owner, a scope, and a data classification for every server.
2. Scope agents to tool-level permissions and forbid token passthrough
Token passthrough risk begins with lost attribution. A forwarded token can make an agent’s action difficult to trace to the person who triggered it, and the downstream API may not be able to identify who is calling it.
Per-tool scopes matter: a tool that reads files should not receive file-deletion scope, and a tool that reads customer records should not receive write scope on the same table. The MCP specification prohibits passing the client’s token straight through to downstream APIs, so each agent should carry its own credential rather than borrow a user’s. Issue each agent its own credential, scope it to the minimum set of tools it needs, and rotate it on the same cadence you use for service accounts.
3. Authenticate every MCP server based on its transport
Authentication requirements follow the transport, not the network location. Servers reachable over HTTP, including those on internal subnets, should follow the specification’s OAuth 2.1 guidance with PKCE and validate token audience so a token issued for one server can’t be replayed against another.
Local stdio servers rely on environment credentials rather than protocol-level authentication, which is why configuration-file review matters. Internal placement alone doesn’t stop a poisoned tool description or a confused-deputy call, so pair authentication with per-tool scopes and AI runtime inspection of the traffic each agent generates.
4. Maintain an approved server registry and fail closed on the rest
An unlisted MCP server can become an unbudgeted, uncontracted third party with production access. Approved MCP servers belong in one catalog with documented owners and scopes that reflect data boundaries.
Configure servers outside that catalog to fail closed so a developer adding an unreviewed entry to a config file doesn’t quietly extend the agent’s reach. Publish the approval path alongside the registry so teams know how to get a new server added instead of routing around the process.
5. Vet the supply chain before onboarding a server
Treat every new MCP server as a third-party dependency, because that’s what it is. Review the maintainer, source repository, release history, and permissions the server requests before it reaches an approved registry.
In September 2025, a package impersonating Postmark’s email integration added a hidden BCC line that forwarded outbound email to an attacker. Pin server versions, verify signatures where the publisher provides them, and subscribe to advisories for the servers you approve so a compromised release doesn’t ship into production on the next agent restart.
6. Re-verify tool definitions at runtime
A tool approved in review can behave differently in production. Whoever owns the customer relationship carries the consequences, so the check has to run every time the tool is called, not just at onboarding.
OWASP’s MCP security cheat sheet lists “Assume a tool approved yesterday is the same tool today” among the things not to do. Lock approved tool versions and signed schemas at installation, then monitor descriptions for changes and screen tool calls and returned content for injected instructions. A description that shifts between calls should raise an alert and, depending on sensitivity, block the invocation until a human reviews it.
7. Sandbox tool execution and constrain outbound traffic
An MCP server that can reach the open internet from a production subnet can also exfiltrate data from it. Run servers in isolated environments with allow-listed egress so a compromised tool has nowhere useful to send stolen data.
Restrict filesystem access to the directories the tool needs, drop unnecessary OS capabilities, and separate the execution environment from the calling user’s credentials. If your platform team already runs a container standard, apply the same baseline to MCP server workloads instead of building a parallel one.
8. Put a human checkpoint in front of irreversible actions
Read-only, observation-tier agents should start with access to defined data sources only. Gartner’s May 2026 guidance predicts 40% of enterprises will demote or decommission autonomous agents by 2027 over governance gaps found only after production incidents.
Require review before a tool call changes data, moves money, sends external communication, or grants access. Alert an owner, present the arguments the agent intends to submit, and proceed only after approval. For high-frequency workflows, define allow-listed parameter ranges so routine calls flow through while anything outside the envelope escalates to a human.
9. Monitor for drift, prompt injection, and anomalous tool use
Static approval is not enough once agents run at machine speed. Baseline the normal call patterns for each agent, including which tools it uses, in what sequence, and against which data, then alert on deviations.
Inspect tool inputs and outputs at runtime for indirect prompt injection, because a malicious document or ticket can hijack an otherwise well-behaved agent. Feed anomaly signals back into the approval registry so a tool that repeatedly triggers alerts loses its approved status until a human reviews it.
10. Keep audit trails that trace each agent action to a human identity
Define a minimum audit trail entry for each tool call: agent identity, user identity, tool name, sanitized arguments, returned content summary, and timestamp. Store it append-only and apart from the systems being monitored, because separating audit trails from the servers they describe preserves their integrity if a server is compromised.
Without attribution, teams may not have a clear audit trail or the evidence needed for review. That gap matters under HIPAA 164.312(b) audit controls, while the OWASP Agentic Top 10 treats repudiation and untraceability as a distinct threat. Retain the trail for the period your regulators require and test the retrieval path before an auditor asks for it.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlGoverning MCP connections as adoption grows
Governance increasingly determines whether agentic AI initiatives successfully move from experimentation into enterprise production, and MCP server security is where that evidence takes shape. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 over cost and complexity, with risk concerns among those factors.
If you’re the person answering board questions about agent risk, the practices above are where the evidence comes from. Projects are more likely to survive when a risk committee has a current inventory, per-tool scopes, an approved registry, runtime checks, human checkpoints, and an attributable audit trail to point to. That evidence helps the board understand how the program keeps agent actions within approved boundaries, and it’s often what moves a pilot into production.
WitnessAI gives you visibility into MCP servers, agents, human identities, and runtime tool activity, combined with policy enforcement and runtime protection, with the policy controls and audit trails your risk committee is asking for. See how the platform fits alongside the practices in this guide.
Runtime AI Threats Need Runtime Defense.
WitnessAI’s enterprise AI firewall delivers bidirectional runtime defense, blocking prompt injections, jailbreaks, and data exfiltration before they reach your models or your customers.
Explore Protect