You’ve Secured Your AI Agents. But Can You Trust Their MCP Servers?

Organizations are investing considerable effort into securing their AI agents, assigning identities, restricting permissions, implementing data protection policies, and establishing governance over what agents can access and do. These are sensible precautions as agents take on more responsibility across enterprise systems.

But there's another part of the architecture that I suspect isn't receiving the same attention: the Model Context Protocol (MCP) servers connecting those agents to external tools, applications, and data sources.

An agent can have a properly configured identity, carefully scoped permissions, and comprehensive monitoring, yet still be manipulated into performing actions that weren't part of the original user's request. The problem isn't necessarily a compromised agent or failed authentication, but malicious instructions introduced through information the agent has been configured to process.

This is MCP poisoning, and it's something organizations need to account for as they move agents into production.

How MCP Poisoning Works

MCP provides a standardized way for AI applications to interact with external systems. An MCP server might expose tools that allow an agent to search SharePoint, retrieve service tickets, query databases, or perform administrative operations.

When an agent connects to an MCP server, it receives descriptions of the available tools, including their purpose and required parameters. The agent uses this information to decide which tools are appropriate for a particular request.

Unlike traditional integrations, where developers generally define the logic governing API interactions, AI agents can interpret natural-language descriptions and contextual information to determine what actions to take. If an attacker can manipulate that information, they may influence the agent's behavior without compromising its identity.

Poisoning can occur through malicious instructions embedded in tool descriptions, altered parameter definitions, or content returned by an MCP server. An attacker might publish a malicious server, compromise an existing integration, or manipulate information that a legitimate server retrieves from another source.

OWASP identifies tool poisoning as MCP03 in its MCP Top 10 project, describing how manipulated tool definitions and schemas can lead agents toward unintended actions. Its MCP Security Cheat Sheet also addresses malicious instructions delivered through tool responses.

In either case, the attacker is attempting to influence how the agent uses its legitimate capabilities rather than necessarily bypassing the security controls surrounding it.

Supporting reference: What is the Model Context Protocol? ↗

Supporting reference: OWASP MCP03:2025: Tool Poisoning ↗

Supporting reference: OWASP MCP Security Cheat Sheet ↗

Malicious returned content: a hypothetical service-desk incident

Consider an organization using an AI agent to support its IT service desk. The agent can search SharePoint for documentation, retrieve service tickets, and send updates through Microsoft 365. Its identity and permissions have been reviewed, and monitoring is enabled.

Now imagine an attacker gains access to a service ticket that the agent is expected to retrieve. The attacker cannot modify the MCP server itself but can alter the ticket's description.

Within that description, the attacker includes instructions directing the agent to retrieve a confidential SharePoint document and send it to an external address, presenting the action as a necessary troubleshooting step.

The MCP server is functioning exactly as intended. It retrieves the ticket and returns its contents to the agent, including the malicious instructions.

If the agent treats those instructions as part of its workflow rather than untrusted data, it may attempt to retrieve and send the document using its existing tools. Provided it has the necessary permissions and no independent controls prevent the transfer, the action could succeed without triggering an authentication or authorization failure.

The logs might show an authenticated agent retrieving a document and sending an email through approved services, even though neither action was part of the original user's request.

This hypothetical example illustrates why an MCP server doesn't need to be compromised to introduce poisoning. A legitimate integration can return malicious content originating from a ticket, document, repository, or other source, and that content can influence how an agent behaves.

The distinction matters because reviewing the security of the MCP server alone wouldn't necessarily identify the problem.

Supporting reference: OWASP MCP Security Cheat Sheet ↗

Malicious tool definitions and cross-tool influence

Although malicious responses are one way to manipulate agents, there are several other poisoning techniques organizations should understand.

Tool definition poisoning involves placing malicious instructions in the descriptions or schemas that explain how a tool operates. Because agents rely on this information when selecting tools and preparing requests, an apparently harmless operation could include instructions directing the agent to invoke another tool or disclose information.

A related technique is the rug-pull attack, where an approved tool is subsequently modified. The server might retain the same tool name while changing its description, parameters, or behavior, potentially introducing malicious functionality after the original security review.

Tool shadowing creates another concern when agents connect to multiple MCP servers. A malicious server may attempt to influence how an agent uses tools provided by another, more trusted integration.

For example, an external research tool might contain instructions directing the agent to retrieve information through a separate SharePoint integration. The attacker doesn't need direct access to SharePoint if they can persuade the agent to use its existing permissions.

These techniques differ in how malicious instructions are introduced, which is important when considering defensive controls. Monitoring changes to tool definitions may help identify a rug-pull attack, but it won't necessarily detect malicious instructions contained in a service ticket retrieved through an otherwise legitimate integration.

The common concern is that information from a lower-trust source may influence actions involving higher-trust capabilities.

Supporting reference: OWASP MCP03:2025: Tool Poisoning ↗

Supporting reference: OWASP MCP Security Cheat Sheet ↗

Where Existing Security Controls Fall Short

Identity management, least privilege, data protection, and monitoring remain essential, and organizations shouldn't interpret MCP poisoning as a reason to replace them.

For Microsoft environments, Entra, Purview, Defender, and Sentinel can help reduce exposure or identify suspicious activity, depending on the capabilities deployed and telemetry available. However, these controls don't automatically establish whether an agent's decision is appropriate.

An agent may legitimately have permission to retrieve a SharePoint document and send an email. If a poisoned response persuades it to perform both actions, the underlying systems may see authorized operations rather than an access violation.

The controls are enforcing the permissions they were configured to enforce, but they don't necessarily establish whether the information influencing the agent should have been trusted.

There's also an important distinction between trusting an MCP server and trusting the information it returns. Even a properly maintained, approved server may retrieve attacker-controlled content, which is why tool responses need to be treated as untrusted input regardless of where they originate.

What Should Organizations Be Doing?

I wouldn't recommend introducing another complicated security framework. Most organizations already have processes for reviewing software dependencies, managing privileged access, and monitoring applications, and these can be extended to cover MCP integrations.

Start by identifying which MCP servers are in use, particularly those connected to agents that can retrieve sensitive information or modify enterprise systems. Establish who owns each server, which agents connect to it, and what permissions and tools it exposes.

Review tool descriptions, parameter definitions, and schemas before approval, looking for instructions that extend beyond their intended purpose. Approved definitions should also be monitored for changes, using version comparisons or integrity checks to identify modifications that warrant another review.

However, reviewing tool definitions only addresses part of the problem because poisoning can also originate in the content returned by legitimate tools.

Tool responses should be treated as data rather than instructions, with clear separation between externally retrieved information and the instructions governing the agent's behavior. Where practical, applications should validate and structure returned content rather than passing unnecessary raw information directly into the agent's context.

These measures can reduce exposure, but they shouldn't be relied upon as the only defense because malicious instructions can be disguised or embedded in otherwise legitimate information.

Organizations also need to examine interactions between tools. A response from an external MCP server shouldn't be able to authorize privileged operations through another integration simply by instructing the agent to perform them.

Sensitive actions should therefore be subject to independent authorization controls that validate what the agent is attempting to do, including the requested operation, destination, and relevant parameters. For actions involving confidential data transfers, security configuration changes, or destructive operations, additional approval should be considered outside the agent's own decision-making process.

Least privilege remains important at both the agent and MCP server layers, particularly where servers operate through service accounts with broader permissions than the agents invoking them.

Monitoring should also consider sequences of activity rather than isolated tool invocations. An unexpected SharePoint retrieval followed by an external email may warrant investigation, especially when the activity originated from an unrelated tool response.

The objective isn't to assume malicious instructions can always be detected before an agent processes them. It's to limit the opportunities for poisoning, prevent inappropriate actions from succeeding, and provide enough visibility to investigate unexpected behavior.

• Inventory MCP servers, their owners, connected agents, exposed tools, and permissions.
• Review and version approved tool descriptions and schemas; require another review when they change.
• Treat returned content as untrusted data and keep it separate from the agent’s governing instructions.
• Validate sensitive operations, destinations, and parameters through independent authorization controls.
• Restrict permissions at both the agent and server layers.
• Correlate sequences of tool activity, including retrieval followed by external transfer.
• Test controlled poisoning scenarios and confirm which actions the independent controls prevent.

Supporting reference: OWASP MCP Security Cheat Sheet ↗

Test the Agent, Not Just Its Permissions

For organizations with agents already in production, I'd recommend selecting one that performs a meaningful business function and examining how its MCP connections could influence its behavior.

Rather than stopping at identity and permission reviews, introduce controlled poisoning scenarios in a test environment and observe how the agent responds.

Can a malicious tool description persuade it to invoke an unrelated tool? Does it follow instructions embedded in returned content? Can it be redirected toward information or actions outside the original request, and would independent controls prevent those actions from succeeding?

It's also worth testing whether changes to previously approved tool definitions are detected and reviewed before the agent continues using them.

These exercises provide a more realistic assessment of exposure because they examine how an agent behaves when information from its connected tools cannot be trusted, rather than assuming that correct permission alone will prevent an incident.

Securing the Agent Is Only Part of the Job

MCP provides a practical way to connect AI agents to enterprise systems, and the risk of poisoning shouldn't discourage organizations from adopting it. As agents become more autonomous and interact with additional applications, however, the consequences of following malicious tool instructions become more significant.

The security challenge extends beyond protecting the MCP server itself because even a legitimate integration can introduce attacker-controlled content into an agent's workflow.

Organizations should extend their existing security practices to include MCP tool definitions, returned content, cross-tool interactions, and independent controls over consequential actions.

We've become reasonably good at asking what an agent is allowed to access and what actions it can perform. We now need to apply the same scrutiny to the information influencing those decisions, because securing an agent means considerably less if a poisoned tool can convince it to do something the organization never intended.