The Manipulated Agent: When Apify’s MCP Turns Against You

A page should not get a vote in what your agent does next. With Apify’s official MCP server, it can. We found a serious prompt-injection vulnerability that lets a malicious page make the assistant contact attacker-controlled infrastructure through the victim’s account. From there, the same assistant can waste API calls and paid compute, expose data in its context, or interfere with live automations – while the user thinks it is simply reading a page.

Why Apify’s MCP Reaches So Far

Since MCP was introduced, it has spread well beyond software development. Analysts use agents for research, sales teams use them for enrichment, and operations teams use them to connect data collection with recurring workflows. Apify’s MCP server makes that easy: one authenticated connection lets an agent search the web, extract content, and run thousands of cloud-based scraping and automation jobs. Apify advertises access to more than 7,000 of these tools, while its connectors can link compatible automations to business applications such as Notion, GitHub, and Slack.

Inspecting remote pages is not an edge case here; it is one of the server’s core workflows. Many users can therefore connect Apify to their work, ask an assistant to read an ordinary page, and never realize that the returned markdown enters the same decision loop as tools authorized against their account. For non-technical users in particular, “read this page” does not sound like granting that page influence over the agent’s next authenticated action.

So We Tested It

We asked an agent to inspect a page using the default apify--rag-web-browser tool. The first tool call was exactly what the user requested. Apify then returned the scraped page as markdown through the job’s stored results, placing attacker-controlled text into the agent’s context.

That text instructed the agent to call apify--rag-web-browser again, this time with a different URL chosen by the attacker. The agent complied. The attacker did not need the victim’s Apify token, JavaScript execution, or access to the victim’s machine; they only needed control over content the agent was asked to read.

In the recorded demo, we used content in a GitHub issue because it is a normal page someone might ask an assistant to inspect. The delivery layer could just as easily be documentation, a support ticket, a README, a product page, a comment, or any other external content returned to the model.

The observed sequence looked like this:

# observed tool-call sequence
apify--rag-web-browser { "query": "<USER_PROVIDED_URL>", "outputFormats": ["markdown"] }
get-dataset-items      { "datasetId": "...", "fields": "markdown" }
apify--rag-web-browser { "query": "<ATTACKER_CHOSEN_URL>", "outputFormats": ["markdown"] }

The first call was expected. The middle call retrieved the page content. The final call was not requested by the user, and its destination came from the scraped page. This was not an HTTP redirect: the page manipulated the model into choosing and issuing a new authenticated tool call.

In eight controlled trials using the same simple payload, the agent initiated the unrequested second fetch every time. We also reproduced attacker-chosen tool-call behavior in Cursor. The exact reliability varied across models and prompts, as prompt-injection behavior usually does, but the weakness was not isolated to one client or one model.

The Lethal Trifecta Inside Apify’s MCP

The dangerous part is not apify--rag-web-browser by itself. It is the combination of three otherwise useful properties in one agent session: access to private data, exposure to untrusted content, and the ability to communicate externally. Security researcher Simon Willison calls this combination the lethal trifecta.

The second fetch is the cleanest proof because the change in control is visible: the assistant contacts a destination the user never supplied. But the same connector can also start cloud jobs, stop running jobs, read stored results, and spend the victim’s account quota. A malicious page is therefore not limited to changing what the assistant reads next; it can try to burn paid resources, interrupt production automations, or pull account data into the conversation.

The exfiltration risk is conditional but serious. If an agent already holds sensitive material in its context – perhaps from a previous tool call, a dataset, or a connected work system – an injected instruction can try to place that material into a follow-up request to attacker-controlled infrastructure. The demo proves the page can influence the destination; the surrounding permissions determine how damaging that influence becomes.

Apify’s Response

Apify closed the report and described the behavior as a broader, “probably unsolvable” prompt-injection problem in autonomous LLM and agent setups, rather than a conventional server-side bug. Its proposed boundary was on the user side: run the agent in a constrained environment, approve every tool call or action, or accept the risk when using full autonomy with open-web access.

That response captures a real technical difficulty, but it also exposes the product gap. Requiring approval for every call erodes the speed and autonomy users installed the connector to gain. Skipping those approvals leaves the model to distinguish user intent from instructions hidden in untrusted content – while that same model is the component being manipulated.

This Is Bigger Than Apify

Many MCP servers fetch remote content and return it directly to a model. That makes indirect prompt injection an ecosystem problem, not an Apify-specific mistake. There is no stable list of malicious phrases to block, and a model cannot reliably inspect its way out of every attack: the payload can be rewritten endlessly, split across content, or adapted to the model and task.

The people exposed are not only engineers who understand tool permissions and model context. MCP is increasingly used by analysts, researchers, sales teams, recruiters, and operations staff who install official connectors to get work done. They may authorize broad access without realizing that text on a page can participate in the agent’s decision-making or that a routine follow-up call may be carrying attacker-supplied arguments.

What Safer MCP Architecture Looks Like

This is not a reason to stop using MCP. It is a reason to enforce trust boundaries outside the model. Open-web retrieval should be isolated from authenticated, state-changing tools; arguments should retain provenance so content cannot silently become a URL or action; new destinations and spend or destructive operations should require meaningful confirmation; and monitoring should evaluate the full chain of context and tool calls, not each call in isolation.

The goal is not to teach every user to spot invisible prompt injection. It is to prevent untrusted content, valuable access, and unrestricted outbound action from meeting by default.

Disclosure Timeline

The Boundary Is the Problem

This is part of our ongoing research into MCP servers and the trust boundaries around them – research that keeps surfacing the same uncomfortable point: some of the most widely adopted MCP servers are running with exactly these gaps, unaudited, right now. CircleCI’s MCP server was first; jupyter-mcp-server was second. Apify is another reminder that it will not be the last.

More findings, practical guidance, and tools for understanding the agent ecosystem will follow. Subscribe to the Pluto blog to keep up with the series.

About Pluto

Pluto‘s platform starts with discovery: every connector, skill, plugin, and MCP server already running across an organization’s AI stack, sanctioned or not. From there, context-aware risk assessment surfaces chains like the one in this article, and enforcement can stop them before untrusted content turns into an authenticated action.

If your team is using MCP servers, self-hosted or otherwise, and wants someone to verify everything’s under control, book time with us and we’ll show you what we’d find in yours.