MCP agents become dangerous when they can access private data, consume untrusted content, and communicate externally.
2
Attackers can use prompt injection, malicious package updates, tool parameter names, and duplicate tool names to make agents expose data or take unwanted actions.
3
Teams should pin server versions, limit permissions, review schemas, isolate servers, filter inputs and outputs, and require human approval for sensitive actions.
Summary
Vitor explains how MCP servers expand an agent's access to data, tools, and external systems while security controls remain immature. He focuses on prompt injection, where instructions hidden in tool output, documents, logs, schemas, or parameter names influence an agent. Several examples show how attackers can move from untrusted content to private data and then exfiltrate it through public repositories, URLs, email, or image requests. He also describes rug pulls, where a trusted MCP package changes after approval, and tool shadowing, where a malicious server exposes a tool with the same name as a legitimate one. His advice covers least privilege, version pinning, server catalogs, schema review, sandboxing, filtering, allow lists, and human approval. For companies, he recommends routing MCP traffic through a controlled gateway. He argues that security scanners need to inspect tool-level input and output flows in context rather than flagging simple suspicious-looking descriptions.
MCP creates a dangerous gap between agent adoption and security controls
Vitor says MCP adoption accelerated after the standard launched in November 2024, while security protections have lagged. Agents can access external systems and private data, so an attacker may steal credentials, impersonate a user, execute code, or exfiltrate information. He says the talk is intended to give listeners a mental model for auditing agents and MCP deployments, rather than provide an exhaustive list of every attack.
Prompt injection can enter an agent through any content in its context
Vitor expands prompt injection beyond a user typing malicious instructions. Tool output, tool descriptions, schemas, names, and parameter names can all end up in the model's context. His example uses a LinkedIn-reading tool for recruiting. A malicious instruction in a LinkedIn profile could influence the agent, especially if the agent also has access to private data and a tool that can send information outside the system.
The lethal trifecta combines private data, untrusted content, and external communication
Using Simon Wilson's term, Vitor describes three conditions that make prompt injection especially dangerous. The agent can access private data, it receives content the user does not control, and it has a way to communicate externally. A GitHub example shows the sequence: an issue in a public repository injects instructions, the agent reads a private repository, and then writes sensitive information into the public repository's README.
Attackers can hide prompt injections in ordinary business data and application behavior
Vitor describes a Notion example where instructions were hidden in a PDF and caused a search tool to send private data through a URL query parameter. In a Heroku example, an attacker placed instructions in the query string of a request that appeared in server logs. When a user asked the agent to inspect those logs, the agent encountered the injection and used an enabled transfer tool. He also describes data exfiltration through remotely loaded Markdown images.
Prompt injection defenses need filtering, least privilege, and human approval
Vitor recommends scanning content entering and leaving tool calls for sensitive data and signs of prompt injection. He says agents should have only the permissions they need, with high-risk actions requiring human approval. Delimiters around external content can reduce its influence on newer models, although he warns against treating an LLM-based guardrail as the main defense. He also recommends penetration testing, internet allow lists, and sandboxes without network access where possible.
MCP rug pulls turn trusted installation into a supply-chain risk
Vitor describes rug pulls as a classic supply-chain attack. A server can look safe when first inspected, then a later package version can introduce malicious behavior. In the Postmark MCP example, an attacker published a package matching the official repository for several versions, then changed the email tool so every message was blind-copied to an attacker-controlled address. Vitor recommends official servers where possible, pinned versions, code review, containerization, and inspection of tool schemas.
Tool names and duplicate tools can cause data leaks without obvious malware
A server can manipulate an agent through suggestive parameter names such as tools list, tool call history, model name, or conversation history. The model may try to satisfy those names by passing sensitive information. Vitor also warns about tool shadowing: a malicious server can expose a tool called send message alongside a legitimate WhatsApp tool. Without server-based namespacing, the agent may call the wrong implementation.
Companies need controlled MCP catalogs and gateways
For organizations, Vitor recommends an internal catalog containing audited, approved servers with pinned versions. A gateway can proxy MCP servers and provide oversight of tool calls, data movement, users, and shutdown actions. Teams can apply least-privilege rules to restrict risky tools, and they can host servers in sandboxes that limit access to local resources. Workflows should expose only the subset of servers and tools they need.
MCP scanners need to understand tool flows and user intent
Vitor says current scanners often flag surface-level patterns, such as a tool description that asks another tool to run first, even when the instruction is legitimate. He expects more specialized security models to inspect input and output flows together and compare them with user intent or system policy. In the question period, he describes Runlayer's approach as layered, combining static scans, code checks, runtime input and output scans, machine-learning methods, heuristics, and regular expressions.
"If you give it access to your private data, you give it exposure to untrusted content that you don't control, and you give the agent a way to externally communicate in any way, then that could be used to steal your data."Vitor04:49
Who should watch
You are deploying MCP servers that can read private data or perform actions in external systems, and you need a practical threat model.
You build MCP servers or agent platforms and need guidance on schemas, permissions, package updates, sandboxing, and runtime checks.
Your company is considering an internal MCP catalog or gateway and wants to understand what controls Vitor recommends.
