How zn-gate is different
Plenty of good tools work on prompt injection and agent security. We do not publish tables of other vendors' numbers that we cannot reproduce. Here is what zn-gate does differently, and when something else fits better.
Local
zn-gate runs on your machine, between your coding agent and its tools. Nothing is sent anywhere by default; the cloud is an opt-in second opinion.
Across agents
One layer for Claude Code, Codex, Cursor, OpenCode and Python agents, through MCP and a small SDK, with the same rules everywhere.
Open
MIT code, Apache-2.0 model weights and public benchmark scripts. You can read, run and change all of it.
Kinds of tools, and when each fits
Hosted detection APIs
You send text to a vendor service and get a verdict back. A good fit when your traffic already goes through a server you control and you want a managed service.
Cloud platform guardrails
Guardrails built into a model provider or a cloud. A good fit when everything runs inside that one platform.
Open-source scanner libraries
Libraries you embed in your own pipeline. A good fit when you build a custom LLM application and want full control of the code path.
zn-gate
A local layer for coding agents: it redacts secrets from tool output, checks what the agent reads for prompt injection and audits MCP servers before you trust them.
When zn-gate is not the right fit
- You need content moderation (toxicity, hate speech, topics). Galvanize only classifies prompt injection.
- You need a contractual uptime SLA for a hosted API today.
- You need to inspect images, audio or files rather than text.
- You want a guarantee. No detector catches every injection; keep least privilege on your agent's tools whatever you use.
Check for yourself
Every number we publish links to its date, dataset and script. Run them against the tools you are comparing.