Your API gateway can't see your AI agent run rm -rf

If you run AI agents in production, someone on your team has probably already asked where the guardrails go. The common answer is "the same place all our other guardrails go: the API gateway." Cloudflare, an egress proxy, a WAF. It is where you already centralize policy, so it feels like the obvious home for agent safety too.

For network traffic, it is. For agent actions, there is a hole in the middle of it.

What the gateway actually sees

An API gateway sits on the wire. It inspects outbound HTTP. That is the right tool for "block this domain," "strip this header," "rate-limit this route."

Now watch what an autonomous agent actually does in a single step:

• it calls a tool that runs subprocess.run(["rm", "-rf", path])
• it reads .env or /etc/shadow off the local disk
• it sends SELECT name FROM users; DROP TABLE users; down the database driver's own socket

The first two never become HTTP the gateway can inspect. The third is a syntactically valid query on a connection the gateway either does not terminate or cannot judge for intent. Your network guardrail is blind to all three, and those are the calls that actually end companies.

This is not a config option you forgot to turn on. It is structural. The gateway lives on the network. These actions happen inside the process, before anything reaches the network, or on a socket the network layer cannot read intent from.

The other half: a block that kills the run

Say your gateway does catch something. It returns a 403. In a normal web app, fine. In an autonomous run, that 403 lands in the middle of a multi-step task and the agent gives up. You did not get safety. You traded one broken outcome for another, and you burned the tokens getting there.

Security at the execution layer

The fix is to move the check to where the agent acts: inside the process, at the point where the model's text becomes a real action, right before it executes.

That is what AgentX does. Two ways to add it, both keyless, nothing leaves your machine for the block:

• Decorator on your Python tools: @agentx_protect.
• One line in mcp.json if your agent speaks MCP. agentx-mcp is a stdio proxy that screens every tools/call before it reaches the real server, so there is no per-tool wiring to forget.

The block is deterministic. A DROP TABLE, an unscoped DELETE, a secret read, an SSRF to 169.254.169.254, an rm -rf: caught by a rule, in process, with no model in the hot path and no key. You can verify that in two minutes.

And because the check runs where the agent is thinking, the block does not have to end the run. Instead of a dead 403, the agent gets what it needs to correct and finish the task. On the MCP path the agent's own model does the correcting, so you can watch the whole block-and-recover loop for free.

Try the distinction yourself

Ask whoever owns your gateway one question: how does it stop an agent from running a local subprocess.run("rm -rf") or reading /etc/shadow? If the honest answer is "it doesn't," that is the gap, and no amount of network policy closes it.

Then wrap one real tool or one MCP server and tell me two things:

• What did it catch that would have bitten you?

• What did it miss? Try to stump it.

• Watch the catch-and-recover live

• Tell me what broke or what it missed: Discord

If your agents only ever call read-only HTTP APIs, your gateway is enough. The moment they touch a shell, the filesystem, or a database, the guardrail has to live where the action does.