Zedmos

AI Security

Allow AI. Without losing sight of it.

Your people are already using assistants you did not choose, and increasingly so are the tools on their machines — coding agents that read a repository, scripts that run at machine rate, MCP clients that call tools on their own. This sees every one of them on the wire: which service, used by whom, processing data where, sanctioned or not — then lets you decide who may use what, and inspects what leaves before it goes. On your own firewall, with the model that judges running on your hardware.

17
Provider rules, assistants and coding agents
69
Content detectors in 8 groups
5
Client classes, decided on evidence
0
Prompts sent to a third party to be judged

What goes wrong, and what answers it

The risk: nobody knows what is in use

Assistants arrive without a procurement decision. Somebody signs up, somebody else installs an editor plugin, and the first honest answer to “which AI services do we use?” is a guess. You cannot write a policy for traffic you cannot name.

Visibility: the inventory, off the wire

Every AI service seen in your traffic, with the vendor behind it, where it processes data, and whether you have sanctioned it. Seventeen provider rules cover the assistants and, separately, the coding agents — Cursor, Codeium, Windsurf, Tabnine and GitHub Copilot — plus a catch-all for anything else classified as AI. Nothing is installed on a laptop to get this.

The risk: the caller is not always a person

A coding agent reading a repository, a script with a borrowed API key, an MCP client calling tools on its own — all three reach the provider your staff use, and a filter that knows only the destination writes the same log line for a person and for a loop.

Control: a rule per kind of caller

Browser, SDK, agent, MCP or unknown — each gets its own action, and a different one per provider where that matters. On top of that: allow and block lists on the client, the tool names a request may carry, a rate limit per source, a request-size cap. The class is decided before the body is read, so a caller can be refused without inspecting a word of what it wrote.

The risk: what is typed, and what comes back

The prompt is the leak. Source code, a customer list, a credential pasted in for convenience. And the answer is its own problem: an assistant can be talked into writing the instruction that does the damage.

Protection: inspected before it leaves

69 content detectors in 8 groups — national identifiers from 22 countries, cloud secrets, personal and payment data, prompt injection, and eight for the instructions that turn an assistant into a tool against you: a script piped to a shell, a reverse shell, an exfiltration instruction, an attempt to talk an agent past its own guardrails. The response leg can be tapped too, where it marks and records and never blocks.

The verdict is reached on your premises

Unstructured text is judged by a language model running on your own hardware. No prompt, no upload and no excerpt is sent to a third party to be scored, which is the difference between a control you can put in a procurement answer and one that adds a sub-processor to it.

Off until you turn it on

Classification always runs, so the inventory and the class are on the flow record from the first day and you can see what is already out there before you decide anything. The controls are a separate switch, off by default, set per policy group.

Five clients, one destination, five different answers

All five of these reach the same AI provider within a minute of each other. Only one of them is a person.

1The bodywhat the request actually did"jsonrpc":"2.0" · "method":"tools/call" · tool_resultscannot be faked without doing it2The headerswhat the client's stack emits unaskedx-stainless-* · client hints · fetch metadatanot chosen by whoever wrote the script3The User-Agentwhat it says it is"Mozilla/5.0 (Windows NT 10.0; Win64; x64) …"one line, anyone can write itoverruled by 1 and 2the only row a destination filter readsCLASSbrowsersdkagentmcpunknown
Three readings of one request, hardest to fake at the top. A client that claims a browser in row 3 and sends none of a browser's headers in row 2 is classified on what it did, not on what it said — and the operator sees the name it was pretending to be.
What reaches the providerWhat a destination filter seesWhat this engine sees
Someone in marketinga tab, a question
traffic to an AI provider
BROWSERchromesends a browser's own headersAllowed
A nightly scriptbatch summaries
traffic to an AI provider
SDKpython-httpxSDK transport announces itselfLogged
A coding assistantreading the repository
traffic to an AI provider
AGENTclaude-codetool results fed back to the modelLogged with tool names
An MCP clientcalling a tool
traffic to an AI provider
MCPmcp-clientJSON-RPC frame, method tools/callread_file denied
A script in disguiseclaims to be Chrome
traffic to an AI provider
SDKspoofed-chromeclaims a browser, sends none of its headersBlocked
The last row is the one that matters. Every filter that trusts the User-Agent lets it through as a person — which is the hole this exists to close.