Quick answer: The Model Context Protocol, MCP for short, is an open protocol that connects an AI model to external tools, files and data sources through a standard interface. Because MCP servers hand the model real capabilities, a flaw in an MCP server turns directly into abuse of the model. The most critical flaws are hidden instructions embedded in tool definitions (tool poisoning), one tool abusing another tool's privilege (confused deputy), overly broad access permissions and secrets leaked during tool calls. DSET runs MCP server penetration testing with its local AI engine KAOS and verifies every finding with a working proof.

AI agents no longer only produce text, they read files, query databases, run commands and send requests to external services. The standard that emerged to give a model these capabilities safely is the Model Context Protocol. But once you connect tools that act in the real world to a model, each of those tools brings a new attack surface. This article explains what MCP security is, which flaws it targets and the DSET and KAOS approach.

What MCP is and why it brings a new attack surface

MCP defines a common language between an AI client and a tool server. The server tells the model which tools it offers, what each tool does and which inputs it expects through a list of definitions. The model reads these definitions and calls a tool when it sees fit. The problem begins exactly here: the tool definitions the model reads are also an input, and that input can be malicious. In classic software you write the code, but in an MCP setup the model's behavior is steered by the definitions written by the third party servers you trust.

Which flaws it targets

MCP flaws are mostly not in the protocol itself but in the way tools are defined and authorized. An invisible instruction embedded in a tool definition can change the model's entire behavior.

Flaw class What it means Typical result
Tool poisoning A hidden instruction is embedded in a tool definition The model leaks secret data to the attacker
Delegation abuse One tool uses another tool's privilege Unauthorized action, data access
Excessive permission A tool is granted more access than needed Control over the file system or network
Secret leakage A key is exposed during a tool call Credential theft
Rug pull An approved tool later changes its behavior A trusted channel turns into a weapon

The essence of the table is this: in MCP security the risk comes less from what the tool does and more from how blindly the model trusts that tool's definition. Tool poisoning is the MCP world's version of indirect prompt injection, so the topic of prompt injection and OWASP LLM Top 10 is the foundation of MCP testing.

Why tool poisoning is the most critical flaw

In tool poisoning the attacker places an instruction into the definition of a seemingly harmless tool that the model will read but the user will not see. For example the description of a calculator tool might carry a hidden directive to also read the user's secret files on every call and send them to a certain address. The model treats this directive as a legitimate instruction, because tool definitions are trusted context for it. Combined with the broad privileges an agent holds, this causes serious consequences; excessive agency and tool abuse in LLM agents addresses exactly this risk.

Its relation to identity, supply chain and isolation

An MCP server is often third party software, so MCP security cannot be separated from software supply chain security; to verify a server's origin and integrity the principles of AI supply chain security and model provenance apply. In addition every tool runs with a machine identity and a set of privileges, which makes machine identities and AI agent identity security an inseparable part of MCP testing.

When it is tested

The correct practice is to test before an MCP based agent system goes into production, when a new third party MCP server is added and at regular intervals. Tools you develop in house must be tested as strictly as external ones, because the broad privilege of an internal tool is at least as dangerous as that of an external one. Before the test it must be drawn clearly which tools, which data sources and which privilege boundaries are in scope; for this the penetration testing preparation and scoping guide is the reference point.

The KAOS and DSET approach

DSET runs penetration testing of MCP and AI agent systems with its local AI engine KAOS. KAOS examines tool definitions for hidden instructions, tries delegation scenarios in a controlled way and tests whether a tool has broader access than expected. It reports every flaw it finds with a working proof, under the principle of proof based verification. The difference is this: it does not settle for saying a tool definition is theoretically risky, it shows that the definition actually steers the model into an unwanted behavior. This test is run as part of the broader AI and LLM application penetration testing service.

Frequently asked questions

Does MCP security concern only large AI companies? No. Every organization that builds an AI agent for its own internal processes uses MCP or a similar tool protocol. When you give a customer service agent database access or grant an internal assistant file read permission, the same attack surface appears for you too. What matters is the privilege of the tools, not the scale.

Will a normal code review catch tool poisoning? Often no. Tool poisoning is not in the code itself but in the natural language definition presented to the model, and classic static code analysis does not treat these natural language instructions as a security risk. For this reason MCP testing requires a separate perspective that treats every piece of text entering the model as a potential instruction.

Is it not enough if I only use trusted MCP servers? A trusted source is an important first step but is not enough on its own. A server you trust can later be updated and change its behavior, which is called a rug pull. For this reason server versions must be pinned, their integrity must be verified and their behavior must be tested regularly.

Sources

To examine your AI agents and MCP based tool infrastructure with a proof based test, contact DSET. We provide MCP and AI agent penetration testing and consulting from our Ankara Hacettepe Teknokent laboratory.