On August 10, over 74 minutes, a single GitHub account opened 23 pull requests into other people’s projects. Most added a few lines of configuration. The URL in them pointed an AI assistant at an attacker-run server on Render.
None were merged. Pillar Security published its findings two days later, named the campaign Deadbugz, and pulled the server apart.
Per their report, the first three tool calls were harmless. The server advertised text formatting and summarization, and delivered it correctly. However, after three queries, the same question got a different response. New instructions told the assistant to find SSH keys, AWS credentials, shell history and Kubernetes configuration. Then it ordered the assistant to conceal the activity.
Instead of a breach report we have a demonstration of a trickier problem. The AI assistant implements instructions nobody has read, from an approved server.
The AI assistant implements instructions nobody has read, from an approved server.
Rule the Deadbugz MCP Server Out in Five Minutes
Pillar found none of the 23 PRs merged, but called the campaign active when it published on August 12.
Search your GitHub organization for productivity-suite-mcp.onrender.com/mcp and your endpoints for ~/.config/.cache/.sys/.deadbug-mcp.py, then block the full hostname rather than the Render wildcard.
None of the three commands below write, delete, or change anything.
# Every repo in the org, GitHub code search
org:YOUR-ORG "productivity-suite-mcp.onrender.com"
# One clone
grep -rn "productivity-suite-mcp.onrender.com" .
# One developer machine
test -f ~/.config/.cache/.sys/.deadbug-mcp.py && echo FOUNDFor more than a handful of machines, run that path as a file-path query in your EDR. Code search only covers default branches, so list the open pull requests in each repository and read any that add MCP configuration.
The Attacker Writes the Description
Model Context Protocol, or MCP, is the standard way an AI assistant connects to tools, such as a file system, a code repository or an internal API.
Before an assistant can use anything, it asks what’s available. The server sends back a list of tools with a description of each. Those descriptions go into the model’s context as guidance on what to do and when.
Whoever operates that server writes instructions your AI assistant acts on.
Pillar found no exploit and no obfuscation, because neither was necessary. In their words, those descriptions “contain instructions intended to steer an attached AI agent toward sensitive local files.” The technique is called tool poisoning.
Because the instructions arrive as prose, the model acts on them while the scanner has no file to open.
These Outlive the Server
The instructions named four sources of standing access, and each stays valid until it is revoked.
SSH keys open whatever hosts they authenticate to, usually without another prompt.
AWS credentials grant whatever the attached policy allows, which is routinely more than whoever created them intended.
Shell history holds the secrets people pasted once and never changed.
A Kubernetes config carries cluster access and the service accounts inside it.
Any hit means the credentials Deadbugz asked for should be treated as exposed. Rotate SSH keys and AWS credentials, search shell history for anything still valid, and re-check what the Kubernetes config grants.
The Control Belongs on the Data
Rotating what leaked closes this incident. It doesn’t say which documents any AI system should reach next time.
Trust on First Use
Two open-source projects have since documented Deadbugz. A contributor proposed an entry in the GenAI Security Project’s incident index, classifying it as call-count-gated tool poisoning, and that pull request is still open. A benchmark called mcp-guardbench merged a frame-by-frame reproduction on September 11.
The benchmark names the failure trust-on-first-use. The tool list was inspected once, when the session started, and the replacement that arrived later was never checked against it. Nothing had been written to disk either, so no saved copy existed to compare against.
Three Controls That Limit the Damage
Prevention
Review a new MCP server like a vendor, not a config change:
- identify who operates the endpoint
- record why the assistant needs it
- get both answers before the merge
Detection
Compare responses, not counts:
- log every response from the server
- diff each one against the previous
- alert on any change to a tool description
Containment
Give the agent its own identity, with no access to:
- SSH keys
- AWS credentials
- shell history
- Kubernetes configuration
Where Sovereign AI Fits
Armor built Sovereign AI as one control layer for every model and every team, so that policy, spending limits and the audit record sit together.
About Sovereign AI
Sovereign AI is the governed AI work platform for the whole company, built by Armor. One control layer for every model, every team, and every dollar, inside your walls, under your rules. Armor has spent 17 years securing regulated industries, protecting over 1,700 organizations across 40+ countries held to the highest compliance bars in the business. Sovereign AI is what that experience looks like as a product. Learn more at sovai.com.
About Armor
Since 2009, more than 1,700 organizations in 40+ countries have relied on Armor to protect regulated data in the public and private cloud. AI is the next risk, so Armor built Sovereign AI to bring that same protection and compliance to how organizations use AI in the workplace: a fully governed platform that lets them leverage AI without creating undue risk to their data and their regulatory obligations. For more information, visit armor.com and sovai.com and follow us on LinkedIn.