Into The Kernel

Why We Went Into the Kernel to Secure AI on the Endpoint

A year ago, "AI security" mostly meant watching what employees typed into ChatGPT in a browser tab. That's still very much worth watching. But it's no longer the whole picture. Today, a growing share of the most consequential AI work on an employee's machine isn't happening in a browser at all. It's Claude Code reading your repo. It's Cursor calling a dozen MCP servers. It's a Python script hitting the Anthropic or OpenAI API directly, with no browser, no tab, and no DOM for anything to inspect.

We started where most people start: instrumenting the browser. That's not a stepping stone we've since outgrown; it's still a genuinely good entry point on its own, and a lot of organizations only need exactly that: full coverage of the 1,000+ web-based AI tools employees actually touch day to day, with no certificate and no OS-level install required. But as soon as we started looking at AI coding agents and local agent frameworks, we ran into a wall: there's no browser surface to instrument there. An agent spawning a local MCP server, or a script calling api.anthropic.com directly, never touches anything a browser extension can see. So the browser layer and the OS layer aren't a "before and after": they're two different surfaces, and for teams contending with autonomous agents and tool access, the second one turned out to need a different depth of visibility entirely.

Why "just watch the network" doesn't work either

The next instinct is usually: put something on the network and inspect traffic there, a PAC file, a system proxy setting, something that redirects traffic through an inspection point without touching the endpoint itself. We tried that. It doesn't hold up. The Claude and ChatGPT desktop apps simply didn't respect the PAC configuration; traffic went where the app decided it should go, not where the proxy settings said it should go. And that's the pattern more broadly: some agents will honor proxy environment variables, some hardcode the provider's API URL directly into the binary or SDK, and the moment any app is free to ignore your redirection, your visibility has a hole in it exactly where the riskiest traffic is. If your interception strategy depends on an app cooperating, the apps that don't cooperate are exactly the ones you can't see. You won't know which ones those are until something has already gone wrong.

That's the gap that pushed us down into the operating system itself.

What going that deep actually buys you

Our endpoint agent, marv-agent, runs as a daemon paired with OS-native interception: a kernel-level driver on Windows, and Apple's Network Extension framework on macOS. It's deployed the same way you'd push any other endpoint security tool, through Intune or Jamf. Because it's built into the OS's own networking stack rather than sitting off to the side hoping traffic gets routed to it, an app can't simply opt out the way it can with a PAC file or a proxy env var. Paired with a local CA certificate, that lets us intercept HTTPS traffic to configured AI provider domains regardless of how the calling application is configured, including apps that hardcode the provider's URL. That's the piece a config-based or proxy-setting approach can't close: coverage doesn't depend on the calling code choosing to route through you.

From that vantage point, we can see a lot that isn't visible from the browser or the network edge: not just coding agents and scripts, but AI desktop apps themselves, like Claude Desktop and Codex. Two things in particular become possible:

We see both sides of the MCP conversation. When an AI coding agent calls a tool, our MCP proxy sits directly in that process tree, inspecting both the outbound tools/call request and the inbound tools/list response, before either reaches the agent or executes on the host. That matters because some of the ugliest failure modes in agentic AI are hidden in the tool definitions themselves: a tool description with hidden instructions designed to hijack the agent, or a tool result carrying a prompt injection payload. You can't catch that by watching a browser tab, and you often can't catch it by watching network flows either, because by the time it's on the wire it may already be an opaque, encrypted MCP payload. Sitting between the agent and the server, we can also gate the MCP server itself before it ever launches: catching typosquatted packages or malicious script content at the supply-chain layer, before the process starts.

We see direct API calls that never touch a browser. The same daemon runs an API proxy that sits in front of the major LLM provider APIs. Local scripts, custom agent frameworks, and desktop AI apps that call Anthropic, OpenAI, or similar APIs directly get classified in the same pipeline as everything else: the request body, system prompt, and attached documents get scanned for PII, prompt injection, and company-specific sensitive content, all on-device, before the request leaves the machine.

The honest tradeoff

We're not going to pretend OS-level interception and a CA certificate are a free lunch. It's a heavier install than a browser extension or a PAC file, and it's a deliberate choice: full coverage of the agent and API surface requires it, and there isn't currently a lighter-weight, config-patched alternative that gives the same guarantee across every framework an engineering team might use. We'd rather be upfront that the depth is the cost of the coverage, instead of shipping something that looks lighter but quietly misses the traffic that matters most, which is exactly what happened when we relied on PAC.

The underlying belief is simple: as more of an employee's AI usage moves from "a website you visit" to "an agent with tool access running as a process on your laptop," the visibility has to follow it there too. The browser extension still covers the browser surface well on its own and remains a strong standalone starting point for a lot of teams. But for the agent and API surface, nothing short of running at the level of the operating system tells you what an agent is actually doing, what it's calling, what it's being told to do by a tool result, and what data is about to leave the machine. That's why we went as deep as we did.

‍