Documentation

gate is a PII-filtering CLI that transparently intercepts AI agent database query commands and redacts sensitive data before it reaches the model context. It requires no changes to your queries or application code.

Install

The recommended install is via Homebrew (macOS and Linux):

brew tap GaaraZhu/gate && brew install gate

Or install a prebuilt binary with cargo-binstall:

cargo binstall gate

Binaries are also on the GitHub releases page. Verify the install:

gate --version

Install the hook

gate init registers the gate hook in your AI harness settings. It only installs the hook — it does not create a gate config file. Run it once; it is idempotent.

# Claude Code (default)
gate init

# Other supported harnesses
gate init --harness opencode
gate init --harness cursor
gate init --harness copilot-cli
gate init --harness codex
gate init --harness gemini

By default the hook is installed globally (user scope). Use --scope project to install it into the current project only.

gate init --scope project

After installing the hook, run gate config to create and edit your gate config file (patterns, tools to intercept, forced columns).

To remove the hook, config, and any gate-generated plugin files:

gate uninstall

MCP proxy

gate can intercept MCP server traffic and redact tools/call responses before they reach the harness. There are three ways to set this up:

Wrap all existing MCP servers at once

If your harness config already has MCP servers configured, gate can rewrite them all in one step. This is a dry-run by default:

# Preview what would change
gate init --wrap-mcp

# Apply the changes
gate init --wrap-mcp --yes

# Wrap specific servers only
gate init --wrap-mcp --servers postgres,bigquery --yes

Register a new MCP server via gate

gate init --mcp postgres --mcp-cmd "uvx mcp-server-postgres postgresql://..."

This writes the server into your harness MCP config routed through gate mcp.

Run the proxy directly

You can also invoke the proxy manually or test it outside the harness:

gate mcp -- uvx mcp-server-postgres postgresql://...

gate acts as a transparent stdio JSON-RPC proxy. All MCP messages pass through unchanged except tool results, which are scanned and redacted.

Scan your schema

Before connecting an AI agent to a database, run gate scan to classify every column by PII tier. It reads columnar schema JSON from stdin — pipe the output of any schema query into it:

# Example with a Databricks query tool
tkdbr query --sql "SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE
  FROM information_schema.columns
  WHERE table_schema = 'mydb'" | gate scan

gate prints a tiered report (high / medium / low PII risk) and optionally lets you mark false positives to add to the allowlist interactively:

... | gate scan --review

Configuration

Run gate config to create and open the gate config file in your editor. To just create a starter config without opening an editor:

gate config --init-only

To see the resolved config path or print the raw contents:

gate config --path
gate config --print

A minimal config:

enabled: true
patterns:
  - name: custom_account_id
    regex: 'ACC-\d{8}'
    label: account_id
pii:
  column_denylist:
    - customer_id
    - account_number
    - tax_file_number

Custom patterns

Add your own regex patterns under the patterns key. Each pattern needs a name, regex, and label. The label appears in redacted output as [REDACTED:label].

Validate your config (compiles all patterns, reports errors) without running the hook:

gate validate

Column redaction policy

Use column_denylist under pii to force certain columns to always be redacted, regardless of value. This is Gate 1 — it runs before the query executes by parsing the SQL. Use it for columns you know always carry PII even when values look clean (e.g. internal IDs that map to customers).

Use column_allowlist to skip name-based redaction for specific columns (value-based checks still apply):

pii:
  column_allowlist:
    - non_sensitive_id
  column_denylist:
    - customer_id

How PII detection works

gate uses two independent layers:

• Gate 1 — parses the SQL query and marks columns by name. Best-effort; handles SELECT, JOIN, and subqueries. Column matches trigger redaction before results are returned.
• Gate 2 — scans every value in the result set with a library of regex patterns. Runs regardless of Gate 1. Covers emails, phone numbers, credit card numbers, and all AU/NZ regulated identifiers.

Gate 2 false negatives are treated as worse than false positives — when in doubt, gate redacts.

AU/NZ identifiers

gate ships built-in, checksum-validated patterns for:

• NZ IRD number — weighted checksum validation
• NZ NHI number — check-character validation (both old and new format)
• AU TFN — weighted checksum validation
• AU ABN — weighted checksum validation
• AU Medicare number — Luhn-adjacent checksum

Checksum validation eliminates the false positives that plague pure-regex approaches for numeric identifiers.

See the AU/NZ Compliance Pack for signed attestation and deployment runbooks.

FAQ

Does gate store or transmit my data?

No. All processing is in-memory. gate never writes query results to disk and never transmits data externally. The source is MIT-licensed and auditable.

What if gate redacts something it shouldn't?

Run gate scan --review to interactively mark false-positive columns and add them to the allowlist. You can also run gate disable to pause redaction temporarily.

Does gate slow down queries?

The passthrough path (commands gate doesn't intercept) adds single-digit milliseconds. Redaction on intercepted commands adds proportionally to result size — typically <50ms for standard query results.

How do I see what gate has protected?

Run gate retro for a protection retrospective — total queries intercepted, PII fields redacted, and a breakdown by tool.