The AI agent security market has gone from nearly empty to crowded in under a year. Scanners, firewalls, proxies, gateways, guardrails, governance platforms. The names overlap. The categories blur. And most teams aren’t sure which ones they actually need.

This page maps the tool landscape by category. Each section explains what the tools in that category inspect, what they miss, and where they fit in a defense stack. Named tools are included as examples, not endorsements. Evaluate them against your own threat model.

Tool categories

AI agent security tools break into five groups based on when they run and what they inspect:

CategoryWhen it runsWhat it inspects
ScannersPre-deployMCP server configs, tool descriptions, known vulnerabilities
Runtime firewalls/proxiesDuring executionHTTP traffic, MCP messages, tool arguments, tool responses
GatewaysDuring executionRouting, access control, tool discovery
Inference guardrailsDuring executionPrompts and completions (text classification)
Governance platformsContinuousAgent inventory, policy enforcement, compliance reporting

No single category covers the full attack surface. Scanners miss runtime attacks. Firewalls miss pre-deploy misconfigurations. Gateways miss content-level threats. A real defense stack combines at least two.

Scanners

Scanners check MCP servers and agent configurations before deployment. They run once (or in CI) and report findings. They don’t sit in the traffic path at runtime.

What they check: Tool descriptions for hidden instructions, known CVEs in MCP server packages, configuration mistakes (overly broad permissions, missing authentication), and supply chain risks in dependencies.

What they miss: Anything that happens at runtime. A tool description that’s clean at scan time can change mid-session (rug-pull). Credential leaks in tool arguments only happen during execution. Prompt injection arrives in responses the scanner never sees.

Examples:

Scanners are the cheapest first step. Run them in CI on every MCP configuration change. But don’t confuse pre-deploy scanning with runtime protection. They solve different problems.

Runtime firewalls and proxies

Runtime tools sit in the traffic path between the agent and external services. Every request and response passes through them. They inspect content, not just routing.

What they inspect: HTTP request bodies, headers, and URLs for credential patterns (DLP). HTTP responses for prompt injection. MCP tool arguments for secret leaks. MCP tool responses for injection payloads. Tool descriptions for poisoning. DNS queries for exfiltration patterns.

What they miss: Local file system operations (no network hop to intercept). In-memory reasoning corruption. Attacks that don’t produce network traffic. These require agent-side hooks or sandboxing.

Examples:

The core question for any runtime tool: does it inspect content or just control access? Domain allowlisting stops requests to unapproved servers but won’t catch a credential leaked to an approved domain.

Gateways

Gateways focus on routing, discovery, and access control for MCP servers. They decide which agents can reach which tools and manage the connection lifecycle.

What they handle: Tool discovery (agents find available servers through the gateway), access control (per-agent or per-team permissions), connection management (transport bridging between stdio and HTTP), and routing (multiple MCP servers behind one endpoint).

What they miss: Content-level threats. A gateway that routes traffic to an MCP server doesn’t inspect whether the tool arguments contain leaked credentials or whether the response contains injection. Access control says “this agent can use this tool.” Content inspection says “this specific tool call is safe.”

Examples:

Gateways and firewalls are complementary. The gateway controls who can talk to what. The firewall controls what’s allowed in the conversation. Large deployments often run both.

Governance platforms

Governance platforms operate at the organizational level. They discover agents running across teams, enforce centralized policies, and produce compliance reports.

What they handle: Agent discovery (finding every agent and MCP server in the organization), policy enforcement (centralized rules for what agents can do), compliance reporting (mapping agent activity to frameworks like SOC 2, NIST, EU AI Act), and risk scoring.

What they miss: Packet-level inspection. Governance platforms set policy. Enforcement still requires runtime tools (firewalls, proxies, gateways) that actually sit in the traffic path. A policy that says “no credential exfiltration” needs a DLP scanner to enforce it.

Examples:

Governance matters when you have dozens of teams running hundreds of agents. If you have three agents, start with runtime controls. Add governance when the management problem outgrows spreadsheets.

How to choose

If you need…Start with…Examples
Pre-deploy config checkingScannermcp-scanner, mcp-scan
Credential leak preventionRuntime firewall with DLPPipelock
Prompt injection blockingRuntime firewall with injection scanningPipelock, inference guardrails
MCP tool access controlGatewayDocker MCP Gateway, agentgateway
Domain-level egress controlProxy with allowlistsPipelock, iron-proxy
Multi-team agent managementGovernance platformZenity, Noma
Compliance evidenceFirewall with audit logging + governancePipelock (flight recorder), Zenity
Red teaming and evaluationTesting frameworkPromptfoo

For a single team running agents with network access: start with a runtime firewall (covers the widest attack surface with the least integration), add a scanner in CI, and add governance when the fleet grows.

For an enterprise with many teams: start with governance to get visibility, then deploy runtime firewalls per-team to enforce the policies.

Further reading

Ready to validate your deployment?