Content Scanner (DLP)

Automatic detection and blocking of secrets in tool call arguments.

The DLP (Data Loss Prevention) scanner runs on every tool call before the policy engine even starts. If an argument contains a known secret pattern, Node9 hard-blocks the call immediately — no approval prompt, no race engine — and injects a negotiation message explaining why.

Always on by default

DLP is enabled out of the box with zero configuration. It also scans tools in your ignoredTools list (e.g. web_search, read_file) because credentials can appear in any tool's arguments.

Built-in Patterns

Node9 ships with 40+ credential patterns out of the box. The cards below are the most common; the full set covers cloud providers (GCP, Azure, DigitalOcean), CI/CD tokens (GitLab, npm, Doppler, Pulumi), SaaS APIs (Shopify, Linear, Notion, SendGrid, Resend, Mapbox, Telegram, Square), secret managers (HashiCorp Vault), JWTs, and PEM private keys. New patterns are added with each Node9 release — see packages/policy-engine/src/dlp/ in the proxy source for the complete list.

AWS Access Key IDblock

Matches the standard IAM key prefix followed by 16 uppercase alphanumeric characters. Hard-blocked — AWS keys in tool args almost always indicate accidental credential leakage.

GitHub Tokenblock

Matches personal access tokens (ghp_), OAuth tokens (gho_), user tokens (ghu_), and server-to-server tokens (ghs_) followed by 36 alphanumeric characters.

Slack Bot Tokenblock

Matches bot tokens starting with xoxb-. Hard-blocked — Slack tokens passed as command arguments are never intentional.

OpenAI API Keyblock

Matches keys starting with sk- followed by 20 or more alphanumeric characters.

Stripe Secret Keyblock

Matches sk_live_ and sk_test_ keys followed by exactly 24 alphanumeric characters. Both live and test keys are hard-blocked.

PEM Private Keyblock

Matches the header line of RSA, EC, and OpenSSH private key files. Hard-blocked — a private key appearing in a tool argument is always a critical incident.

Bearer Tokenreview

Matches Authorization: Bearer ... headers. Routed to the normal race engine for human approval rather than hard-blocked, since Bearer tokens can be intentional in some MCP workflows.

Secret Redaction

Secrets are never logged in full

When a match is found, Node9 redacts the secret before writing to the audit log. Only a prefix + suffix sample is stored — for example, an AWS key becomes AKIA****MPLE. The full secret is never persisted anywhere.

The same redacted sample is shown in the approval UI, the terminal alarm banner, and the negotiation message sent back to the AI.

Recursive Scanning

The scanner recursively walks the entire argument object — nested objects, arrays, and JSON-encoded string fields are all inspected. Performance guards prevent runaway scans: recursion stops at depth 5, strings over 100 KB are truncated, and JSON-in-string parsing is skipped for strings over 10 KB.

Configuration

DLP config knobs

// node9.config.json or ~/.node9/config.json
{
  "policy": {
    "dlp": {
      "enabled": true,
      "scanIgnoredTools": true
    }
  }
}

enabled — master switch, defaults to true.
scanIgnoredTools — also scan tools listed in ignoredTools, defaults to true. Disable only if DLP is causing false positives on tools that legitimately pass token-shaped values.

DLP runs before ignoredTools

Even if a tool is in your ignoredTools list, DLP still scans its arguments when scanIgnoredTools is true (the default). This ensures credentials can't slip through by tagging a tool as ignored.

Response DLP — secrets in Claude's text

Tool-call DLP blocks secrets before they leave your machine. But Claude can also write a secret into its response text — a curl example with a real token, a config snippet with a live key — and that prose bypasses tool-call interception entirely.

Background JSONL scanner

The Node9 daemon runs a response DLP scanner that reads Claude's JSONL conversation history incrementally (delta scan — only new bytes since the last check). When it finds a secret pattern in an assistant response, it fires a desktop notification immediately and logs the finding to the audit trail.

Findings appear in node9 report under a dedicated Response DLP section, and a ⚠️ DLP ALERT banner is shown at the top of the report when open findings exist.

`node9 dlp` — guided remediation

Run node9 dlp after receiving a response-DLP alert. It shows every open finding with the pattern name, a masked sample, the project it came from, and the date — plus a three-step remediation checklist.

node9 dlp resolve

Once you have rotated any exposed credentials, run node9 dlp resolve to acknowledge all current findings. Resolved findings are stored in ~/.node9/dlp-resolved.json and will no longer appear in future reports or alerts — only genuinely new secrets will resurface.

Bearer Token minimum-length guard

The Bearer Token pattern requires at least 20 characters after Bearer . This prevents false positives on prose like "Node9 scans for Bearer tokens in your commands" — only real credential-length values trigger the pattern.

Content Scanner (DLP) · node9 documentation