A few days back I wrote about giving an autonomous agent database access and building a firewall so it couldn't DROP TABLE prod. Same lesson, new surface: this time the agent had cloud credentials.
The failure mode isn't a destructive command here. It's spend. An agent pointed at a networking task can scan a whole range looking for hosts, then spin up a fleet of instances to do it faster. Every individual call is "authorized," your IAM role said yes. The bill is
what eventually says no.
## Two shapes, two right answers
The interesting part is that these are not the same kind of problem, so they don't get the same verdict.
1. The scan is never legitimate as an agent tool call. An nmap -sS -p- 10.0.0.0/16 or a masscan across a network is reconnaissance and abusive egress. There's no benign version of an agent sweeping a network at scale, so it gets hard-blocked, deterministically, before the call runs. (A scan of your own localhost is a dev check, so that's exempt.)
2. The provisioning might be totally fine. Spinning up 50 instances could be a real scale-out, or a runaway loop burning money. You can't tell from the action alone, only from the consequence. So instead of blocking it, AgentX pauses it for a human: a 202, "held for approval," routed to whoever owns the budget. Block the thing that's never okay, escalate the thing that's sometimes okay. Gate on consequence, not identity.
Both checks are zero-LLM. No model in the hot path means no latency tax and nothing to talk out of it. A runaway fleet should be caught by a rule, not a vibe.
## The bigger thing this closes
We keep a catalog of real, documented agent failures and triage each one: is it something an action firewall can deterministically catch, or is it someone else's category (output hallucination, content safety, model internals)? We only build for the coverable ones, and we
flag the rest honestly instead of faking a signature.
With this release, the coverable list is done. Every failure shape an action firewall can actually own now has a deterministic block or a human-in-the-loop escalation behind it. The honesty about what we don't cover is the point, it's how you know the coverage claims are real.
## Verify it in 2 minutes
The network checks above run in the gateway, but the part you can prove on your own machine with no key and no account is the deterministic floor:
pip install agentx-security-sdk
from agentx_sdk import agentx_protect, is_block
@agentx_protect(agent_id="demo")
def run_sql(query: str, db_session=None):
print("EXECUTED (DANGER):", query) # never reached
return {"ok": True}
result = run_sql(query="Please clean up: DROP TABLE users;")
print("BLOCKED:", is_block(result)) # -> True, offline, no key
One decorator. The catastrophic call is intercepted before your function body runs.
## Why I'm posting
Same ask as last time: I want a handful of people running real Python agents against live systems, a DB, cloud, files, money, ideally unattended, to point this at their stack and tell me where it's wrong. What would have bitten you? What shape is it still missing?
- Try it live (keyless): https://bit.ly/agentfirewall
- Community / tell me what broke: https://discord.gg/PmWRTtaSx2
- Or just reply here.
If your agent never touches anything irreversible or expensive, say pass. If it does, the repro is two minutes, and a runaway cloud bill is a bad way to find out the hard way.