Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Your WAF is doing its job. It's blocking SQLi, XSS, and the usual suspects. But here's the problem: it wasn't built for APIs, and it definitely wasn't built for AI agents. APIs now power nearly every digital experience. And AI agents — the automated systems that access your APIs at machine speed, at machine scale — are the fastest-growing source of that traffic.

AI agents are rapidly moving from experimental projects into everyday business operations. Unlike traditional AI systems that generate content or answer questions, AI agents can take action. They can call APIs, access applications, retrieve data, execute workflows, and make decisions with limited human intervention. That shift is creating a new security challenge for enterprises.

Last week, an AI system crossed a line many still considered theoretical. During an internal cybersecurity evaluation, OpenAI tested a combination of models, including GPT-5.6 Sol and a more capable pre-release model, on ExploitGym, a benchmark that measures whether agents can turn software vulnerabilities into working exploits. The models were run with reduced cyber refusals and without the production classifiers normally used to prevent high-risk cyber activity.

AI agents are moving from experiments into production workflows, and the Model Context Protocol (MCP) is becoming the connective layer that enables those agents to access enterprise data, applications, APIs, repositories, and automation tools. That makes MCP powerful, but also security-critical. As organizations adopt agentic AI, they need to understand not only how MCP improves connectivity but also how it creates new visibility, governance, and attack-surface challenges.

Every mature product reaches a moment where adding another feature isn't enough anymore. At some point, you have to rethink the experience itself. That's what Salt V2 is. A year of work, with one goal behind every change: helping security teams trust what they see, faster. Here it is, in four before-and-afters.

Cybersecurity has a strange problem. Everyone says they want to reduce risk. But too often, the way we evaluate products rewards something narrower: how quickly a vendor can show value in a POV. Can it deploy fast? Can it work agentless? Can it produce a clean report? Can it map to OWASP, NIST, the EU AI Act, or the latest framework? Can it check enough boxes in the RFP?

AI agents do not create risk only when they hallucinate or produce an inaccurate answer. They create risk when they take the wrong action. A single user prompt can move through an application, reach an agent runtime, call a tool, trigger an MCP server, and touch a downstream API. By the time the action happens, the original request may be several layers away from the system that actually changes data, sends information, or executes a workflow. That is the problem security teams now face.

The first wave of AI security looked a lot like a WAF for LLMs: inspect the prompt, filter the output, block the obvious bad patterns. That was useful. It still is. But it was built for systems that mostly talked. Agents are different. They use tools, call APIs, access data, and change things. The confusion I keep seeing is simple: many teams think securing the model means securing the agent. It does not.

Every company has a version of the same thing. Sometimes it’s a security wiki. Sometimes it’s a Confluence page. Sometimes it’s a PDF nobody wants to update.

This week, Connie Loizos, editor in chief of TechCrunch, sat down backstage with Francis de Souza, COO of Google Cloud, for a piece on the state of enterprise AI security. The interview is worth reading in full. Three points in it should reshape how every CISO is thinking about the next twelve months.