Security

A security tool should show its work.

Gate0x sits in the path of your agent's actions, so it has to be easy to audit and hard to talk around. This page says how it is built and where it is weak.

Current scope

What Gate0x covers today, and what it does not.

  • Covered: local stdio MCP tools/call, in a macOS-first private trial. Linux is covered by automated tests only and Windows is not supported.
  • Not yet covered: remote (URL) MCP servers, MCP resources and prompts, and an agent's built-in tools.
  • Local approvals are a safeguard against mistakes, not an agent-proof security boundary (see below).
  • Classification is heuristic and can miss dangerous tools. Write explicit rules for the ones that matter.
  • Not complete agent security. Gate0x does not replace host-agent, identity, network or enterprise gateway controls. It adds a decision immediately before an action runs.
  • Real-client validation is narrow. The flow (allow, hold, approve, time out) was tested by hand with one client, Claude Code, and a project-scoped local MCP server. Other clients are not validated.

Design principles

  • Deterministic. The policy engine is a pure function: no network, filesystem, clock, randomness or model. Lint rules enforce this in the codebase.
  • Explainable. Every decision carries a reason code and the rule that made it.
  • Local by default. Scan and Protect run on your machine and upload nothing.
  • Secrets are kept out of logs. Arguments are redacted by key name and credential pattern before they are written, and Scan reports secret names, never values. Redaction is best effort: an unfamiliar secret format can slip through.
  • Record first. The audit record is written before a call is forwarded. If it cannot be written, BLOCK, REQUIRE_APPROVAL and high-risk calls never run, and low-risk calls are blocked too unless you explicitly opt in.
  • Fail safe. An invalid policy or an unwritable log stops the proxy from starting. Unparseable input is dropped. An approval that is not explicitly granted blocks. Infrastructure failure never silently turns a block into an allow.
  • Careful with your configuration. gate0x wrap --apply shows exactly what it will change, asks first, writes a timestamped backup that is never overwritten, edits only that one server's entry (every other byte of the file stays identical), validates the result, replaces the file atomically, and can be undone with gate0x wrap --rollback. It refuses symbolic links and anything it cannot edit safely.
  • No telemetry. Gate0x makes no network connections of its own: no analytics, crash reports, scan uploads or usage reporting.
  • Small. The shipped CLI is one file with no runtime dependencies.

Local approvals are not a security boundary

Local approvals are not a security boundary against an agent that has unrestricted shell access as the same OS user. Approvals are files in a directory owned by you. Any process running as you, including an agent's shell tool, can write an approval, and can edit the pending request a human is shown. They protect you from mistakes: you see a call and decide. They do not protect you from a hostile agent that can run commands.

  • Block or approval-gate shell_exec so the agent cannot reach a shell without a human.
  • gate0x scan flags an unprotected shell-capable server next to a protected one in the same client (GX-APR-001), and notes clients that ship their own terminal tool (GX-APR-002). It cannot see what a client does internally or what a policy allows, so no finding is not a guarantee.
  • An approval channel the agent cannot reach is planned, not built.

Threats and mitigations

Threat What Gate0x does What remains
Prompt injection steering the agent to a dangerous tool Decisions come from policy over structured call data, not from the model A permissive policy still allows what it allows
Agent approves its own request Approvals are single-use and bound to the exact call; Scan flags obvious setups Not a boundary against shell access as your user (see above)
Audit outage causing unrecorded execution Write-ahead audit; risky calls never run without a record; low-risk calls blocked unless you opt in In the opt-in mode, low-risk calls can run unrecorded (the gap is counted)
Hiding a command in padding, nesting, size or Unicode Arguments are inspected at any depth after normalization; anything too large or deep, or a non-ASCII tool name, needs approval Encoded commands (hex, custom) are not decoded
Path traversal in allow rules The within operator resolves .. Symlinks and servers that decode %2e%2e
Tool description changed after you trusted it Tool definitions are fingerprinted; a change requires approval under the starter policies The first definition is trusted on first use
Message tricks (duplicate keys, odd method names) The proxy forwards the exact re-serialized message it evaluated; near-miss method names are never forwarded Other protocol methods (resources, prompts) are not inspected
Tampering with the audit log Hash-chained entries; gate0x audit --verify detects edits, reordering and middle deletion Tamper-evident, not tamper-proof: removing the newest entries is not detected
Secrets leaking into logs or output Redaction before write; Scan masks secrets in arguments and URLs; tests assert it Unknown secret formats can slip through
Dangerous tool with a harmless name Heuristics read the name, description, argument names and SQL or shell text Heuristic; write explicit rules for critical tools
Agent uses a server that is not wrapped gate0x scan shows unprotected servers Gate0x cannot stop a client that bypasses it
Compromised package launching your MCP server Scan flags unpinned packages Gate0x does not verify package contents

What we don't claim

  • Gate0x is early access software and has not had an independent security audit.
  • It is not a sandbox. It decides whether a call is forwarded; it does not contain what an allowed tool does.
  • It does not make a bad policy safe, and its classification is a heuristic.
  • Local approvals are not a security boundary against an agent with shell access as you.

Report a vulnerability

Email security@gate0x.com with steps to reproduce. Please don't open a public issue or share details before we've had a chance to fix it. We'll acknowledge reports and keep you updated.