A few months ago I gave an autonomous agent write access to a real database. It was a LangChain-style loop — plan, call a tool, observe, repeat and one of the tools ran SQL.
It worked great in the demo. Then I watched it, during a "clean up the test rows" task, generate this:
sql
DROP TABLE users;
It didn't run (staging, and I was watching). But the lesson landed: the LLM doesn't know the difference between a destructive command and a safe one until it's already calling the tool. And by then your code is one cursor.execute() away from an incident.
**"AI firewalls" guard the wrong side**
When I went looking for protection, almost everything in the "LLM security" space guards the inbound side — prompt injection, jailbreaks, PII in the input. Useful, but it's the wrong end for an autonomous agent. My problem wasn't a malicious prompt. It was a well-meaning agent emitting a catastrophic action.
What I actually wanted was a firewall on the outbound side; the tool calls themselves:
- destructive SQL (DROP TABLE, unscoped DELETE)
- writes to prod / ALTER ... DROP COLUMN
- SSRF and cloud-metadata fetches (169.254.169.254)
- bulk secret / API-key reads
- runaway retry loops draining your token budget
And critically: I wanted the catch to be deterministic. If your safety layer is itself an LLM call, it's slower, costs money, and can be talked out of it. A DROP TABLE should be blocked by a rule, not a vibe.
**The 2-minute version you can run right now**
I ended up building this and putting the SDK on PyPI. Here's the whole thing; it blocks a live DROP TABLE offline, with no API key, using built-in policy seeds:
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 on your tool function. The destructive call gets intercepted before your
function body runs, and you get a block result back insteateway,
no account, no LLM in the hot path as it runs entirely on your machine.
▎ Note: the package is agentx-security-sdk (import path agentx_sdk), version ≥ 0.3.11.
**How the block works**
The decorator wraps your tool call and runs the arguments through a layer of deterministic
checks before execution including pattern + structural rules for s
(destructive SQL, prod writes, SSRF targets, secret-store reads, no-progress loops). If a rule trips, the call returns a block instead of executing. No the floor, which is why it works with no key and adds negligible latency.
There's more above that floor — it can escalate ambiguous-but-dangerous actions for a human-in-the-loop decision, circuit-break a runaway loop, reframe and retry the run instead of just dying. But the part I want you to be able to verify in 2 minutes without trusting me is the whole point of leading with it.
**Why I'm posting this**
I'm looking for a handful of people running real Python agents; something that touches a
live DB, cloud, files, or money, ideally unattended to stack and
tell me where it's wrong. Not a launch, not a sales pitch. I want to know:
- Does it catch the thing that would've bitten you?
- What dangerous action shape is it missing?
If you've ever thought "what happens when this agent does something irreversible at 2am," I'd genuinely like your take.
- **[Try it live (keyless quickstart)](https://agentx-core.com/?utm_source=devto-firewall&utm_medium=article)**
- Community / tell me what broke: https://discord.gg/PmWR
- Or just reply here. Bonus points for the war story that made you click.
If your agent never touches anything irreversible, ignore me. If it does, the repro's two minutes, and DROP TABLE is a bad way to find out the hard way.
Top comments (5)
The outbound tool-call side is where the real exposure is — framing it as a firewall on tool calls rather than input filtering is right.
Two things I've found useful as complements to the decorator pattern:
Typed tool schemas with explicit allowlists. For SQL specifically, we added a
statement_typeenum to our DB tool accepting only["SELECT", "INSERT", "UPDATE"]. The agent can't passDROPbecause the schema rejects it before the call reaches any inspection layer. Validation is cheaper and more deterministic than pattern matching.Separate tool registries per agent role. A report-reading agent only gets SELECT tools registered. A data-cleanup agent gets UPDATE but with a
max_rowsparameter enforced by the tool definition. The agent can't request more than what its tool kit exposes — privilege separation at the tool layer, not the runtime layer.Different threat models from the decorator: the decorator catches valid calls that happen to be destructive; the typed schema catches disallowed parameter values; the registry catches the agent attempting operations it was never supposed to have. In practice all three layers are doing different work.
@hannune This is the right mental model and "all three layers are doing different work" is exactly how I think about it too. Where you can type-constrain the tool, you should, it is cheaper and more deterministic than inspecting a string, and the agent literally cannot emit a DROP if the schema only accepts SELECT/INSERT/UPDATE. The firewall is moot on that surface and that is a good thing.
Two places I have found the runtime layer still has to exist underneath the typed schema:
Blast radius inside an allowed verb. The enum constrains the verb, not the damage the verb can do. UPDATE is in your allow-set, and
UPDATE accounts SET balance = 0with no WHERE is verb-legal and still catastrophic. Same for a no-WHERE DELETE if cleanup agents get it. max_rows is the right knob for this and it is the same insight a commenter on the other post landed on, gate on the consequence (how many rows, how much spend) not just the operation. The typed schema can carry max_rows, but it can't see "this UPDATE touches every row" without looking at the statement.Tool surfaces you can't enumerate. The enum works because you own the DB tool and can list its parameter space. The cases that pushed us to a runtime layer are the ones you can't enumerate: a raw SQL passthrough, a shell tool, a third-party MCP server with a free-text argument. There is no statement_type to reject when the parameter is an opaque string the agent composes. That is the surface the firewall is really for, the typed registry is strictly better everywhere it applies.
So I read your three layers as: registry for "never had it," typed schema for "disallowed value," firewall for "valid value, valid verb, catastrophic blast radius on a surface you can't pre-constrain." Defense in depth, each catching what the layer above structurally can't.
You are clearly building the same muscle on 2asy.ai and the entity-resolution side. Would genuinely enjoy comparing architectures properly, off the comment thread if you are up for it. There is early access if it is ever useful to you, but mostly I want to compare notes with someone who has shipped this in production.
The "surfaces you can't enumerate" point is the one I keep running into with third-party MCP integrations -- the typed schema approach breaks down the moment the tool's meaningful argument is a free-text string the agent composes. What we ended up doing is treating that as a separate risk tier: tools with opaque string arguments get a confirmation gate before execution in production, regardless of what the schema says about types. Blunt, but it buys time to enumerate the surface before something unexpected happens.
On blast radius: we added WHERE-clause presence enforcement on top of max_rows. If the operation is UPDATE or DELETE, the query parser rejects it at the firewall layer if no WHERE predicate is present, before it even runs the max_rows estimate. It catches the "intended to filter but dropped the clause" class that the type system structurally can't see.
Happy to compare notes on the architecture -- the entity-resolution side has some interesting interaction with the DB firewall question when the agent is writing structured graph updates with keys that have to exist.
Hi @hannune The opaque-string tier is the right instinct, and a blanket confirm is the correct day-one posture for a surface you haven't enumerated yet. The upgrade I'd flag is the thing that lets you climb back down off it: screen the composed string's content for the catastrophic signatures (DROP, no-WHERE DELETE, secret reads, SSRF, rm -rf) so you escalate only the calls that actually look dangerous and let the safe majority through. Otherwise every raw-SQL or third-party MCP call confirms, and you hit the exact fatigue the commenter on the other post described, where the human rubber-stamps the one that mattered. The content screen is what turns "always confirm" into "confirm only the ones worth confirming" as you learn the surface.
WHERE-clause presence enforcement is exactly right, and we gate the same no-WHERE DELETE/UPDATE class hard. The next ring past presence is the vacuous predicate:
UPDATE accounts SET balance = 0 WHERE 1=1has a WHERE, passes presence, and still touches every row. So "has a predicate" shades back into "has a predicate that actually narrows," which is where it rejoins the max_rows estimate you already run. Presence catches the dropped clause, the row estimate catches the tautology, and you end up needing both.The entity-resolution interaction is the part I'd most want to dig into, because it's a different threat model than blast radius: an agent writing graph updates against keys that must exist is a referential-integrity problem, not a too-much-damage problem, and the firewall question changes shape when "safe" means "this key resolves" rather than "this verb is allowed." I have half-formed thoughts there and they're better over a call than a comment box.
I don't want this to die in a comment thread. Want to take the architecture compare somewhere with more room? Reply with whatever's easiest for you (X, email, or a quick call) and I'll come to you. The early access is yours whenever you want to point it at a surface you can't enumerate yet.
Hi @hannune
A quick update from our thread. You added a rule: a DELETE or UPDATE must have a WHERE. We talked about the case it does not catch: WHERE 1=1. It has a WHERE, but it still affects every row.
We fixed that on our side. Our rule now treats a WHERE that is always true (1=1, WHERE true) the same as no WHERE. It blocks the write. A normal condition is still allowed: WHERE 1=1 AND user_id=5 passes, because it really does narrow the rows. The rule runs in one shared place, so both the SDK (pip install agentx_security_sdk) and the MCP proxy (uvx agentx-mcp or pip install agentx-mcp) have it.
Your WHERE rule is what led me to this, so thank you. The entity-resolution case is the one I still most want to compare. When you have time, we can move off the thread. X, email, or a short call, whatever is easy for you.