Security Policy
Our commitment to transparency, vulnerability coordination, researcher recognition, and an honest compliance posture.
RFC 9116 security.txt: /.well-known/security.txt
Security Hall of Fame
Researcher AcknowledgmentsWe extend our sincere gratitude to the independent security researchers who have responsibly disclosed vulnerabilities to help keep zn and the AI ecosystem secure.
Control-plane authorization gap on policy and consensus handlers
Discovered that control-plane endpoints (/api/v1/policies* and /api/v1/consensus*) validated tenant API authentication but omitted function-level authorization checks, allowing non-admin tenant keys to alter policies or consensus state. Remediation enforced strict SuperAdmin role checks and consensus witness verification.
Insufficient session and token revocation on password reset (CWE-613)
Identified that changing or resetting a user account password did not invalidate existing active authorization grants, refresh tokens, or concurrent browser sessions. Remediation implemented immediate server-side Auth0 grant and refresh token revocation on password reset events, client-side session termination across existing devices, and reduced access token lifetimes.
Incomplete session revocation on password change (CWE-613 follow-up)
Independently identified that changing the account password did not immediately invalidate other active browser sessions: previously issued access tokens remained valid until expiry, even though refresh token grants were revoked. Remediation added a per-user revocation epoch that the API checks on every request, so tokens issued before a credential change are rejected instantly; reduced the access token lifetime from 24 hours to 15 minutes; extended the same revocation to the password reset flow; and added a "Sign out of all devices" control plus automatic sign-out when a session is rejected.
Session termination flow hardening (logout redirects & error handling)
Identified that the global sign-out flow relied on a post-logout destination that was not registered in the identity provider's allowed logout URLs, producing an unbranded error page that also exposed internal configuration. Remediation replaced raw identity-provider errors with a branded error page, added a graceful "session expired" notice for cross-device sign-outs, registered the legitimate logout destinations as defense-in-depth, and completed the migration to a first-party authentication domain.
Entries use the format SEC-YYYY-NN and are permanent — we never remove a credited researcher. If you prefer to stay anonymous, we can list the report without your handle.
Security advisories
Our own findingsIssues in software we ship, published with the same detail we ask of researchers: what happened, who is affected and what to do.
zn-gate for Python 1.2.3 to 1.13.0: the LangChain callback handler did not stop blocked tool calls or hide secrets in tool output
Affected: zn-gate for Python (zn-gate on PyPI) 1.2.3 to 1.13.0, when you use ZnGuardCallbackHandler with LangChain or LangGraph. Not affected: the zn-gate plugin and agent hooks for Claude Code, Codex CLI, Cursor and OpenCode, the npm package, the @guard decorator, guarded_tool and check_tool_call. Fixed in zn-gate 1.13.1. LangChain catches errors raised inside callback handlers unless the handler asks it not to, so in affected versions a tool call the handler blocked still ran, and a blocked prompt or tool output still reached the model. LangChain also ignores what a callback returns, so with mask_secrets=True a secret in a tool output was not hidden. Update with pip install -U zn-gate. Until you update, wrap your tools with guarded_tool, or subclass the handler and set raise_error = True. Found by the zn team during an internal review.
pip: zn-gate· Affected: >= 1.2.3, <= 1.13.0 · Fixed in: 1.13.1
zn-gate for Node.js 1.2.3 to 1.12.0: shield, check_tool_result and optional cloud analysis did not redact some provider token formats
Affected: zn-gate for Node.js (npm package zn-gate) 1.2.3 to 1.12.0. Not affected: the zn-gate plugin and agent hooks for Claude Code, Codex CLI, Cursor and OpenCode, zn-gate scan and zn-gate audit, and the Python package (zn-gate on PyPI) with the GitHub Action. Fixed in zn-gate 1.13.0. zn-gate replaces secret values with placeholders before text leaves the local process. In affected versions, the Node.js shield proxy, the MCP tools check_tool_result and check_tool_call, the optional cloud analysis and the local evidence log did not redact some provider-specific token formats when they appeared on their own, outside a KEY=value assignment: Stripe, Slack, Google, Hugging Face, npm, GitLab and PyPI tokens, and AWS access key IDs other than AKIA. Those values could reach the model provider and, if you turned the optional cloud check on, the zn API. Update with npm install -g zn-gate@1.13.0. If you used an affected version and tool output or prompts may have contained one of these formats, rotate those credentials. Until you update, set up the hooks with npx -y zn-gate init where your agent supports them, and leave the cloud check off. Found by the zn team during an internal review.
npm: zn-gate· Affected: >= 1.2.3, <= 1.12.0 · Fixed in: 1.13.0
zn-gate agent hooks for Node.js 1.5.0 to 1.11.0: a protected file reached indirectly, or a command too long or slow to check, could be read or run without being checked
Affected: zn-gate for Node.js (npm package zn-gate) 1.5.0 to 1.11.0. Not affected: the Python package (zn-gate on PyPI), which has no agent hooks. Fixed in zn-gate 1.12.0. zn-gate installs hooks in coding agents that refuse shell commands which would read a protected file, such as a .env file with plain-text values or a credential file, so its contents do not reach the model. In affected versions, a protected file could be read or run without being checked in two cases: when a command reached it indirectly, and when a command was too long or too slow for the hook to check. An agent that ran such a command, for example after reading a prompt injection, could print a protected file into its context. Update with npx -y zn-gate@1.12.0 init. If you use the Claude Code plugin, update it from the plugin directory once 1.12.0 is listed there. Until you update, for .env files, run zn env shadow .env in every folder that has a .env file with values: shadowed files hold only __ZN_<NAME>__ markers, so reading them reveals no value. Older versions have no workaround for long or slow commands. zn-gate check shows which agents have the hooks installed. Found by the zn team during an internal review.
npm: zn-gate· Affected: >= 1.5.0, <= 1.11.0 · Fixed in: 1.12.0
zn-gate for Node.js 1.5.0 to 1.8.0: a crafted Codex CLI patch could write to protected files without being checked
Codex CLI edits files with patches (apply_patch). Before a patch is applied, the zn-gate hook reads the file names it touches and blocks writes to files zn-gate protects, such as the zn vault directory and the agents' hook settings. Two kinds of problem could let a patch through unchecked. A patch of about 100 KB made of many blank lines made the hook take longer than the 30 seconds Codex CLI gives it, and Codex CLI then applies the patch without the hook's decision. And the hook did not read file names exactly as Codex CLI does (which whitespace is trimmed from a marker line, the spaces after the marker, and which characters end a line), so a protected file could be written while the hook checked a different, harmless name. An agent could be led to write such a patch, for example through a prompt injection in content it read; Codex CLI asks for approval of patches unless it runs with automatic approval. Affected: zn-gate for Node.js from 1.5.0-beta.1 to 1.8.0. Not affected: OpenCode, Claude Code, Cursor, and the Python package, which has no agent hooks. Fixed in zn-gate 1.8.1: the hook reads patch lines in linear time, blocks patches over 100 KB, splits patches into lines and checks file names the way Codex CLI and OpenCode do, and blocks patches with file names or marker lines it cannot read safely. Update with npm install -g zn-gate@1.8.1. Until you can, keep Codex CLI asking for your approval before it applies patches, and decline very large patches or patches whose file lines look unusual.
npm: zn-gate· Affected: >= 1.5.0-beta.1, <= 1.8.0 · Fixed in: 1.8.1
zn-gate for Node.js 1.5.0 to 1.8.0: a crafted .env, .npmrc or .znrules file could make the secret scrubber time out and let tool output through unscrubbed
Before tool output, MCP responses and prompts reach the model, the zn-gate agent hooks replace known secret values with placeholders. To know those values, the hooks read the project's .env files, .npmrc (in the project and in the home directory) and .znrules. On some crafted lines of those files, reading took time that grew with the square of the line length: a line of about 40,000 characters made a hook take longer than 15 seconds. Agents give a hook a fixed time to answer (15 seconds in Claude Code, 30 seconds in Codex CLI and Cursor) and then go on without its result: in Claude Code and Codex CLI, tool output then reached the model without its secret values replaced, and in Cursor so did MCP output. Anyone who could put such a file in a repository, or lead an agent to write one, could therefore turn off the scrubbing for that project; prompts in Claude Code could also be blocked. Affected: zn-gate for Node.js from 1.5.0-beta.1 to 1.8.0. Not affected: OpenCode, Cursor file reads and prompts, and the Python package, which has no agent hooks. Fixed in zn-gate 1.8.1: these lines are read in linear time, with the same values as before. Update with npm install -g zn-gate@1.8.1 (or update the agent plugin once its release that pins 1.8.1 is out). Until you can, check new repositories for .env, .npmrc or .znrules files with very long lines before running an agent in them.
npm: zn-gate· Affected: >= 1.5.0-beta.1, <= 1.8.0 · Fixed in: 1.8.1
zn-gate for Node.js 1.5.0 to 1.7.0: a crafted shell command could make the agent hooks time out and let a protected file read run unchecked
The agent hooks check every word of a shell command for paths that hold secrets, such as .env files, cloud and SSH credentials and the zn vault. Some crafted words, with very many *, [, { or , characters, made that check take seconds to minutes. When a hook does not answer in time, Claude Code and Codex CLI run the tool call without the hook's decision, and so does Cursor for shell commands. A shell command that combined such a word with a read of a protected file could therefore run unchecked, if the agent was led to write it, for example through a prompt injection in content it read. Affected: zn-gate for Node.js from 1.5.0-beta.1 to 1.7.0. Not affected: Cursor file reads and prompts, OpenCode, and the Python package, which has no agent hooks. Fixed in zn-gate 1.7.1: the hooks match globs without backtracking, refuse as too broad the words too complex to check, and resolve paths in linear time. Update with npm install -g zn-gate@1.7.1 (or update the agent plugin once its release that pins 1.7.1 is out). Until you can, keep your agent asking for your approval before it runs shell commands, and decline unusually long commands full of *, [, { or , characters.
npm: zn-gate· Affected: >= 1.5.0-beta.1, < 1.7.1 · Fixed in: 1.7.1
zn-gate scan for Node.js 1.4.0 to 1.7.0 could print secret values in its output and CI logs
zn-gate scan reports each finding with the file, the line number and a short excerpt of the line. In the Node.js package, from 1.4.0 to 1.7.0, that excerpt could show a secret: in 1.4.0 and 1.4.1 it was printed in full, and from 1.5.0 it was redacted with zn-gate's secret patterns, which do not cover every token format, so some values could still be printed. The scan command also ignored --format: with --format github or --format json it printed the text report, excerpts included, so in CI the excerpts ended up in the job log. Affected: zn-gate for Node.js from 1.4.0 to 1.7.0. Not affected: the Python package and the zn-gate GitHub Action, which runs the Python package. Fixed in zn-gate 1.7.1: no matched value is printed any more, scan honors --format text, json and github, and GitHub annotations show only the rule, the reason, the file and the line. Update with npm install -g zn-gate@1.7.1. Until you can, run the scan with the Python package or the zn-gate GitHub Action. If a secret may have appeared in a CI log from an affected version, rotate it and, where your CI allows it, delete the logs of those runs.
npm: zn-gate· Affected: >= 1.4.0, < 1.7.1 · Fixed in: 1.7.1
zn-gate for Node.js before 1.6.0: an agent could run zn admin commands through a versioned package call, skipping the hook that denies them
The agent hooks deny AI agents the commands that manage your secrets and your protection, such as zn unlock, zn lock, zn secret set, zn env shadow and zn hooks uninstall. From 1.5.0-beta.1 up to 1.6.0-beta.1 the hook did not recognise these commands when they were written as a versioned package call, for example npx -y zn-gate@1.5.1 hooks uninstall, so it let them through. Most of these commands also refuse to run when the environment shows a coding agent or when there is no interactive terminal; zn lock has no such check, so any agent could lock the vault (this does not reveal secrets). Not affected: the Python package, the scrubbing of secrets in tool input and output, and reading secret values. Fixed in zn-gate 1.6.0, which denies the versioned forms with npx, pnpm dlx and bunx like the plain command. Update with npm install -g zn-gate@1.6.0 (or update the agent plugin); until you can, keep your agent's commands out of an interactive terminal, review any prompt from zn you did not expect, and if the agent hooks were removed, install them again with zn hooks install from your own terminal.
npm: zn-gate· Affected: < 1.6.0 · Fixed in: 1.6.0
zn-gate 1.5.0 and earlier for Node.js on Windows: zn run could hand secrets to a program chosen through the environment
On Windows, when zn run passed stored secrets to an approved batch file (.cmd or .bat, such as a CLI installed with npm), it started the file through the command interpreter named by the ComSpec environment variable. A process able to set that variable, such as an AI agent in a session where you had approved the batch file, could point it at another program, which then received the secret values. Not affected by this issue: macOS and Linux, Windows programs that are .exe files, the Python package, and the hooks' scrubbing of tool input and output. Fixed in zn-gate 1.5.1, which always starts batch files through the system cmd.exe; on every platform it also stops passing interpreter start-up settings such as NODE_OPTIONS from the caller's environment to a program that receives secrets. Update with npm install -g zn-gate@1.5.1 (or the version your agent plugin pins); until you can, do not approve .cmd or .bat programs for secrets in zn run, and for HTTP APIs use the secrets_http_request MCP tool.
npm: zn-gate· Affected: <= 1.5.0 · Fixed in: 1.5.1
zn-gate 1.4.0 and earlier sent tool output and tool-call arguments to api.usezn.com without redaction when ZN_API_KEY was set
Found during an internal review of the published package. Without ZN_API_KEY nothing left the machine. Fixed in zn-gate 1.4.1: tool output and tool-call arguments are evaluated locally only, cloud analysis is opt-in (ZN_CLOUD=1), prompt-only and redacted before sending. The API no longer stores input text, and the text it had stored was deleted from the service. If you ran 1.4.0 or earlier with an API key set, upgrade and rotate any credential that could have appeared in tool output.
npm: zn-gate· Affected: <= 1.4.0 · Fixed in: 1.4.1pip: zn-gate· Affected: <= 1.4.0 · Fixed in: 1.4.1
Security changelog
Every security improvement we ship, logged publicly. Fixes, not exploits.
Responsible Disclosure Policy
If you believe you have discovered a security vulnerability in zn-gate, the zn Cloud API, or any usezn.com infrastructure, please report it directly to our security team. We take all responsible disclosures seriously and investigate them promptly. This policy follows RFC 9116 and coordinates disclosure with the reporter.
Please include detailed steps to reproduce the issue, proof-of-concept scripts or requests, and any relevant environment details. Testing against local Docker containers or isolated test accounts is strongly encouraged.
Disclosure process
- Report — email security@usezn.com with reproduction steps, impact, and a proof of concept. Never access data that is not yours and never disrupt production systems.
- Acknowledge — we target an initial human response within 24 hours.
- Triage — we target a validity and severity assessment within 48 hours and will tell you if the report is valid, a duplicate, or out of scope.
- Remediate — we fix prioritized by severity and keep you informed of progress.
- Coordinate disclosure — default embargo is 90 days from the report, or the timeline we agree with you. We support advisory drafts and CVE assignment, and credit you publicly according to your preference.
These timelines are best-effort targets from a small team, not a contractual SLA. If we go quiet, we are still working on it — and you are always welcome to nudge us.
Safe Harbor Commitment
We consider security research conducted in accordance with this policy to be authorized. If you make a good-faith effort to comply with responsible disclosure (avoiding user data access, service disruption, and privacy violations), we will:
- Not initiate or pursue legal action against you
- Work with you transparently to validate and remediate the issue
- Coordinate the public advisory and attribution according to your preferences
- Not treat your research as a violation of our Terms of Service or Acceptable Use policy
Scope
In Scope
- zn-gate (open source): MCP server, CLI, secret redaction and local audit log
- Cloud API endpoints (
api.usezn.com) - Client SDKs (
zn-gateNPM/PyPI) - Authentication and access control mechanisms
- Model jailbreak bypasses against
/v30/analyze - usezn.com web application and customer dashboard
- Evidence vault integrity, export, and retention controls
- Auth0 and Polar billing integration flows
Out of Scope
- Denial of Service (DoS/DDoS) attacks
- Social engineering or phishing targeting zn personnel
- Third-party services hosting our assets (for example AWS, Cloudflare)
- Automated scanner spam without actionable proof-of-concept
- Missing hardening headers or best practices without a demonstrable security impact
- Findings that require physical access or a compromised end-user device
- Unverified reports (no reproduced steps and no observed result)
Supported versions
Security fixes are released for the latest minor version of zn-gate on npm and PyPI, today 1.13.x.
Older versions do not receive fixes; upgrade with npm install -g zn-gate@latest or pip install -U zn-gate.
Recognition & Rewards
We value the effort required to identify security flaws. For qualifying vulnerabilities, we offer:
- Public Attribution: Permanent listing in our Security Hall of Fame and release notes.
- Platform Subscriptions: Qualifying researchers may receive a 6-month Scale-tier grant (2,000,000 calls per month) for personal or research use.
- Direct Advisory Collaboration: Full coordination on disclosure timing, advisory drafts, and CVE assignment.
We do not currently run a paid bug-bounty pool. We will not promise money we cannot pay: we are a small team, and rewards are discretionary and focused on attribution, platform access, and collaboration. If a monetary bounty becomes available, it will be published here first.
Data Handling & Retention
Zero Data Retention: Every plan (Free, Pro, Scale and Team) evaluates input outside Contributor Mode in volatile memory and discard it after the verdict; only the decision metadata below is kept. Paid plans never train models on customer data.
Contributor Mode (opt-in): Contributor Mode, offered with some startup and research grants, is the only option that shares data for research, and you choose it. In that mode a scrubbed excerpt of each analyzed input (the first 1,000 characters, with emails, bearer tokens, API keys and long hex strings redacted automatically) is stored with its evidence record for up to 90 days and used to improve zn detection models. Automatic redaction does not catch every piece of personal data in free text.
Evidence records: Each decision produces an evidence record with a random evidence ID and metadata (verdict, confidence, rule, latency, timestamp, and from October 12, 2026, 12:24 UTC a SHA-256 hash and the size of the input, the API key prefix, and the client family). Outside Contributor Mode it never contains the input itself. Evidence expires automatically after 90 days, is encrypted at rest (AES-256, AWS-managed encryption), and can be exported as CSV or JSON from the dashboard. API keys are stored hashed and encrypted with AWS KMS.
Read the full detail in our Privacy Policy.
Certifications & Compliance
We would rather be precise than impressive. This is our actual status today:
- SOC 2 / ISO: zn does not hold SOC 2 or ISO 27001/42001 certifications today.
- Infrastructure: we run on AWS, whose data centers hold SOC 2 Type II and ISO 27001 certifications.
- Roadmap: a SOC 2 Type II engagement activates with our first enterprise contract; ISO 27001 and ISO 42001 readiness work is on the roadmap.
- Audit exports: per-decision evidence records can be exported (CSV or JSON) to support customer record-keeping. The local zn-gate package additionally keeps a hash-chained ledger on your own machine.
- No uptime SLA: we monitor internally with AWS CloudWatch alarms, but we do not publish a real-time uptime monitor or promise a public uptime SLA. See the Status page.
Model provenance
- Galvanize 3 is the model behind the optional cloud check. Its weights are not published.
- Galvanize 2, the previous model, was the cloud check model before Galvanize 3. It is fine-tuned from Horizon-Labs/prompt-injection-guard-small (Apache-2.0) and released under Apache-2.0. Overview: Galvanize 2; model card and weights: usezn/Galvanize-2. Benchmark scripts and results: usezn/Galvanize-2/benchmark.
- Galvanize-60M, the previous model, is the automatic fallback when Galvanize 3 is unavailable. Model card and weights: usezn/Galvanize-60M (Apache-2.0).
Subprocessors & DPA
We rely on a small set of vetted subprocessors: AWS (hosting and storage), Auth0 (authentication), Polar (payments and Merchant of Record), and Amazon SES (transactional email).
The full list, purposes, and transfer safeguards live on our DPA & Subprocessors page. Customers can execute a Data Processing Agreement on request: contact us at hello@usezn.com.