What we found
The server: a Gmail integration on GitHub exposing 28 tools that send, read, search, draft, delete, label, and filter mail against a real inbox.
A staggering 35 CVEs were found in the dependency tree.
A clean tool audit isn't the same as low stakes, though. Among those 28 tools, send_email sends mail on the user's behalf and delete_message removes it outright: neither one is reversible the way a search or a read is. Nothing about them looked malicious, and nothing about them needed to. The critical CVE sits in the dependency tree underneath all 28 tools equally, so the tools carrying the riskiest consequences if that CVE is ever exploited are exactly the write and delete ones, not the read-only ones the audit spent the least time worrying about.
Why the agent didn't just use Google's server
Google does run an official Gmail MCP server, gmailmcp.googleapis.com, opened to public developer preview in May 2026 alongside Chat, Drive, and Calendar MCP servers announced at Cloud Next '26. But by Google's own documentation, it exposes eleven tools, and none of them send mail. Google's own guide describes what it does in plain terms: read data, and create drafts and label messages. Meanwhile the server still requests the gmail.compose scope, which Google's own scope reference describes as "manage drafts and send emails." The permission to send is there. The tool to use it isn't.
So when the developer's ask included send, the agent had a real gap between what the official server could do and what it was asked to do. It filled that gap the way these agents fill gaps: it searched, found a full-featured, popular, actively-maintained community project that covered everything Google's preview doesn't, and configured it. That's not the agent malfunctioning. That's the agent doing exactly what it's built to do, running headfirst into the one thing it was never built to check: what's actually sitting underneath a plausible-looking dependency tree.
And the missing tool isn't even the only way this happens. We've also seen environments where the organization did everything right on paper: an AGENTS.md or similar config file, sitting right in the repo, spelling out exactly which MCP servers are approved for which task. The agent read it and reached for something else anyway. A written policy that isn't enforced at launch time is a suggestion, not a control, and an agent under time pressure to satisfy a request will route around a suggestion just as easily as it fills a capability gap.
This is the twist: it's not obvious the agent was wrong to look elsewhere. Google's official Gmail MCP server exposes eleven tools, and none of them send mail, even though it requests an OAuth scope Google's own docs describe as permitting sending. It's built for reading, drafting, and labeling. It is not, today, a complete replacement for what someone actually means when they say "connect to Gmail" and expect an agent that can send.
The agent wasn't tricked, and it wasn't careless in any sense we'd normally flag. It was asked to accomplish a goal, found a widely-used, actively-maintained, plausible-looking project matching that goal, and configured it. That's exactly what these agents are designed to do.
There's no complete official vendor server for many integration categories an agent gets asked to wire up: Gmail, Slack, internal ticketing systems, and dozens more. The agent fills that gap with judgment calibrated on popularity and plausibility, not on a dependency-level vulnerability scan. That gap is the whole story, and it isn't specific to this repository or a knock on its maintainer.
What actually stopped it
Our MCP proxy sits between the agent and every MCP server it tries to run, and it doesn't wait for a server to misbehave at runtime. It inspects the server before the process launches: cataloging the dependency tree and surfacing the CVE, static-analysis, and tool-audit findings above, before that server gets anywhere near a real Gmail account.
That inspection isn't just pass/fail on the server as a whole. Every tool the server exposes gets classified by what it actually does: read, write, or delete. Policy acts on that classification per tool, not per server. read_email and search_threads land in read. send_email and the label-editing tools land in write. delete_message lands in delete. A team can let agents read freely while gating or blocking write and delete outright, on this server or any other, without writing a special-case rule for the one that happened to show up in a scan.
From there it's a policy decision, not a guess. A security team can require review before a critical-CVE server executes, block it outright pending remediation, or allow it with the finding logged and visible. What it does not do is let the agent quietly wire live inbox access through an unvetted dependency chain and find out about it later, if at all.
This particular server wasn't just caught once and then waved through afterward. Continuous scanning keeps re-evaluating servers already in use, not only at launch, and it flags this one as risky on every pass: same critical CVE, same standing risk score. Once a server is scored that way, containing it isn't a custom fix: it's a single MCP policy rule, "don't allow risky servers," applied the same way across every agent and every server in the environment.
