Methodology

What each category does

Runtime firewalls and proxies

1. Pipelock

2. iron-proxy

3. Backslash Security

4. Promptfoo

5. Nightfall AI

MCP scanners

6. Cisco mcp-scanner

7. Snyk agent-scan (formerly Invariant)

8. Enkrypt AI

MCP gateways

9. Docker MCP Gateway

10. Runlayer

11. agentgateway

Governance platforms

12. Zenity

13. Noma Security

Inference guardrails

14. LlamaFirewall

15. NeMo Guardrails

How to choose

The layered approach

Further reading The AI agent security market went from a handful of projects to a crowded field in about twelve months. Scanners, firewalls, proxies, gateways, guardrails, governance platforms. The category names overlap, the marketing copy blurs together, and nobody ships a single tool that covers every threat. This post is a fair, category-by-category tour of 15 tools that are actually shipping in 2026. It is a listicle, but the goal is to be the page other people cite when they explain the landscape. That means honest strengths, honest limits, and no pretending one tool solves every problem. I build one of these tools, Pipelock. I have tried to write about it the same way I write about everyone else. If you think I missed a strength or oversold a weakness, the repo is public and the tests are public. Open an issue. Five categories, based on where a tool sits in the agent stack and what it inspects: Inclusion rules. The tool has to be in active development, shipping code or a hosted service as of April 2026, and aimed at AI agent or MCP security specifically. I left out tools where the parent product has been folded into a larger platform and the standalone name no longer ships. I left in Snyk agent-scan because the Invariant product continues under the new name. Pricing, funding, and acquisition status come from public announcements. For capabilities I could not confirm in public docs, I say "not documented in public docs" instead of guessing. That is a habit from writing comparison pages. It also keeps the post honest when somebody asks "where did you get that number." Runtime firewalls and proxies sit in the traffic path. Every HTTP request, every MCP tool call, every response passes through them. They scan content for credential leaks, prompt injection, SSRF, tool poisoning, and related threats. Good ones work on the wire so they cover any agent that makes network calls, not just a specific SDK. MCP scanners run before you deploy an MCP server or in CI. They check tool descriptions for hidden instructions, look for known-vulnerable packages, flag permission problems, and pin descriptions to detect rug-pulls. They do not sit in the runtime path, so anything that happens during execution is invisible to them. MCP gateways route traffic between agents and MCP servers. They handle discovery, authentication, access control, transport bridging, and sometimes observability. Most of them do not inspect content. A gateway answers "can this agent talk to this server," not "is this specific call safe." Governance platforms live at the org level. They discover agents running across teams, roll up policies, produce compliance reports, and score risk. They set policy. Enforcement still needs runtime tools in the traffic path. Inference guardrails wrap the model itself. They classify prompts and completions, block jailbreaks, and filter outputs. They run inside the application, close to the LLM call, and they see text rather than network traffic. No single category covers the full attack surface. Most real deployments combine at least two. Open source agent firewall, written in Go, ships as a single binary. Sits between agents and external services as a content-inspecting egress proxy for HTTP and MCP traffic. Scans requests for credential leaks using a DLP engine with multi-layer decoding, scans responses for prompt injection, blocks SSRF, and scans MCP tool descriptions for poisoning and rug-pulls. Wraps MCP servers through stdio or HTTP. Hash-chained audit logging for compliance evidence. Best for: teams running agents with network access who want open source, content-level egress protection without adopting a vendor SDK. Links: Pipelock site, GitHub. Open source Go proxy focused on domain allowlisting for agent traffic. Uses MITM TLS interception to see inside HTTPS traffic. Includes a boundary secret rewriting approach that replaces secrets with placeholders at the proxy edge so the agent only ever handles rewritten values. Best for: teams that like the secret-rewriting model and want a small, auditable Go proxy they can self-host. Commercial AI security platform. Raised a reported $27M total ($19M Series A) and ships MCP coverage, DLP, and IDE integration aimed at developer workflows. Focus is on protecting the developer path from source editor through agent tooling, with policies that follow code as it moves through CI. Best for: engineering orgs that want AI coding assistants and MCP tooling governed the same way they govern the rest of their SDLC. Link: backslash.security. Open source LLM testing and red teaming framework with an MCP proxy mode that can intercept tool calls during test runs. OpenAI announced plans to acquire Promptfoo in March 2026; the deal is pending closing as of this writing. Primary use case is evaluation, regression testing, and adversarial red teaming rather than inline production blocking. Best for: teams building an eval and red team pipeline for LLM apps and agents, especially pre-production. Commercial DLP-first platform. Started in classic SaaS DLP (Slack, Jira, Google Drive) and extended into AI traffic. Markets itself as a firewall for AI, with emphasis on sensitive data discovery, classification, and blocking across AI chat and agent traffic. Best for: regulated enterprises that already run Nightfall for SaaS DLP and want their AI traffic in the same console. Open source scanner for MCP servers from Cisco's AI Defense team. Combines YARA rules with LLM-based analysis to flag tool poisoning, cross-origin escalation, and known vulnerability patterns in tool descriptions and configs. Best for: teams that want a vendor-backed MCP scanner in CI with both deterministic and LLM-driven checks. Link: github.com/cisco-ai-defense/mcp-scanner. MCP scanner originally built by Invariant Labs, acquired by Snyk in 2025. The product continues under the Snyk name and integrates with Snyk's broader security workflows. Pins MCP tool descriptions and flags changes over time, catching rug-pull patterns. Licensing and deployment options are documented in Snyk's product pages rather than in a single open-source repo. Best for: Snyk customers who want MCP scanning in the same dashboard as their existing code security checks. Commercial AI security platform that includes MCP scanning alongside red teaming and model evaluation. Scans tool descriptions against known attack patterns, with continuous monitoring for changes in deployed servers. Best for: teams that want MCP scanning and LLM red teaming from one vendor. Open source gateway from Docker that manages containerized MCP servers. Agents connect to the gateway, which routes to servers running in isolated containers. Includes a --block-secrets flag that filters secret-shaped data from tool responses, plus call tracing for observability. Best for: teams running MCP servers in containers who want Docker-managed isolation and basic secret filtering out of the box. Link: github.com/docker/mcp-gateway. Cloud MCP control plane. Raised a reported $11M. Hosts MCP servers, manages access control across teams, and provides usage analytics. Aimed at orgs that want a registry and central management rather than running MCP infrastructure themselves. Best for: teams that want someone else to run MCP infrastructure and would rather pay than patch. Open source gateway from Solo.io, recently contributed to the Linux Foundation. Written in Rust. Handles MCP and agent-to-agent traffic with JWT authentication, RBAC, and observability hooks. Positioned as the neutral open source gateway for multi-agent systems. Best for: teams that want a vendor-neutral, open source gateway they can deploy as a sidecar or ingress in front of many agents. Link: github.com/agentgateway/agentgateway. Commercial agent security governance platform. Raised a reported $38M Series B. Discovers agents running across an organization, builds an inventory, assesses risk, and enforces policy. Positioned for enterprise programs where the hard problem is "how many agents do we even have." Best for: enterprises with many teams shipping agents independently who need inventory and policy before they can even talk about enforcement. Commercial AI security platform covering model supply chain risk, runtime monitoring, and agent governance. Pitches a single pane of glass across data science and agent workflows. Best for: orgs that run both classic ML pipelines and LLM agents and want one vendor for both. Link: nomasecurity.com. Open source Python library from Meta's PurpleLlama project. Provides classifiers for prompt injection, jailbreaks, and unsafe outputs at the model layer. Ships as a library that wraps LLM calls rather than a network proxy. Best for: Python-native agent stacks that want prompt injection and jailbreak classification close to the LLM call. Link: github.com/meta-llama/PurpleLlama. Open source framework from NVIDIA. Uses a DSL called Colang to define conversational rails, safety checks, and topic boundaries for LLM applications. Supports custom actions, integration with other guardrail models, and fact-checking flows. Best for: teams building conversational LLM apps who want structured, auditable safety rules at the application layer. Link: github.com/NVIDIA/NeMo-Guardrails. Start with the threat you are actually worried about. The table below maps common problems to the category that solves them first. One team, a handful of agents, limited budget: start with a runtime firewall. It covers the widest attack surface with the least integration cost. Add a scanner in CI once the firewall is stable. Many teams, hundreds of agents, compliance pressure: start with a governance platform to get an inventory, then deploy runtime firewalls per team to enforce policies the governance platform sets. Pure research or prototyping: inference guardrails and a test framework are enough. You do not need a production firewall for a notebook. Every honest security vendor will tell you this: no single tool covers the full attack surface. The categories catch different things. A real defense stack picks at least two layers. Scanner plus runtime firewall is the most common starting combination. Governance joins when the fleet outgrows spreadsheets. Inference guardrails are extra defense-in-depth for conversational apps. Gateways show up when the MCP surface area gets big enough that routing and access control are their own problem. Expect to stitch tools together. The market will eventually consolidate, but 2026 is not that year. If I missed a tool that deserves a spot on this list, open an issue on the pipelab.org repo and tell me why. I would rather be corrected than wrong. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - Runtime firewalls and proxies that inspect traffic content in real time.

- MCP scanners that check server configurations before deployment.- MCP gateways that control routing and access between agents and tools.- Governance platforms that manage agents at org scale.- Inference guardrails that sit at the model layer. - Content inspection on every hop, not just domain filtering. Catches credential leaks to allowlisted hosts, which allowlists alone cannot.- Single binary, systemd friendly, works with any agent that respects HTTPS_PROXY. No SDK lock-in.- Hash-chained flight recorder gives tamper-evident audit logs for incident response and SOC 2 style questions. - Runtime only. It does not scan MCP servers before deployment, so pair it with a scanner in CI.- Network-only scope. In-memory reasoning corruption and local filesystem abuse do not generate network traffic, so a network proxy cannot see them. - Boundary rewriting is a clean design for keeping real credentials out of the agent's working context.- Open source, Go, small surface area, easy to read and reason about. - Content scanning beyond allowlisting and secret rewriting is not documented in public docs at the time of writing.- MITM certificate trust has to be installed in every agent environment, which adds ops overhead on managed endpoints. - IDE integration meets developers where they work, which helps adoption in engineering orgs.- DLP plus MCP coverage in one product avoids stitching two vendors together. - Commercial only. No open source path for teams that want to self-host everything.- Best fit is IDE-centric workflows. Non-developer agents get less direct value. - Strong red team and eval story. Catches regressions and jailbreaks before they ship.- Open source, large community, wide LLM provider support. - Primary mode is testing, not production blocking. Teams that want an inline enforcement point should not treat it as a drop-in firewall.- Acquisition is pending. Roadmap and license terms could shift once the deal closes. - Mature DLP engine, built for regulated environments with long-running compliance programs.- Covers both SaaS DLP and AI traffic in one product, which simplifies vendor management for enterprise buyers. - Commercial only. SMBs and open source shops often find it overkill.- AI agent features are newer than the SaaS DLP core, so specific MCP capabilities should be verified against current docs. - Hybrid YARA plus LLM approach catches both pattern-based and semantic issues.- Backed by a large vendor, which tends to mean steady rule updates. - Pre-deploy only. Nothing in this tool inspects runtime traffic.- LLM-based analysis has cost and latency implications at scale; run it in CI rather than on every request. - Description pinning is a strong defense against rug-pull attacks where a server changes its tool metadata mid-session.- Native integration with Snyk workflows means one place for SCA, SAST, and MCP scanning. - Pre-deploy and CI focus. Runtime MCP traffic inspection is out of scope.- Acquisition means roadmap is tied to Snyk's priorities, which may or may not match a given team's direction. - Scanning plus red teaming in one platform, so you can go from "what are my MCP servers doing" to "what happens when I attack them."- Continuous monitoring catches changes after the initial scan. - Commercial platform with broader scope than pure MCP scanning, which can be too much for small teams that just want a CI check.- Public feature set changes quickly; verify specifics against current docs before committing. - Container isolation is a strong boundary. Each MCP server runs in its own sandbox, limiting blast radius.- Call tracing plus the block-secrets flag give a baseline of runtime visibility and protection without a separate firewall. - Gateway focus means content inspection beyond the secret-blocking flag is narrow. For full DLP coverage, pair it with a runtime firewall.- Docker-native workflow works best if the rest of your stack is already Docker-shaped. - Fully hosted, so teams skip the infra work of running and patching MCP servers.- Central access control and analytics give a clean story for audit and spend. - Hosted model means your MCP traffic goes through a third party, which some regulated shops will not accept.- Hosted MCP catalog is only as useful as the servers it offers for your use case. - Linux Foundation project reduces single-vendor risk compared with a company-owned gateway.- Rust core is fast and has a tight memory footprint, which matters in sidecar deployments. - Gateway scope. Content inspection beyond routing and auth is not the focus.- Younger project than some commercial alternatives; some advanced features are still landing. - Discovery story is strong. Finding shadow agents and MCP servers is a real problem at scale and Zenity has been working on it longer than most.- Enterprise-grade policy and reporting aligned with existing GRC workflows. - Governance first, enforcement second. You still need runtime tools in the traffic path to actually block anything.- Enterprise pricing model is a poor fit for small teams with a handful of agents. - Covers both classic ML supply chain and agent runtime, which is rare in one product.- Runtime monitoring complements the governance features rather than replacing them. - Broad platform means any given feature may be shallower than a best-of-breed point tool.- Commercial only, with enterprise-shaped contracts. - Backed by a well-funded research team with a steady release cadence.- Python library fits naturally into agent code that already calls LLMs from Python. - Library integration means every agent has to adopt the SDK. Agents in other languages or behind opaque frameworks get no coverage.- Model-layer classifiers catch prompt-shaped threats but do not see network egress, so credential leaks in tool calls are out of scope. - Colang gives a structured way to express conversation policy, which is easier to audit than a pile of system prompts.- Mature project with documentation, examples, and a growing ecosystem. - Framework requires learning Colang and wiring rails into every application, which is real adoption work.- Focus is conversational safety and grounding, not network-level agent threats like credential leaks or SSRF. - Scanners catch problems that exist before deployment.- Runtime firewalls catch problems that only show up during execution.- Gateways control who can talk to what.- Governance platforms tell you what you have and whether it matches policy.- Inference guardrails catch prompt-shaped threats close to the model. - AI Agent Security explains the three layers of agent security and where each tool category fits.- AI Agent Security Tools is the long-form tool landscape guide this post draws from.- Open Source AI Firewall focuses on the open source end of the runtime firewall category.- Pipelock Comparisons walks through head-to-head positioning against specific alternatives.- Pipelock is the open source agent firewall I build.- Pipelock on GitHub has the code, the tests, and the issues.