Blog
Your AI tools trust each other. That's the part to fix.
This week, Ars Technica's Dan Goodin reported on a kind of attack that moves through AI tools the way a rumour moves through an office. Independent researcher Syed Anas Mohiuddin showed that a planted instruction given to one AI agent can be passed along to a second agent, which carries it out because it trusts whoever handed it the work. According to Ars, Google and four other organizations have acknowledged flaws of this kind.
If your team is starting to connect AI tools to your own systems, this is worth ten minutes. Nothing here is on fire. The fixes are mostly good habits you can put in place now.
What actually happened
A few quick definitions first. An AI agent is an AI tool that can take actions, not just answer questions: look something up in a database, call another service, send a file. MCP (Model Context Protocol) is a common standard that lets agents plug into tools and data. Think of it as a universal adapter.
The researcher's point is that agents are often set up to trust each other completely. Someone hides an instruction in a document or web page. That's prompt injection: text written to trick an AI into doing something it shouldn't. The first agent reads it and passes it down the line as a normal task. The next agent follows it.
Google's case is the clearest example. Its official record for the flaw (CVE-2026-14540), published 31 July 2026, describes a high-severity bug in its MCP Toolbox for Databases. A crafted request could make the toolbox follow a redirect and send requests to internal systems it was never meant to reach. That's called server-side request forgery: tricking a server into making requests on an attacker's behalf. Versions 0.3.0 to 1.4.0 were affected, and Google has fixed it. Rapid7 also published and fixed a separate issue in its own MCP tool in September.
Douglas McKee of Rapid7 put it well to Ars: "Each protocol was built assuming it lived on its own, so each one checks its own front door while nobody watches the hallway in between."
Why this matters for a small team
You don't need to be Google to be in this picture. The moment your team connects an AI assistant to a shared drive, a customer database or your inbox, you have the same basic shape: an AI reading content it didn't write, with the access to act on it.
The good news is that none of these bugs are exotic. They're old web security mistakes showing up in a new place. That means the defences are well known.
Four checks before your next AI tool goes live
1. Treat anything an AI passes along as untrusted. When one tool hands a request to another, the receiving tool should check it as if it came from a stranger on the internet. In a prompt injection, that's exactly where it came from.
2. Give each tool the smallest key it needs. An agent that summarizes invoices doesn't need permission to delete them, or to open your HR folder. Read-only access, limited folders and a separate account for each tool all shrink what a tricked agent can do.
3. Fence off where tools can connect. Google's fix blocks connections to internal network addresses by default and lets administrators list the address ranges the toolbox is allowed to reach. Apply the same idea to your own tools. If a tool only needs to talk to one system, it shouldn't be able to reach the rest of your network.
4. Keep a person in the loop for anything that matters. Sending money, emailing customers, changing records: put a human "yes" in front of those steps until you've watched the tool behave for a while.
One housekeeping item: if your team uses open-source MCP servers or toolkits, make sure someone owns keeping them up to date, the same way you'd patch any other software.
The short version: treat anything one AI tool hands to another as untrusted, and give each tool only the access it needs.
Sources
- "MCP for agent-to-agent comms may be the riskiest protocol you've never heard of", Ars Technica (Dan Goodin), 2026-10-05. https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/
- CVE-2026-14540, "Server-Side Request Forgery via Unrestricted HTTP Redirection in MCP Toolbox", CVE record assigned by Google, published 2026-07-31. https://www.cve.org/CVERecord?id=CVE-2026-14540
- "fix(source/http): implement SSRF guard", googleapis/mcp-toolbox pull request #3448, GitHub (Google). https://github.com/googleapis/mcp-toolbox/pull/3448
- CVE-2026-97228, "Rapid7 Bulk Export MCP — GraphQL Query Injection in Export Status Lookup", CVE record assigned by Rapid7, published 2026-09-25. https://www.cve.org/CVERecord?id=CVE-2026-97228
