The market for AI-agent security has three main shapes — the static scanner, the MCP gateway and the runtime agent firewall — and they’re easy to confuse because the pitches overlap. They are not substitutes. They cover different parts of the problem. Here’s how to tell them apart and what a mature setup actually uses.
Static scanners check the artifact once
Snyk (via Invariant Labs), Lasso, and similar tools inspect a skill or MCP server before you install it, looking for known-risky patterns.
Good at: catching obviously malicious or vulnerable artifacts up front, in CI.
Blind to: anything that happens after install — the rug pull where a vetted server ships a poisoned update, runtime-conditional behaviour, and payloads that only assemble at call time. A scan is a point in time; the risk is continuous.
Network MCP gateways watch the traffic that crosses the network
Runlayer, MintMCP, Obot and others put a central proxy in front of your MCP servers with a registry, RBAC and logging.
Good at: governing hosted MCP servers reached over the network, centrally, for a whole org.
Blind to: what never crosses the network. A local stdio MCP server on a developer’s laptop, and the agent’s own Bash call doing cat ~/.ssh/id_rsa, don’t pass through a network gateway at all. rm -rf, reading a local secret, curl | sh — none of these are network events.
Runtime agent firewall: the call path on the machine
This is the last mile: a control on the developer’s machine that decides, per call, whether an action is allowed, covering local stdio MCP servers and the agent’s native file and shell tools.
Good at: stopping the action at the point of execution, where a skill that reads clean and behaves badly actually does damage. Least-privilege per call, rug-pull holds, and a tamper-evident local log.
Blind to: nothing on the local machine by design, but it’s stdio-first today (hosted HTTP MCP is a gateway’s job) and it doesn’t stop prompt injection itself — it gates the action the injection asks for. airlock_ai is this category.
Side by side
- Hosted MCP over HTTP: gateway ✔ · scanner — · firewall (roadmap)
- Local stdio MCP on a laptop: gateway ✘ · scanner partial · firewall ✔
- Agent’s native Bash / file tools: gateway ✘ · scanner ✘ · firewall ✔
- Decision at the moment of the call: gateway ✔ · scanner ✘ · firewall ✔
- Rug pull, with calls held: gateway partial · scanner detect-only · firewall ✔ hold
- Runs with no vendor cloud: gateway ✘ · scanner partial · firewall ✔
So which do you need?
If you run agents at any scale: a scanner in CI to catch bad artifacts early, a gateway if you have hosted MCP servers to govern centrally, and a runtime firewall on the machine for the last mile the other two can’t see. They compose, so buying one doesn’t make the others redundant. The common gap we see is the third: teams have a scanner and maybe a gateway, and nothing watching the agent’s local shell and stdio servers.
That gap is what airlock_ai fills. And if you want to know which parts of your stack are actually exposed, that’s a AI agent penetration test.
Frequently asked questions
Can one product do all three? Not well — they enforce at different boundaries (CI, network, local call path). Expect to combine.
We already have a gateway. Do we still need a firewall? Ask your gateway what happens when the agent runs cat ~/.ssh/id_rsa in a local shell. If the answer is “nothing,” that’s the last mile. See securing Claude Code and Cursor.
Mapping your agent security? Start with airlock_ai for the last mile, or ask us for an assessment.