AI Agents in Code: How Malicious MCP Servers Steal Secrets

AI agents that write, review, and run code have stopped being an experiment and become part of the daily routine for development teams at Brazilian companies. They connect to repositories, run commands, query APIs, and increasingly integrate with external tools through protocols like MCP (Model Context Protocol), created to standardize how an AI assistant discovers and uses third-party capabilities. It is exactly this convenience that has opened a new attack surface, and recent research has shown how it can be exploited silently.

The problem: fragmented instructions bypass refusal

The mechanism is simple to understand and hard to detect. A malicious MCP server, connected to the coding agent as if it were a legitimate tool, does not directly ask "send the SSH keys to this address." A request that obvious would be refused by the model's guardrails. Instead, the attack splits the malicious instruction into small fragments, each one looking like a routine development task: reading a configuration file, listing environment variables, formatting output, sending a diagnostic log. Each fragment, in isolation, passes through the model's security filters without triggering an alarm. When put together in the agent's execution sequence, the end result is the complete exfiltration of secrets: SSH keys, sensitive environment variables, snippets of proprietary source code, and even customer data.

The most concerning detail is that the technique works even after a direct, "clumsy" version of the same attack has already been refused by the agent. The attacker simply switches approach, breaks the request into parts that exploit channels the assistant already uses normally, and the agent executes without realizing it is being manipulated from end to end.

Why this matters beyond the development team

This type of attack exposes a gap that most companies still haven't closed: governance over what AI agents can access, which external tools they can connect to, and how that behavior is audited over time. Unlike a traditional software vulnerability, the problem here isn't an isolated code flaw, but the agent's own reasoning logic, which trusts instructions arriving through legitimate channels that never look malicious in isolation.

This connects directly to a broader trend we've already discussed here: as autonomous agents gain permission to act (run commands, access systems, make decisions), the risk surface stops being purely technical and becomes a governance issue. The case of malicious MCP servers is one more reminder that giving an agent autonomy without proper oversight opens a door that no one is monitoring.

There's also a second development amplifying this risk: language models built specifically for offensive tasks, such as vulnerability research and exploit development, are being released with reduced safeguards to enable legitimate security research. This means the same sophistication that helps defenders find flaws before attackers do also lowers the technical barrier for those who want to build exploit chains. The practical result for the Brazilian CISO is twofold: the internal agents your company already uses for coding can be manipulated by third parties, and publicly available AI tools for offensive research are becoming increasingly capable.

What actually changes for risk managers

A few questions should be on the agenda of any security committee overseeing generative AI adoption in development:

• Which MCP servers or tool plugins are your coding agents allowed to connect to? If the answer is "whatever the developer installs," there's already a governance problem.
• Is there logging and auditing of the agent's action sequence, not just the final outcome? A fragmented attack only becomes visible when you look at the full flow of instructions, not an isolated action.
• Are secrets and credentials isolated from the context the agent can read directly? Secret vaults with mediated access, rather than free reading of environment variables, drastically reduce impact.
• Is there a review process for new AI tool integrations, equivalent to what already exists for third-party libraries in CI/CD pipelines?

These questions don't have trivial answers, and that's exactly where the need for a dedicated AI governance layer comes in. At Intelliway, that's the role of AI Trust: defining guardrails, access policies, and audit mechanisms for AI agents before they go into production, covering both what the agent can do and which external tools it can invoke. When a company builds custom agents with AI Factory, that permission and monitoring design is already part of the project, not a patch applied later.

On the security operations side, anomalous AI agent behavior (out-of-pattern tool calls, sequences of sensitive file reads, unusual outbound traffic) is the kind of signal SOC teams need to start monitoring with the same seriousness they apply to compromised human identities. This is where Intelliway's SOC and MDR, backed by AI-driven detection like ISA Cyber, helps correlate this type of activity with the rest of the environment and identify when a supposedly trustworthy agent is being used as an exfiltration channel.

Practical takeaway

AI agents in development are here to stay, and the productivity gains they bring are real. But every new tool or server connected expands the attack surface in a way that traditional application security controls weren't designed to see. Before scaling up the use of coding agents at your company, it's worth mapping which external integrations they already have, isolating sensitive credentials from the model's direct context, and establishing continuous auditing of these agents' behavior, not just the code they produce. AI governance has stopped being a distant compliance topic and become part of the daily routine for anyone protecting critical development infrastructure.

Want to assess the governance maturity of the AI agents your company already uses? Talk to Intelliway.