The more developed our agents are, the more we want them to make jobs easier for us,so we hand over the ability to do tasks like read files, query databases, send emails, e.t.c. to them.
If that agent reads untrusted content, it can be manipulated into running destructive commands.
I wanted a guardrail for this, so I built WALL-A, an open-source runtime security gateway for AI agents. I built it on my mobile phone using Termux.
What is WALL-A?
WALL-A is a barrier that sits between an AI agent and its tools, where the agent only holds a WALL-A API key not the database credentials.
When an agent attempts an action, WALL-A evaluates it:
1. Deterministic Rules: It uses string checks and patterns (not AI judgment) to block destructive SQL like DELETE without a WHERE clause, path traversal like ../../etc/passwd, and leaked keys.
2. Taint Tracking: If an agent fetches a URL, WALL-A taints the session whereas any subsequent high-impact action (like sending an email) is held for human approval.
3. Signed Audit Logs: Every action is recorded in a hash chain signed with Ed25519. If someone manually edits the database, the dashboard flags it as TAMPERED.
The Test
I connected WALL-A to Claude using the Model Context Protocol (MCP). I asked Claude to run a query that would delete from my users table.
Claude's reply was:
So this proves that a deterministic firewall acts as a hard boundary even though the AI sent the tool call, the gateway refused to execute it. (Note: WALL-A also blocks rephrased versions of destructive queries).
What I Learned
1. Multi-tenancy: I learned how to isolate data so different users (workspaces) don't see each other's logs. Every database table now uses a client_id.
2. Termux Constraints: Pasting secrets into Termux actually gave me some issues so I had to generate them in the terminal and move them using files.
3. Caching: I kept seeing an old cached page and thought my deployments were broken. Adding cache: "no-store" to the API fetches fixed it.
Incoming finalizations
· The tools (send_email, db_query) are currently simulated & they don't hit a real database or SMTP server yet.
· There are no user logins because your workspace is tied to your browser's local storage.
You can test it here:
· Demo: wall-a.vercel.app/demo
· Code: github.com/superwavvy/wall-a
You can create a connector link at /connect to try it with your own Claude client.
Top comments (0)