Why are coding agents a SASE question?
A coding agent does more than suggest text. It reads repositories, runs commands, calls package registries and, through the Model Context Protocol, reaches internal tools and data. That traffic leaves the developer's machine and crosses the same network path a SASE service inspects. If the platform can see the agent's calls, it can apply policy to them, in the same place it applies policy to people.
What does each vendor publish?
Cato states it can "Stop risky coding-agent tool calls before they run", with "enforcement for Claude Code, Cursor, and Codex", and lists discovery of "shadow AI and coding agents across endpoints". The product names are third-party tools that Cato names on its page.
Source: Cato AI security
Netskope's Agentic Broker includes an MCP inventory in its App Catalog that covers clients "including ChatGPT, Cursor, and VS Code", with continuous discovery of MCP servers, clients and tools.
Source: Netskope Agentic Broker
Zscaler describes "Zero trust access to AI developer tools ... with inline controls" on its AI Access Security page.
Source: Zscaler AI Access Security
Palo Alto Networks lists "Secure AI Coding Agents: Protect code and credentials, govern agent actions" among Prisma AIRS capabilities.
Source: Palo Alto Networks Prisma AIRS
Fortinet's FortiAIGate checks agent tool calls, including MCP tool traffic, as a self-hosted product.
Source: Fortinet FortiAIGate
Cisco describes registering every agent, mapping each to a human owner and issuing short-lived access tokens on Secure Access; coding agents are not named on the pages we read.
Source: Cisco Secure Access
What should the controls do?
Four controls matter most. Discovery: know which coding agents run, on which machines, and which MCP servers they call. Identity: tie each agent to the developer who runs it, so that actions can be traced. Policy: decide which tools and repositories an agent may reach, and which commands need approval. Enforcement: stop a risky call before it runs, not only log it afterwards.
Where do coding agents differ from chat tools?
A chat tool sends prompts and receives answers; the main risk is data leaving in the prompt. A coding agent also acts: it can push code, delete files or call an internal API. That shifts the question from "what did the user paste" to "what did the agent do". Controls that inspect tool calls, not only prompts, are the ones that address this.
What should you ask in a trial?
Install one coding agent on a test machine and connect it to a test MCP server that exposes a harmless tool. Ask the vendor to show the agent in its inventory, show the tool call in its logs, and block the call by policy. Then try a prompt that includes a secret pattern, such as a test API key, and check whether it is redacted or blocked. Record whether each step worked inline or only as an alert.
How does this affect the ranking?
Agent and MCP controls are part of our AI security criterion, which carries 15% of the total. The weighting lab has a must-have filter for platforms that name MCP or agent tool-call controls on their pages. On the pages we read, Cato, Netskope, Zscaler and Fortinet name MCP controls; Palo Alto Networks and Cisco do not name MCP on those pages, though both describe agent controls.
What about developer experience?
Controls that slow developers down get bypassed. Ask how the platform handles a blocked call: does the developer see why, and is there a way to request an exception? Ask whether the agent's traffic needs a separate client or rides on the existing SASE client. The best policy is one developers can live with.
Who owns the policy?
Coding agent controls sit between security, platform engineering and development teams. Agree early who approves new MCP servers, who handles exceptions and how quickly. A clear owner keeps the controls in use.
The short version
Coding agents are users that act. Choose a platform that can see their tool calls, tie them to a person and stop risky actions inline, and test it with a real agent before you rely on it.