Credential Sanitization

Overview

Every byte of text that NetStacks sends to an external LLM — chat messages, selected terminal output, system prompts, and agent tool results — passes through a sanitization layer first. The layer scrubs credentials and secrets so that passwords, SNMP communities, API keys, routing secrets, VPN keys, and private keys never leave your machine in plaintext.

This is not advisory. Safety Rule 4, hardcoded into every AI interaction, states:

The sanitizer applies three tiers of patterns, in this exact order:

1. Mandatory patterns — 19 built-in credential patterns that are always active and cannot be disabled.
2. Optional network redaction — five toggles for IPv4, IPv6, MAC, hostnames, and usernames (off by default).
3. Custom patterns — your own named regular expressions with your own replacement tokens.

An allowlist sits across all three: any match containing an allowlisted substring (case-insensitive) is left untouched.

How Sanitization Works

The SanitizingProvider is a transparent decorator. When the app or an agent needs an LLM, it builds the real provider (Anthropic, OpenAI, OpenRouter, or a custom OpenAI-compatible endpoint) and immediately wraps it. Every entry point — interactive chat, the streaming agent loop, and delegated sub-agents — goes through the same wrapper.

For each request the decorator sanitizes, before forwarding to the real provider:

• every chat message's content;
• the agent system prompt (it can carry device IPs and pasted terminal output);
• agent message blocks — both plain Text blocks and ToolResult blocks (the raw command output a tool produced);
• context fields: selected text, recent terminal output, and session-context entries (issue, root cause, resolution, commands).

Two categories are deliberately passed through unmodified:

• Tool schema definitions — these are static JSON descriptions of available tools, not user data.
• ToolUse blocks — the model's own generated tool calls (id, name, input). These originate from the AI, not from your devices, so they are not re-sanitized.

Inside sanitize(), patterns are applied sequentially — mandatory, then optional, then custom — each one rewriting the running text. Most patterns use a capture group so the label stays and only the secret is replaced, e.g. enable secret 5 <hash> becomes enable secret 5 [REDACTED]. The result also reports a redaction_count and the list of pattern_names that fired, which the test panel surfaces.

Mandatory Patterns (Always On)

Nineteen credential patterns ship built in and are always active. They cannot be toggled off — even with an empty configuration, every one of these runs. They are vendor-aware and cover the credential forms you find in real network configs:

In the UI these are listed read-only under the collapsible Mandatory Patterns (19 always active) header. There is no switch to disable them. Given a snippet of a Cisco config:

! before — what you paste / what a tool returns
enable secret 5 $1$mERr$aBcDeFgHiJkLmNoPqR.
snmp-server community public RO
username netadmin password 0 S3cr3tP@ss

! after — what the LLM actually receives
enable secret 5 [REDACTED]
snmp-server community [REDACTED]
username netadmin password 0 [REDACTED]

Optional Network Redaction

Five additional patterns redact network identifiers. These are off by default — identifiers like IPs and hostnames are often exactly what you want the AI to reason about. Enable them under Optional Redaction when you need stricter privacy (for example, when sharing output with a third-party model under a strict data-handling policy).

Custom Regex Patterns

Add your own patterns for site-specific secrets the built-ins don't know about — an internal token format, a corporate asset tag, an employee ID, or anything else you never want sent to an LLM. Each custom pattern has three fields:

name

A label for the pattern (shown in the UI and in test results).

regex

A Rust regex-crate pattern. The field also accepts the alias pattern for compatibility with the Controller.

replacement

The token to substitute. You can reference capture groups with ${1}, ${2}, etc. — the same syntax the built-in patterns use to preserve their labels.

Custom patterns run after the mandatory and optional patterns. Add them in the UI under Custom Patterns, or write them straight into the config JSON:

{
  "custom_patterns": [
    {
      "name": "Internal API Token",
      "regex": "INT-[A-Z0-9]{32}",
      "replacement": "[INT-TOKEN-REDACTED]"
    },
    {
      "name": "Employee ID",
      "regex": "(?i)(emp[-_]?id\\s*[=:]\\s*)\\S+",
      "replacement": "${1}[EMP-ID-REDACTED]"
    }
  ]
}

Allowlist

The allowlist names strings that should never be redacted, even if a pattern matches them. Matching is a case-insensitive substring check: if a would-be redaction contains any allowlisted entry (in any case), it is left in the output verbatim.

This is the escape hatch for the aggressive optional patterns. For example, with hostname redaction on, allowlist lab.example.com to keep your lab gear visible to the model while still redacting production FQDNs. Or allowlist a well-known placeholder like public so the literal SNMP community string public passes through.

{
  "redact_hostnames": true,
  "redact_ip_addresses": true,
  "allowlist": [
    "lab.example.com",
    "10.255.0.0",
    "public"
  ]
}

Configuration Reference

The complete configuration is a single JSON object stored under the ai.sanitization_config setting. All fields are optional; anything omitted falls back to its default (which is "off" for the optional toggles, and empty for custom patterns and the allowlist). The 19 mandatory patterns are not represented here because they are always on.

{
  "redact_ip_addresses": false,
  "redact_ipv6_addresses": false,
  "redact_mac_addresses": false,
  "redact_hostnames": false,
  "redact_usernames": false,
  "custom_patterns": [],
  "allowlist": []
}

A fully populated, stricter example:

{
  "redact_ip_addresses": true,
  "redact_ipv6_addresses": true,
  "redact_mac_addresses": true,
  "redact_hostnames": true,
  "redact_usernames": true,
  "custom_patterns": [
    {
      "name": "Corp Asset Tag",
      "regex": "ASSET-[0-9]{6,8}",
      "replacement": "[ASSET-REDACTED]"
    }
  ],
  "allowlist": [
    "lab.example.com",
    "10.255.0.0/16"
  ]
}

In Personal Mode you can also set it over the Local Agent's loopback API. The agent stores it wrapped in a value field as a JSON string; saving it invalidates the in-memory sanitizer cache automatically:

curl -s -X PUT http://127.0.0.1:PORT/api/settings/ai.sanitization_config \
  -H 'Content-Type: application/json' \
  -d '{"value":"{\"redact_ip_addresses\":true,\"allowlist\":[\"lab.example.com\"]}"}'

Testing Sanitization

The settings UI includes a Test Sanitization panel: paste any text, click Test, and it shows the sanitized output, a redaction count, and the list of patterns that fired. The test path always loads a fresh config (bypassing the cache) so you see the effect of unsaved-then-saved changes immediately.

Under the hood the panel calls POST /api/ai/sanitization/test on the Local Agent (or the Controller, in Enterprise mode). You can exercise it directly:

curl -s -X POST http://127.0.0.1:PORT/api/ai/sanitization/test \
  -H 'Content-Type: application/json' \
  -d '{"text":"enable secret 5 $1$mERr$aBcD\nsnmp-server community public RO"}'

{
  "sanitized": "enable secret 5 [REDACTED]\nsnmp-server community [REDACTED] RO",
  "redaction_count": 2,
  "pattern_names": ["cisco_enable_secret", "snmp_community"]
}

An empty text returns zero redactions and no patterns. If a pattern you expected does not appear in pattern_names, the secret wasn't matched (check spacing/format) or a custom regex failed to compile.

Controller SanitizingProvider

Tier: Team / Enterprise. When the Terminal is connected to a Controller, sanitization works identically — the same SanitizingProvider decorator, the same 19 mandatory patterns, the same optional toggles, custom patterns, and allowlist. The single difference is where the configuration lives.

• Personal Mode: config is stored locally under ai.sanitization_config and read/written via /api/settings/ai.sanitization_config.
• Enterprise Mode: config is managed centrally by the Controller and read/written via /admin/sanitization/config, where it is sent as structured JSON (the same field names as the local config). Admins set the policy once; every connected operator inherits it.

The Controller accepts custom patterns using either the regex or the pattern field name — the engine treats pattern as an alias for regex — so a policy authored against the Controller schema applies cleanly on the Terminal. The test endpoint POST /api/ai/sanitization/test behaves the same in both modes.

Q&A

Can I turn off the credential redaction entirely?

No. The 19 mandatory patterns are always active and have no toggle. Only the five network-identifier patterns (IP, IPv6, MAC, hostname, username), custom patterns, and the allowlist are configurable. This enforces Safety Rule 4.

Does sanitization apply to local-only models too?

The SanitizingProvider wraps every provider the app builds, including a custom OpenAI-compatible endpoint. Whatever you point at, the same redaction runs before text leaves the agent.

Why do I still see the keyword, like "enable secret 5"?

By design. Most patterns capture the keyword prefix and replace only the secret with [REDACTED], so the model can reason about the configuration without seeing the value. Full blocks (private keys, certificates) are replaced wholesale with [PRIVATE-KEY-REDACTED] / [CERTIFICATE-REDACTED].

My custom pattern isn't redacting anything. Why?

Either it didn't match the text, or the regex failed to compile (invalid patterns are logged and skipped, never fatal). Paste a sample into the test panel; if the pattern name doesn't appear in the fired list, fix the regex. Remember to double backslashes in raw JSON.

What does the allowlist match against?

The matched text of a would-be redaction, as a case-insensitive substring. If the match contains any allowlisted entry, it is left untouched. Keep entries specific so you don't accidentally exempt more than intended.

Do agents and sub-agents get sanitized too?

Yes. The ReAct agent loop and delegated sub-agents build the provider through the same SanitizingProvider wrapper, so system prompts, messages, and tool results are all sanitized before any LLM call.

Is the config the same on the Controller?

The fields and behavior are identical; only the storage location differs. Enterprise mode reads and writes /admin/sanitization/config centrally, and accepts pattern as an alias for regex. See Controller SanitizingProvider.

Related

• LLM Configuration — choose and connect a provider; sanitization wraps whichever you pick.
• AI Chat — the interactive assistant whose messages and selected text are sanitized.
• NOC Agents — autonomous agents that run through the same sanitizing provider.
• Sub-Agent Orchestration & Delegation — delegated sub-agents inherit the same redaction guarantee.
• MCP Servers — external tool integrations and how their data flows.
• The Local Agent (Personal Mode) — the loopback service that stores the local config and runs the sanitizer.