On August 12, 2026, Pillar Security published a report on a supply-chain campaign they named Deadbugz. A single account submitted 23 pull requests in 74 minutes on August 10, 2026, targeting AI projects, MCP servers, and developer tools with no apparent connection to each other. Nineteen of those pull requests were closed by the time the report came out. Four remained open.
What happened
MCP—Model Context Protocol—is the protocol AI agents use to connect to tools and data sources. The Deadbugz campaign exploited a fundamental assumption in that protocol: that once a tool is approved, its behavior stays the same.
One of the MCP servers in the campaign offered text formatting and summarization. After three normal tool calls, the subsequent responses from tools/list and prompts/get changed. The new tool descriptions instructed the agent to search for SSH keys, AWS credentials, terminal history, and Kubernetes configuration. They also told the agent to hide that activity from the user.
Nothing about the connection had to change for this to work. It was still the same server the team had approved; only the instructions it handed the agent were different.
Pillar Security's recommendation was direct: clients should treat a change in the tool definitions of an already-approved server as a relevant security event. In other words, a tool that changes its own description is not a feature update. It is an incident.
Why tools that change matter more than open ports
The instinct in many security teams is to focus on the perimeter. Open ports are visible. They show up on scans. They feel like the obvious risk. But the Deadbugz campaign did not exploit an open port. It exploited trust in a connection that was already established.
The same month, the NIST National Vulnerability Database published three vulnerabilities in legitimate MCP servers. CVE-2026-73498 was a path traversal in the community MCP server for Confluence and Jira, versions before 0.22.0, with a high severity score of 7.7. CVE-2026-67357 affected the ArcadeDB MCP server before version 26.7.3, which returned the cluster token in clear text, also at 7.7. CVE-2026-19956 was a server-side request forgery in an MCP server for Facebook ads, version 0.1.0, at medium severity 5.3.
These are not obscure tools. They are connectors to Confluence, Jira, ArcadeDB, and Facebook Ads—systems that regulated companies use every day. The vulnerabilities were in the connectors themselves, not in the infrastructure around them.
Network controls alone do not see flaws like these: the connection is allowed, the credentials are legitimate, and the session looks normal.
What this means for operations in Latin America
Regulated companies in Latin America operate under data protection laws that require proportional security measures. Panama's Law 81 of 2019 is explicit: the measures must match the risk level of the personal data being processed. When an AI agent connects to internal systems that contain customer data, employee records, or financial information, the risk is not theoretical. The agent can read, summarize, and act on that data. If the connector it uses changes its behavior mid-session, the data walks out through a channel the company approved.
This is not a compliance checkbox problem. It is an architectural problem. The architecture must answer three questions for every request an agent makes: who sent this, what tool is being called, and has that tool changed since we approved it.
Many agent deployments cannot answer the third question yet. They authenticate the connection once, at setup time, and then trust the tool indefinitely. Deadbugz showed that the window between setup and exploitation can be as short as three API calls.
For a regulated company in the region, the implication is practical. Connecting an agent to a core system through an MCP server with no additional controls is hard to defend as a proportional measure. The regulator does not need to name MCP; proportionality to the risk is already the standard an auditor will apply.
What your company can do this week
-
Inventory every MCP server your agents connect to. List the tool definitions each server exposes today. Store that list somewhere the agent cannot modify. Compare it weekly. If a tool description changes and nobody on your team requested the change, treat it as an incident, not a maintenance note.
-
Close every inbound port on the server that hosts your agent connectors. The server should only open connections outward. Agent access should enter through a tunnel behind an identity provider. If a port is open, there is something to scan. If there is nothing to scan, the attack surface shrinks to the identity layer.
-
Put a signed identity token on every request. The connector should receive, with each call, a token that identifies the person who initiated the action. If the token is missing or invalid, the connector returns a 401 and stops processing. This gives you an audit record that ties every tool invocation to a specific person, not just to the agent.
-
Resolve sensitive data on the server, never in the model. When the agent needs a customer ID, an account number, or a tax identifier, the model should write a reference to that data. The connector resolves the reference against the authorized source on the server side. The real data never enters the chat, the model never sees it, and no tool can return it to the prompt.
-
Store secrets in a vault that reads at runtime. API keys, database credentials, and service tokens should live in a vault on the connector server. The connector reads them at the moment it needs them. No tool definition should contain a secret. No environment variable should hold one. If a tool changes its behavior, it still cannot read a secret that was never in its memory.
My take
The pattern we build on for regulated clients is not complicated: no open ports, identity on every request, secrets in a vault, and sensitive data resolved outside the model. What Deadbugz adds to that pattern is the realization that tools are not static. A connector you approved on Monday can be a different connector on Wednesday, and the agent will not notice unless you build the detection yourself.
This is why we treat a change in tool definitions as a security event. It is why the server where our connectors live opens no inbound ports. Access enters through a tunnel behind an identity provider. Every request carries a signed token that identifies the person. The connector rejects anything without it. Secrets sit in a vault, read at runtime, and no tool returns them to the model. For sensitive data, the model writes a reference and the connector resolves it on the server. The real data never touches the chat.
I do not think this is optional for regulated companies. Law 81 requires proportional measures. A tunnel with identity verification and server-side data resolution is a proportional measure. An open port with a static API key is not. The difference is not subtle, and the Deadbugz campaign made it impossible to ignore.
We also run a hybrid AI platform where frontier models handle judgment and local models handle volume, with a model gateway that assigns keys per person and per agent, budgets per key, and a trace per call. The governance framework answers three questions for every model interaction: which model touches which data, who approved it, and what evidence remains. That framework is what makes the architecture auditable under Law 81.
Frequently asked questions
What is the Deadbugz campaign and why does it matter?
Deadbugz was a supply-chain attack documented by Pillar Security on August 12, 2026. A single account sent 23 pull requests in 74 minutes to unrelated AI, MCP, and developer-tool projects. One MCP server changed its tool definitions after three calls, instructing the agent to steal SSH keys, AWS credentials, terminal history, and Kubernetes configuration while hiding that activity from the user. It matters because it shows that a tool your agent already trusts can silently turn malicious without any visible change to the connection.
How does an identity-verified tunnel work for AI agents?
The server where the connectors live opens no inbound ports. Access enters through a tunnel behind an identity provider. Every request to a connector arrives with a signed token that identifies the person who initiated it. The connector rejects any request that lacks a valid token with a 401 error. Each call is audited with the tool name, the person, and the result. Secrets are stored in a vault on the server, read at the moment of use, and never returned to the model or the chat.
What does Panama's Law 81 of 2019 require for AI agent connections?
Law 81 requires security measures proportional to the risk level of the personal data being processed. The law does not list controls for AI agents. For an agent that reaches personal data, proportionality is easiest to show with controls such as identity verification on every request, an audit trail per call, and secrets kept out of the model's reach. A tunnel without open ports, combined with per-request identity and server-side resolution of sensitive data, provides evidence that the company took measures proportional to the risk.
Already using AI? We run a free 45-minute AI governance assessment for regulated companies: which model touches which data, where a control is missing, and what evidence an auditor would ask for today. Book the assessment