Don't trust us. Inspect the design.
Redactor Desk's security claim is structural, not a policy promise: the agent's tool surface cannot lead out unsanitized. This page explains how that's built and where the honest limits are. It's written by our developers — not a third-party audit (an independent audit is on the roadmap).
The core invariant
Two sentences everything hangs on.
- Everything that enters model context — file contents, search results, your own message — passes
sanitize()first. - Everything the model emits — chat text, written file contents, edits — passes restoration before it is displayed or written to disk.
Why the surface can't leak
A single choke point
Detection and tokenization run exclusively locally. There is exactly one place where text becomes model input — and it redacts.
No shell, no built-ins
The agent has no shell access and no built-in tools. Only five file operations are allowed, each through the redaction layer. No channel bypasses it.
Edits in sanitized space
The model edits the sanitized view; real values are re-inserted locally just before the file is written. A hash guard rejects stale edits.
Fail closed
Where a category is set to "block" (Enterprise policy), the sanitizer returns nothing rather than risk letting something through.
What a pack cannot do
A pack puts someone else's text into your agent's context. That is a fair objection — and the reason the format is deliberately poor in capability.
- A pack is a directory of a manifest file and Markdown text. It cannot define a tool, open a network connection, read a file, or run a script. It cannot change the tool permission gate, switch a session from plan to build mode, or decide which detector categories are blocked. That is a property of the format, not a promise of good behaviour.
- Every pack is validated, including our own. On load the client compares the contents against what the manifest declares — in both directions. A pack carrying more than it declared is refused; so is a pack declaring a capability it has no content for. Refused means visible: in the Packs view, with a reason, rather than silently skipped.
- The same check is asserted twice and written once. The test cases live as a corpus in the packs repository — each one a pack directory plus the verdict it must produce. The client runs that same corpus in its own tests. So "a pack whose contents exceed its manifest is refused" is one assertion that breaks in two places at once when it breaks — not two prose descriptions that drift apart.
- Detection rules from packs are not in service yet. A pack may carry detectors and advisories; the client validates them but applies them in no shipped build. So a pack can today neither widen nor weaken detection.
- Nothing is fetched, nothing is reported. The client pulls no packs from a catalogue and reports nowhere which ones you enabled. You place your own pack in a folder yourself; it stays on your machine.
Your data
- The Anthropic key is stored encrypted via the OS keychain (Keychain/DPAPI), never in plaintext. With Amazon Bedrock, the client prefers your IAM credential chain (SSO, temporary credentials) — static AWS keys are the fallback only and are stored encrypted the same way.
- The placeholder → real-value mapping lives in a local vault on your machine. None of it leaves the device.
- The evidence log (Enterprise, optional) is hash-chained and holds only categories and counts — never the values.
- A backup is written before every file change; every change is reversible.
Honest limitations
- Detection is deterministic and heuristic. What isn't detected isn't replaced — we promise no hit-rate numbers without an independent benchmark.
- "Fully offline" applies to detection and tokenization. The client itself talks to the model API — the Anthropic API or your own Amazon Bedrock in the EU region, inside your AWS boundary, with your IAM.
- Regulatory wording is deliberately "supports", never "meets".
Report a vulnerability
Found something? Please report it privately and give us reasonable time to fix it before going public. Please no real secrets in your report.
- Email kontakt@zerodotfive.com, subject "Redactor Desk security".