The security bill is coming due for AI's agent era

Every developer I know uses an AI coding assistant. Most of them assume the IDE sandbox protects them. It does not. Security researcher Ari Marzouk tested every major AI-powered IDE — Cursor, Windsurf, GitHub Copilot, Cline — and found over 30 exploitable vulnerabilities across all of them. One hundred percent hit rate. Twenty-four CVEs. The attack chains are elegant in their simplicity: hidden instructions in rule files, READMEs, or MCP server outputs abuse the IDE's own built-in features to exfiltrate data and execute arbitrary code.

This would be bad enough in isolation. But it landed alongside two other stories that sketch the same picture from different angles.

CyberStrikeAI, an open-source AI attack platform that integrates over 100 security tools with an AI decision engine, was used by a Chinese-linked threat actor to systematically compromise 600+ Fortinet FortiGate appliances across 55 countries in 37 days. The tool automates the full kill chain from reconnaissance to exploitation. It is on GitHub. Anyone can run it. The creator's git commit history links back to China's MSS-affiliated vulnerability disclosure programme. The tool that was built "for security testing" became the weapon.

And a new industry report covered by The Quantum Insider argues that while most enterprise security spending targets training pipelines, the actual exposure surface is inference. Agents operating as non-human identities in enterprise systems can exfiltrate data at machine speed. CrowdStrike's 2026 Global Threat Report found eCrime breakout times averaging 29 minutes, with the fastest at 27 seconds. Nearly half of enterprise security teams admit they are not confident their AI systems meet 2026 standards.

The pattern for product engineers

The throughline across these three stories is that the security model for AI tooling assumes boundaries that do not exist.

The IDE vulnerability assumes the LLM operates in a sandbox. It does not — it has access to your filesystem, your terminal, your environment variables, your SSH keys. The CyberStrikeAI story assumes open-source security tools will be used defensively. They are dual-use by definition. The inference security report assumes enterprise IAM controls are fast enough for machine-speed threats. They are not.

Every AI agent integration point is an untrusted boundary. MCP servers, IDE extensions, API tool calls, RAG pipelines that ingest external content — each one is a surface where prompt injection, tool abuse, or data exfiltration can occur. The engineering discipline we developed for web security (never trust user input, sanitise everything, principle of least privilege) applies with equal force to agent systems. We just have not applied it yet.

I keep hearing that security will be solved "once the ecosystem matures." That is backwards. The attack surface is maturing faster than the defences. CyberStrikeAI did not wait for the ecosystem to mature before automating exploitation across 55 countries. The IDEsaster vulnerabilities were not theoretical — they were demonstrated against production tools used by millions.

If you are building with AI agents, the minimum bar today is: sandbox LLM tool execution, apply least-privilege to every agent capability, treat all external content (including rule files and MCP responses) as untrusted input, and monitor inference-time behaviour the same way you monitor network traffic. The tooling to do this well barely exists. Build it anyway. The alternative is learning the hard way that your AI assistant was also someone else's attack vector.

---