Why one AI control rarely covers both chat tools and coding agents

What does each kind of AI do?

A chat tool in a browser takes what the person gives it and sends back text. The risk is what goes in: customer data, contracts, source code. The tool does nothing on the laptop.

A coding agent such as Claude Code, Codex or Cursor works on the laptop. It reads and writes files, runs shell commands, installs packages and calls MCP servers, many of which run on the same machine. The MCP security best practices describe local MCP servers as running with the same privileges as the client. The risk is what the agent does, and much of it never touches the network.

Which controls see which?

• A browser extension sees chat tools in that browser. It does not see a terminal.
• A network or SSE proxy sees traffic to AI services leaving the device. It does not see local file reads, shell commands or MCP servers talking over standard input and output.
• An AI or MCP gateway sees calls routed through it, such as remote MCP servers. It does not see local MCP servers.
• An on-device control sees what agents do on the laptop. Unless it includes a browser component, it may see little of chat tools.

Which products describe both positions?

On the pages we read, the products that describe both the browser and device positions fully are computed here from our data: Ent, Onyx Security and Prompt Security (SentinelOne). Several others describe one fully and the other partly: Harmonic Security describes the browser and covers desktop apps and developer tools through device management; Lasso Security describes the browser and acts on Claude Code through its hooks; Akamai Workforce Protector describes the browser and says its controls reach desktop applications. Bay, Koi (Palo Alto Networks) and Noma Security describe the device position and not the browser.

How do companies handle this?

Three patterns are common. The first picks the position where the main risk sits: a company where most AI use is chat starts in the browser; a software company where coding agents are the concern starts on the device. The second combines a device control and a browser control, accepting two products for full coverage. The third chooses a product that spans both, accepting that it may go less deep in one of them.

None is wrong. The choice depends on who uses which AI tools and with what data, which is why the finder's first question asks about the tools in use and allows more than one answer.

What should you check before choosing?

1. List the AI tools in use by team, separating chat tools from agents.
2. For each, note the worst data in reach and whether the tool can act.
3. Decide whether one position covers most of the risk, or whether you need two.
4. For a product that spans both, ask to see how deep it goes in the position it describes only partly.
5. Run the finder with both browser AI and coding agents selected, and compare with each selected alone.

What about desktop AI agents?

They sit between the two. A desktop AI agent is installed on the computer and may act on files and applications, so it shares the action risk of coding agents, but people often use it like a chat tool, so it shares the data risk too. The finder treats desktop agents as a reason to look at the device position and switches on the tool-call check, without the coding-agent check that asks whether specific coding agents are named.

Is policy still needed?

Yes, in every case. An approved-tools list tells people which chat tools are allowed for which data. A rule about who may connect which MCP servers covers the agent side. The products enforce and record; the policy decides what they enforce.

What does this mean for budgets?

Two controls usually means two contracts, two rollouts and two places to look when something happens. One product that spans both positions may cost less to run but go less deep in one of them. No vendor site here publishes a list price, and only two products have marketplace list prices, so the comparison mostly has to come from quotes. Ask each vendor to price the positions you actually need, rather than its full platform, and ask what it would cost to add the second position later if you start with one. That keeps the first decision small without closing off the second.