The Problem
Your Docs Are Full of Things You Can’t Publish
Publishing a markdown tree publishes everything in it — and it isn’t only human readers: AI agents reading your docs over MCP will happily use a leaked credential. CI secret scanners guard commits, not the documentation you serve; most skip markdown entirely.
Secrets & credentials
RedactedAWS keys, GitHub tokens, Stripe keys, PEM private keys, Slack tokens, JWTs, passwords in config snippets, credentials inside connection URLs
Personal data (PII)
RedactedEmail addresses, international-format phone numbers (reserved documentation values like example.com are never flagged)
Internal infrastructure
Redacted / reportedPrivate and link-local IP addresses, hostnames under internal domains (yours plus built-in suffixes like .internal), context-anchored AWS account IDs
Confidential terms
RedactedAnything you list: project codenames, client names, unreleased product names — matched case-insensitively on word boundaries
How It Works
Scan → Redact → Vault → Report
Every publish is scanned before anything goes live
The scan runs inside the publish pipeline itself, before content is staged — the built site, the stored copies and the search index all derive from sanitized content. Findings never block a publish; a scanner failure fails the publish rather than shipping unscanned pages.
Sensitive values become redaction chips backed by an encrypted vault
Readers see a neat ••• chip
— in prose, tables and code blocks alike. The original value is stored in the Redaction
Vault, encrypted with a dedicated key and isolated per workspace. Chips aren’t holes in your
docs: workspace admins will be able to unmask a chip in place after a fresh multi-factor
check, with every reveal audited (rolling out next).
Your AI agents never see raw secrets
The same redaction covers what SystemDox serves over MCP and in the in-app reader — everywhere the documentation is read. Context delivery to Claude Code, Cursor or any MCP client carries chips, never credentials.
Findings tell you what to rotate
Redaction is display-level protection, not remediation: a credential that reached git history is compromised until rotated. Every publish produces a per-file findings report — masked previews, never the values — so you can rotate the real ones and fix the source. We’d rather be honest about that than pretend hiding is fixing.
Setup
Three Steps to a Sanitized Knowledge Base
- 1
Open Settings → Sanitization
Workspace admins choose an action per category (redact, report-only, off), list confidential terms and internal domain suffixes, and maintain an allowlist for intentional examples. The policy applies workspace-wide — it’s a compliance posture, not a per-repo preference.
- 2
Dry-run before you enforce
Paste sample markdown into the built-in tester and see exactly what the draft policy would redact — nothing is stored. Tune rule overrides until the preview matches your intent.
- 3
Publish as usual
The publish panel shows a scanning phase, then a findings summary: how many values were redacted, reported or suppressed, per file. Policy changes automatically re-publish with the new posture on the next publish — no manual rebuilds.
FAQ
Common Questions
What about intentional examples in our docs — test keys, sample IPs?
Reserved documentation values (example.com, RFC 5737 IP ranges, 555 numbers) are never
flagged. False-positive-prone rules like Stripe test keys and AWS account IDs default
to report-only. For everything else there’s the allowlist, and inline escape hatches:
<!— sdx:allow —> on a line, or
<!— sdx:allow-file —> at the top of a file.
Suppressions are always counted in the report — never silent.
Does redaction fix a leaked credential?
No — and we won’t pretend it does. Redaction stops readers and agents from seeing the value; the credential itself is compromised until you rotate it (it’s still in git history). The findings report exists precisely so you know what to rotate.
Where are the original values stored?
In the Redaction Vault: encrypted with a dedicated KMS key, bound to your workspace and the specific redaction (a row copied elsewhere fails to decrypt), deduplicated, and cleaned up when the last referencing repo is unpublished. Decryption is reserved for the audited, MFA-gated unmask path — no other component holds that permission.
Does this replace making my portal private?
No — it composes with it. Portals are private to your workspace by default; sanitization protects what your own members, invited readers and AI agents see, and makes going public a decision about audience rather than a leak risk.
Can a finding block a publish?
Findings never block — content is redacted and ships. The only thing that stops a publish is the scanner itself failing: for workspaces with sanitization enabled we fail closed rather than ever shipping unscanned content.