MCP Security: Risks Your AI Agent Inherits

MCP security keeps the tools your AI agent reaches through the Model Context Protocol (MCP) from being turned against you. Each connection runs through a program called an MCP server, so any flaw or planted instruction there becomes your problem. Key risks include hidden commands in a tool’s replies, harmful changes after approval, and requests sent anywhere without checks.

Your developers can plug a new tool into your AI in an afternoon, often using a server copied from GitHub that nobody else has reviewed. From then on, that code shares your agent’s access to data and actions. In 2026, even Google and JPMorgan Chase had to fix the same flaw in MCP software their own engineers built, and someone tried to sneak a malicious server into 23 AI projects in 74 minutes.

During AI agent testing, QAwerk specialists probe every connection the way an intruder would. Our Bug Crawls, where we test popular apps and publish what we find, show why that matters. On Otter.ai, an AI meeting assistant, one typed question got the chatbot to list its internal tools and their settings, handing an attacker a map of where to aim. Everything in this article comes from that work, so you’ll know what to ask before your agent connects to its next server.

What Does MCP Security Protect?

MCP security protects the data, actions, and credentials your agent gains from every connection. Underneath, MCP is an open standard that lets AI connect to outside tools in a common way. For example, once you add a calendar server, your agent can suddenly read meetings, send invitations, and act through the account’s login.

Each new MCP server can hand your agent three kinds of access:

• Data: Everything the server can read, from customer records to internal documents
• Actions: Everything the server lets the agent do, such as sending messages, editing records, or running commands
• Credentials: The passwords and access keys the server holds to reach other systems

Whoever controls a server, or slips instructions into its replies, can reach all three through your agent. How much access any agent should have across all its tools is a wider question, covered under agentic AI security.

What MCP Security Risks Come with Each New Server?

Most MCP security risks trace back to a server your team trusted without checking. The Open Worldwide Application Security Project (OWASP), a nonprofit whose checklists are widely used across the industry, now publishes a separate top 10 for MCP, still in beta. Most of the risks below appear on that list:

• Orders hidden in tool replies: An agent reads whatever a server sends back, whether that’s a web page, an email, or a database entry. If an attacker planted instructions in that content, the agent may follow them as though they came from you. This attack is called indirect prompt injection, and tool replies are one of its easiest ways in.
• Servers that change after approval: A server can pass review on day one and rewrite its own instructions later. The section on MCP tool poisoning below explains how that trick works.
• Servers that fetch any address: Many servers download pages or call other services for the agent. Without a check on the destination, an attacker can steer the agent into making the server contact internal systems.
• Connections with too much power: A server built to read files might also be able to delete them or send them elsewhere. Agents take the shortest route a connection allows, as one developer learned when an AI booking assistant cancelled another member’s reservation to free up a gym class spot.
• Unknown servers: Developers sometimes add servers on their own, without telling the person who approves tools. OWASP calls these shadow MCP servers, and nobody can check a connection they don’t know exists.
• No record of tool calls: Without logs, nobody can tell afterward what the agent asked a server to do or what came back.

How One Planted Instruction Travels Between Agents

Hidden orders in tool replies get harder to trace when agents work in teams. Many products use an orchestrating agent, a coordinator that splits a job and hands each piece to a specialist subagent. Independent security researcher Syed Anas Mohiuddin calls the resulting attack protocol pivoting. The chain runs in three steps:

1. An attacker plants text in content that an MCP tool will return. The text is written to look like a task request in the format agents use to message each other.
2. The orchestrating agent reads the tool’s reply and passes the task along. To the orchestrator, the planted request looks like ordinary work.
3. A subagent carries out the task. Because the request arrives from the orchestrator, the subagent has no reason to question where the order started.

By the last step, no agent in the chain can tell that an outsider wrote the instruction. Handoffs fail in plenty of other ways too, as our breakdown of testing multi-agent AI systems shows.

MCP Tool Poisoning: When a Trusted Server Changes Its Mind

MCP tool poisoning is an attack that hides instructions in a server’s descriptions, the short notes that tell an agent when and how to use each feature. People rarely read them, yet the AI treats every line as guidance. As a result, poisoned notes can steer the agent toward secrets or change how other tools behave.

One of the hardest versions to catch is a delayed one, where a server behaves well during review, earns approval, and only then rewrites its own descriptions. On August 10, 2026, someone tried exactly that at scale. In a campaign reported by the firm Pillar Security, 23 pull requests, or proposed changes to a project’s code, reached 23 AI projects on GitHub within 74 minutes. Each proposal aimed to add the same malicious MCP server.

According to OWASP’s quarterly exploit roundup, the server behaved normally for its first three tool calls. After the third call, it rewrote its own tool descriptions to steer the connected agent toward the most valuable files on a developer’s computer:

• SSH keys, which unlock remote servers
• Login credentials for Amazon Web Services cloud accounts
• The history of commands typed into the computer, which sometimes contains passwords
• The settings file that controls a company’s Kubernetes server clusters

The server never opened those files directly. Instead, it used the trusted agent to collect them and tried to hide the activity from the people running the system.

None of the pull requests were merged, and OWASP reports no confirmed compromise. Even so, a server that passes one inspection can still turn hostile later. To guard against that, OWASP advises recording each server’s tool descriptions at approval and requiring a new review whenever they change.

Why Google and JPMorgan Chase Shipped the Same MCP Flaw

Many MCP servers fetch web pages or call other services at whatever address the agent supplies. If the server never checks the destination, anyone who steers the agent can reach systems meant to stay private, such as a company’s internal network. This weakness is called server-side request forgery (SSRF).

In 2026, Google, JPMorgan Chase, Weaviate, France’s digital agency, and an Indonesian city government all made this mistake, because checking every outgoing request is an easy step to skip. Security researcher Syed Anas Mohiuddin reported it to all five teams, which share no code or owners, and each has since fixed it:

• Google: MCP Toolbox for Databases, rated high severity at 8.0 out of 10 (CVE-2026-14540)
• JPMorgan Chase: An open-source server for searching documentation
• Weaviate: The database company’s connector to Google services
• DINUM (France’s digital agency): The official server for the country’s national open-data platform
• Tangerang (an Indonesian city government): A security monitoring server that claimed protection against SSRF but blocked only raw numeric addresses

According to TNW, five more MCP servers run by a US federal office, including one for Veterans Affairs benefits claims, were still awaiting fixes in October. No data exposure has been confirmed.

Even a server from a famous brand needs its outgoing requests tested before your agent relies on it.

What to Check Before Your Agent Uses an MCP Server

Good MCP security means handling every server like any outside code your product relies on. What you can check varies with the source:

Either way, every statement below should be true before your agent starts using the server:

• You know who maintains the server. A named owner, recent updates, and a way to report problems mean fixes will actually reach you.
• The server reaches only the addresses it needs. During API testing, requests to internal systems and unexpected destinations should fail every time.
• The connection grants only what the task requires. A support agent that looks up orders can’t issue refunds, and read-only access is the default wherever possible.
• The server holds its own narrow credentials. Its access keys expire quickly and open nothing beyond the server’s job.
• Tool descriptions are recorded at approval. Any later change triggers a fresh review before the agent uses the server again.
• Tool replies count as information, never as orders. Testers have planted instructions in content the server returns and confirmed that the agent ignores them.
• A person approves risky actions. The agent can’t make payments, delete records, or message customers until someone on your team says yes.
• Every tool call is logged. You can see afterward what the agent asked for and what came back.
• Someone outside the build team has tested the connection. Developers confirm that a server works, while an independent tester checks how it behaves when someone tries to break it.

When a connection reaches customer records or money, this list becomes the starting scope for AI penetration testing. In that kind of test, specialists attack the agent and its servers as a real intruder would. Our engineers map every server your agent can call, test each one against every item above, and hand your team a report of what holds and what needs fixing before launch.

Not sure how safe your agent’s connections are? Talk to our security team.

FAQ

Is MCP secure?

MCP security comes down to the servers you add, since MCP itself is only a common standard that lets AI agents use outside tools. The protocol doesn’t check whether a connected tool is honest or well built. That job falls to the team approving each connection, so an agent is only as safe as the least-tested server it relies on.

Should I use third-party MCP servers?

Yes, as long as you vet a third-party MCP server the way you would vet a new software vendor. Look for an active maintainer, a public history of fixes, and clear documentation of what it can access. Grant the smallest set of permissions that still gets the job done, and review the setup after every update, because an approved server can change its behavior later.

How do you secure an MCP server?

Securing an MCP server takes several layers of protection, and three matter most. Start by limiting access, so the connection reaches only the systems and actions its job requires, using keys that expire quickly. Logging every request and reply then lets your team see exactly what the AI agent did. The last layer is an outside test, where specialists try to slip hidden commands into data the server returns.