Why AI Agents Need a Firewall

The shift nobody planned for

A year ago, AI tools suggested code. You reviewed it, copied it, pasted it, and ran it yourself. You were in the loop. You were the operator.

Today, AI tools execute code. Cursor runs terminal commands. Claude Code spawns processes, installs dependencies, and calls external APIs — all autonomously, all on your machine.

This isn't a theoretical risk. It's the default workflow for millions of developers, every day. And it has created a gap that no existing security tool was designed to fill.

What changed: MCP and the agentic explosion

The Model Context Protocol (MCP) turned AI tools into orchestrators. An AI agent can now discover local tools, call them with structured arguments, chain multiple tool calls together, and act on the results — without waiting for human approval.

This is powerful. It's also dangerous. A compromised MCP server can read your SSH keys and phone home. A prompt injection can cause an agent to write to your policy files. A malicious npm package can spawn osascript through a postinstall chain — and none of this triggers your existing security stack.

Why existing tools leave a gap

EDR / XDR is excellent at what it does. Modern platforms like CrowdStrike Falcon and SentinelOne correlate process trees, detect known-bad chains in real time, and quarantine malicious processes. But EDR applies the same policy to every node process — whether it was spawned by a developer in Terminal or by an AI agent acting on a prompt injection. It blocks node → osascriptbecause that's suspicious for any parent — but it can't apply different policy for AI-initiated vs. human-initiated execution of the same binary. It has no concept of agent identity.

SASTscans source code in git. It can't see runtime execution at all. A tool call that reads ~/.aws/credentialsthen curls an external endpoint doesn't exist in your repository — it exists on your laptop, in the moment.

Prompt guardrails filter what goes into the model. They cannot block what comes out as a runtime action. If the model decides to call a tool, the guardrail is already behind the decision boundary.

macOS Sandboxis static and app-scoped. It restricts what a signed application can do — not what an AI agent spawns dynamically across processes and tools. It can't classify AI vs. human intent, and it can't understand behavioral chains.

The gap isn't that your EDR is bad. It's that no tool in your stack knows whether the process was spawned by an AI agent or a human — and that distinction changes everything about the policy you should apply.

What an AI agent firewall is

An AI agent firewall sits between AI applications and your operating system. It intercepts every execution attempt — process spawns, file writes, network connections, package installs — and applies policy before the action completes.

It does three things traditional tools cannot:

1. Classifies the actor. It knows whether a process was spawned by Cursor, Claude Code, an MCP server, or a human in Terminal. Context changes the policy.
2. Correlates causal chains. It builds a behavioral graph linking file reads to process spawns to network connections. A single curl is fine. A readSensitiveFile → networkConnectExternal chain is not.
3. Enforces at the OS level. It uses Endpoint Security AUTH events and Network Extension content filters to approve, block, or prompt — synchronously, before the action completes. Not a log. Not an alert. A gate.

Why macOS specifically

macOS is where developers live. It's where Cursor runs, where Claude Code spawns bash, where MCP servers execute tools, where npm install pulls dependencies with postinstall scripts. The developer laptop is the most agent-dense endpoint in any organization.

And yet, macOS has no native AI execution layer. There is no system-level concept of “this process was started by an AI agent” or “this file read is part of an agentic session.” The operating system doesn't know. Your security tools don't know. Only an AI agent firewall knows.

What TURI does

TURIis the first AI agent firewall built for macOS. It uses Apple's Endpoint Security and Network Extension frameworks — not a kernel extension, not a proxy — to govern what AI agents execute on your machine.

In monitor mode, it shows you everything: which agent spawned which process, what files it read, what network connections it attempted, and how those actions chain together in a behavioral causal graph.

In enforce mode, it blocks: ungoverned runners from AI parents get denied. Secret reads followed by egress get quarantined. Writes to security-sensitive files from agent processes get stopped. The agent still works — it just can't do what you haven't approved.

Honest limits

TURI is in beta. Supply-chain install gates default to off. Behavioral detection is async — it catches the next action, not always the first. Some rules are alert-only until you promote them. K8s and cloud runtime are out of scope.

We publish a full evaluation matrix with known gaps. We don't pretend to be complete. We prove what works, show what doesn't, and let you run the labs yourself.

The category is real. The threat is now.

Every developer using AI coding tools today is running an autonomous agent on their machine. Every npm install triggered by Cursor, every bash call from Claude Code, every MCP tool execution is an unreviewed action on a production endpoint.

The question isn't whether AI agents need a firewall. It's whether you have one.