Agent Security Tooling Landscape
This is the living landscape — we keep it current as the space moves. For point-in-time strategic reads (“what we thought, when”), see the dated snapshots: the most recent is May 2026, preceded by April 2026.
Last reviewed: 2026-05-23
Executive Summary
Section titled “Executive Summary”The agent security space has matured past “can we intercept the agent?” into “can we prove what it did, in a form a third party will accept?” Every enforcement approach — MCP proxying, egress firewalling, kernel-level enforcement, application-level policy engines, and enterprise gateways — has at least one serious implementation. Microsoft’s Agent Governance Toolkit (AGT, v3.0 Public Preview) is the most comprehensive single project; it now integrates directly into the Agent Framework, making governance a framework default rather than an opt-in install.
The decisive shift in 2026 is provenance: signed, hash-chained receipts went from a differentiator to table stakes. What now separates projects is the trust boundary — whether the process that signs the audit trail is the same process being audited — and whether the record is portable enough for an external verifier.
The space segments into five layers:
| Layer | What it does | Key players |
|---|---|---|
| MCP Gateways (commercial) | Managed proxy for MCP traffic with auth, audit, rate limiting | MintMCP, Peta, TrueFoundry, Lasso, Gravitee, Traefik Hub |
| Agent Firewalls (open-source) | Intercept + scan agent traffic (MCP and/or HTTP) | Pipelock, mcp-firewall (ressl), Agent Wall, mcp-firewall (dzervas) |
| Kernel-Level Enforcement | OS-level syscall interception, sandboxing | agentsh / Canyon Road, Anthropic sandbox-runtime |
| Governance Frameworks | Application-level policy engine, identity, compliance | Microsoft AGT, GitHub Agentic Workflows |
| Audit & Provenance | The provenance record is the product | Agent Receipts, nono, Asqav, InALign |
Audit & Provenance Layer
Section titled “Audit & Provenance Layer”The category that crystallized in May 2026: tools whose primary product is the provenance record rather than enforcement. The differentiating axis is where the signing key lives (inside vs. outside the audited process) and how portable the record is.
| Primary product | Signing locus | Envelope | Notes | |
|---|---|---|---|---|
| Agent Receipts | Provenance record | Out-of-agent daemon | W3C VC (Ed25519, RFC 8785) | Keys + chain outside the audited process; one chain across all channels |
| nono | Provenance record | Out-of-process (append-only Merkle log) | Sigstore/Rekor anchored | Closest on the boundary axis; binary-identity binding |
| Asqav | Provenance record | In-agent / SDK | Signed records (ML-DSA-65, RFC 3161 timestamps) | Audit-first; post-quantum signing, EU AI Act audit packs |
| InALign | Alignment + audit | In-process | SHA-256 hash chain | MCP-native; MITRE-mapped detection, EU AI Act checks |
Several of these entrants are weeks old; rows carry verified specifics where available, not fabricated detail. The axis that matters is in-agent vs. out-of-agent signing and record portability — and on the first question, nono lands on the same side as Agent Receipts, so the differentiation runs through the portable W3C VC envelope and the single cross-channel chain. See the audit boundary belongs outside the agent for why the boundary is the durable property.
Detailed Comparison: Open-Source Agent Security Tools
Section titled “Detailed Comparison: Open-Source Agent Security Tools”These are the tools most relevant to an individual builder or small team entering the space.
| Microsoft AGT | Pipelock | mcp-firewall (ressl) | agentsh (Canyon Road) | Agent Wall | mcp-firewall (dzervas) | |
|---|---|---|---|---|---|---|
| Released | v3.0 Public Preview (Apr 2026) | Jan 2026 | Feb 2026 | 2025–2026 | Feb 2026 | 2026 |
| Language | Python (primary), TS, .NET, Rust, Go SDKs | Go | Python | Go + system-level | Node.js | Rust |
| License | MIT | Apache 2.0 | AGPL-3.0 (commercial available) | Source-available (commercial) | MIT | MIT |
| Approach | Application middleware + Agent Framework integration | Egress proxy + MCP proxy | MCP stdio proxy + SDK library | Kernel enforcement (Landlock, FUSE, ptrace, seccomp) | MCP stdio proxy | Claude Code pre-tool-use hook |
| MCP proxy | No (framework adapters) | Yes (stdio) | Yes (stdio) | No (syscall-level) | Yes (stdio) | No (hook-based) |
| HTTP/egress proxy | No | Yes (7-layer scanner) | No | Yes (network proxy) | No | No |
| Shell/command control | No | No | No | Yes (shell shim, ptrace) | No | No |
| File I/O control | No | Integrity monitoring | No | Yes (FUSE, Landlock) | No | No |
| Policy engine | YAML + OPA/Rego + Cedar | YAML config | YAML + OPA/Rego | YAML policy | YAML config | Jsonnet |
| DLP / secret scanning | No | Yes (regex, entropy, env leak) | Yes (response scanning) | Yes (output redaction) | Yes | No |
| Prompt injection detection | MCP scanner module | Yes (response scanning) | Yes (8 inbound checks) | No | Yes | No |
| Cryptographic identity | Ed25519 DIDs + ML-DSA-65 | Ed25519 signing | Ed25519 audit chain | No | No | No |
| Audit logging | Structured + OTEL | JSON + Prometheus; EvidenceReceipt v2 | JSON + signed hash chain | Structured + OTEL | JSON | No |
| Compliance reporting | EU AI Act, NIST, HIPAA, SOC 2, OWASP | OWASP mapping | DORA, FINMA, SOC 2 | No | No | No |
| Dashboard | No | Prometheus/stats endpoint | Yes (web UI) | Via Watchtower (commercial) | Yes (web UI) | No |
| Framework integrations | Agent Framework + 12+ (LangChain, CrewAI, AutoGen, etc.) | Claude Code, Cursor | Claude Desktop, Cursor, any MCP client | Vercel, E2B, Daytona, Cloudflare, etc. | Any MCP client | Claude Code, Copilot CLI |
| Trust model | Same-process middleware | Capability separation (proxy has no secrets) | Same-process proxy | Kernel-enforced isolation | Same-process proxy | Hook-based |
Detailed Comparison: Commercial MCP Gateways
Section titled “Detailed Comparison: Commercial MCP Gateways”| MintMCP | Peta (Agent Vault) | TrueFoundry | Lasso Security | Gravitee | Traefik Hub | |
|---|---|---|---|---|---|---|
| Type | Managed SaaS | Credential vault + gateway | AI platform + gateway | Security platform + OSS gateway | API gateway + MCP | Reverse proxy + MCP middleware |
| OSS component | LLM Proxy (partial) | No | No | Yes (mcp-gateway, Apache 2.0) | No | No |
| Key differentiator | One-click deploy, pre-built connectors | Zero-trust vault, agents never see raw keys | Low latency (3–4ms), 350+ rps | Plugin-based guardrails, PII detection (Presidio) | Protocol-aware, method-level governance | Extends existing Traefik deployments |
| Auth model | OAuth 2.0 | Scoped time-limited tokens | OAuth 2.0 OBO | API key + plugins | Standard API gateway auth | Standard Traefik auth |
| Human-in-the-loop | No | Yes (approval workflows) | No | No | No | No |
| Compliance | SOC 2 | SOC 2 | Varies | Gartner Cool Vendor 2024 | Enterprise certifications | Enterprise certifications |
| Best for | Fast deployment, non-security-specialist teams | Regulated industries, credential management | High-throughput, perf-sensitive deployments | Security-first orgs wanting OSS flexibility | Orgs already on Gravitee | Orgs already on Traefik |
Platform-Native Solutions
Section titled “Platform-Native Solutions”| GitHub Agentic Workflows | Cloudflare Enterprise MCP | GitHub Copilot Agent Firewall | |
|---|---|---|---|
| Scope | Full defense-in-depth for GH Actions agents | WAF + AI Gateway for MCP servers | Domain allowlist for Copilot cloud agent |
| Architecture | Kernel isolation + MCP gateway + integrity filtering | WAF in front of MCP, portal pattern (N servers → 2 tools) | iptables-based egress filtering |
| Policy model | Declarative YAML (network, integrity levels) | WAF rules + AI Gateway config | Domain allowlist (org or repo level) |
| Limitations | GitHub Actions only | Cloudflare stack only | Only covers agent-started processes, not MCP servers; bypassable |
| Notable | Trust-scored content filtering (merged/approved/unapproved) | Published April 15, 2026 — their own internal deployment | Honest about limitations in their own docs |
Architectural Approaches Compared
Section titled “Architectural Approaches Compared”| Approach | Enforcement guarantee | Bypass risk | Setup complexity | Coverage scope |
|---|---|---|---|---|
| Kernel-level (agentsh) | Strongest — syscall interception | Very low (requires kernel exploit) | High (kernel 6.7+, FUSE, capabilities) | Shell, filesystem, network, processes |
| Egress proxy (Pipelock) | Strong for network — capability separation | Medium (agent could use alternative channels) | Low (single binary) | Network egress, MCP responses |
| MCP stdio proxy (mcp-firewall, Agent Wall) | Moderate — protocol-level interception | Medium (only covers MCP channel) | Low (wrap command) | MCP tool calls and responses only |
| Application middleware (Microsoft AGT) | Weakest — same trust boundary as agent | High (agent can bypass if compromised) | Low (pip install) | Whatever the framework exposes |
| Hook-based (dzervas/mcp-firewall) | Moderate — pre-execution check | Medium (depends on client enforcement) | Very low | Tool calls in supported clients |
Audit & provenance tools are not enforcement tools — they record rather than block. The analogous axis for them is the trust boundary: an in-process signer shares the agent’s blast radius; an out-of-agent signer does not.
Key Primitives Convergence
Section titled “Key Primitives Convergence”Multiple projects have independently converged on the same cryptographic and protocol primitives. By May 2026, signed hash-chained receipts are no longer differentiating — they are table stakes.
| Primitive | Used by |
|---|---|
| Ed25519 signing | Microsoft AGT, Pipelock, mcp-firewall (ressl), Asqav, nono, Agent Receipts |
| SHA-256 hash chaining | mcp-firewall (ressl), Agent Receipts |
| DIDs (Decentralized Identifiers) | Microsoft AGT, Agent Receipts |
| OPA/Rego policies | Microsoft AGT, mcp-firewall (ressl) |
| Cedar policies | Microsoft AGT |
| Signed, hash-chained receipt (any scheme — table stakes) | Agent Receipts, Pipelock (EvidenceReceipt v2), Asqav, nono, InALign, Microsoft AGT |
| W3C Verifiable Credentials (data model envelope) | Agent Receipts only — competitors sign receipts with other schemes (Asqav: ML-DSA-65; nono: Sigstore/Rekor; Pipelock: Ed25519 JSONL), not the VC envelope |
| Sigstore / Rekor transparency log | nono |
| OWASP Agentic AI Top 10 | Microsoft AGT, Pipelock, mcp-firewall (ressl) |
| YAML policy config | All enforcement projects |
| Out-of-agent signing / log | Agent Receipts (daemon owns keys + chain); nono (append-only log the agent can’t reach); others sign in-process |
| Hook-based emission | Claude Code (full tool-surface coverage), Codex CLI (partial — no WebSearch, partial shell); Agent Receipts aligns with both hook surfaces |
Standards Window
Section titled “Standards Window”EU AI Act Article 12 requires automatic, tamper-evident logging of high-risk AI system operation over its lifetime — nearly verbatim, the problem a hash-chained, independently-signed receipt solves. August 2, 2026 is a genuine AI Act milestone, though some Annex III high-risk obligations were reportedly deferred (to late 2027) in a recent political agreement, so the deadline is softer than a single date implies. The direction of travel — tamper-evident logging as a legal expectation — is the durable signal.
| Effort | Venue | What it is | Maturity |
|---|---|---|---|
| EvidenceReceipt v2 | Pipelock | Receipt format (Ed25519, evidence.jsonl); bid to standardize the firewall-emitted record | Shipping |
| W3C VC Data Integrity | W3C | The envelope our receipts use; CG argues canonicalization (JSON-LD vs. RFC 8785) | Recommendation |
| IETF draft-sharif | IETF | draft-sharif-agent-audit-trail, a logging format for agent actions | Individual I-D (not WG-adopted) |
General supply-chain transparency work (IETF SCITT, COSE receipts) is the substrate some of these build on, but it is software-supply-chain-oriented, not agent-audit-specific, so we don’t count it as part of this race.
Agent Receipts’ position: the receipt is a W3C VC; the differentiator is the out-of-agent boundary plus one chain across channels; the format should be portable, and we will align with a credible standard rather than fork one.
Gap Analysis
Section titled “Gap Analysis”Areas that remain underserved despite the crowded landscape:
| Gap | Description | Who’s closest |
|---|---|---|
| Audit independent of the audited process | Signing keys/log held outside the agent so the trail survives a compromised agent | Agent Receipts (daemon process separation) and nono (append-only log the agent can’t reach); most other audit-first tools sign in-process |
| Unified cross-channel audit | Correlating MCP calls + REST calls + shell commands + browser actions into one timeline per agent session | Agent Receipts (one daemon, one chain across channels); Canyon Road Watchtower (commercial/closed) |
| CISO-ready reporting | PDF/HTML reports a security team can review to approve agentic AI adoption | mcp-firewall (ressl) has compliance reports; Microsoft AGT has framework mappings; neither produces turnkey CISO artifacts |
| HTTP/OpenAPI interception | Policy-enforced proxy for agent REST API calls (not just MCP) | Pipelock (egress proxy); agentsh (network proxy) — but neither is OpenAPI-schema-aware |
| Browser automation governance | Intercepting Puppeteer/Playwright/CDP actions with policy enforcement | Nobody (GitHub Copilot firewall explicitly doesn’t cover this) |
| Policy portability standard | A way to express agent policies that works across tools | Microsoft AGT supports 3 languages but no cross-tool standard exists |
| Agent identity federation | Verifying agent identity across organizational boundaries | Microsoft AGT (SPIFFE/SVID) is closest; still early |
This document is kept current. For the point-in-time strategic read, see the May 2026 snapshot.