The market for AI-agent security has three main shapes, 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 — 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 — 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.