Allows masking PII in prompts before sending them to OpenAI's API and unmasking the responses, ensuring no confidential data is transmitted to OpenAI.
Send sensitive data to Cloud LLMs (ChatGPT, Claude, Gemini) without ever leaking confidential PII.
pip install scrub-vaultScrubVault is a lightweight, zero-dependency in-memory privacy proxy and Model Context Protocol (MCP) server. It intercept prompts, replaces personal identifiable information (emails, IBANs, IP addresses, credit cards, tax IDs) with deterministic local tokens ({{EMAIL_1}}, {{IBAN_1}}), and restores the original values when the AI responds.
+----------------------------------+
| Your Prompt (Confidential PII) |
+----------------------------------+
│
▼
┌─────────────────────────────┐
│ ScrubVault (Local RAM) │
│ - Scans & Masks Sensitive │
│ - Stores Mapping in Memory │
└─────────────────────────────┘
│
▼ (Masked Prompt: "{{EMAIL_1}}, {{IBAN_1}}")
┌─────────────────────────────┐
│ Public Cloud LLM API │
│ (OpenAI / Anthropic / ...) │
│ *Zero PII is transmitted* │
└─────────────────────────────┘
│
▼ (Response with tokens)
┌─────────────────────────────┐
│ ScrubVault (Local RAM) │
│ - Deterministic Unmasking │
└─────────────────────────────┘
│
▼
+----------------------------------+
| End-User Result (Restored PII) |
+----------------------------------+Related MCP server: zentric-protocol-mcp
from src.core.vault import ScrubVault
vault = ScrubVault()
# 1. Mask sensitive input
input_text = "Order for client Max, email: max@corp.de, IBAN: DE89370400440532013000"
result = vault.mask(input_text)
print(result.masked_text)
# Output: "Order for client Max, email: {{EMAIL_1}}, IBAN: {{IBAN_1}}"
# 2. Transmit result.masked_text to your LLM of choice...
ai_response = "Received confirmation for {{EMAIL_1}} on account {{IBAN_1}}."
# 3. Unmask locally
clean_response = vault.unmask(ai_response, result.token_map)
print(clean_response)
# Output: "Received confirmation for max@corp.de on account DE89370400440532013000."# Calculate GDPR Art. 32 Risk Score
python -m src.cli.main audit "Contract with Herr Schmidt, IBAN: DE89370400440532013000"
# Mask a dataset file directly
python -m src.cli.main scrub-dataset input.json output_clean.jsonScrubVault includes a native stdio Model Context Protocol (MCP) server. Add it to your claude_desktop_config.json or Antigravity configuration:
{
"mcpServers": {
"scrub_vault": {
"command": "python",
"args": ["-m", "src.mcp.server"],
"cwd": "/path/to/scrub_vault"
}
}
}npx -y @smithery/cli install @tastenkasperle/scrub-vault --client claudescrub_mask_text: Masks PII in input text and returns a reversible token map.
scrub_unmask_text: Replaces tokens with original values.
scrub_audit_risk: Calculates risk scores and detection breakdowns.
scrub_anonymize_json: Recursively scrubs JSON structures.
Pure Python Standard Library: Zero third-party dependencies (re, json, sys, typing).
In-Memory Vault: Token maps live exclusively in volatile RAM and are never written to disk.
ReDoS Hardened: Regex patterns are strictly bounded against algorithmic complexity attacks.
Audit Passed: Tested and verified by Raptor Guard SAST (0 Critical, 0 High, 0 Medium findings).
Apache License 2.0. Open-source research and engineering by the Diamantenschmiede.
Recursively scans and anonymizes all PII in a JSON data structure for safe staging or testing.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | JSON object or dictionary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet 'anonymizes' is left undefined: it does not say whether values are replaced, hashed, or removed, whether the operation is reversible (notable given the scrub_unmask_text sibling), or whether the input is mutated or a copy returned. Recursion is mentioned, but the privacy-critical semantics of the mutation are not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the verb and scope lead. It is efficient, though arguably it is under-specified rather than concise given how much behavior is left implicit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a privacy-sensitive recursive transformation with nested objects, zero annotations, and no output schema, the definition is too thin: it omits what anonymization produces, return format, reversibility, and mutation behavior, leaving an agent unable to predict the outcome of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'data' parameter is already fully documented in the schema (100% coverage), and the description adds only that PII is scanned within it. Baseline 3 applies when the schema does the heavy lifting and the description adds no format or structure detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (anonymizes), resource (PII in a JSON data structure), and scope (recursively, all PII). It is clearly distinguishable from the text-oriented siblings by naming JSON as the target, though it never explicitly names an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the trailing phrase 'for safe staging or testing,' which hints at intent but gives no when-to-use versus scrub_mask_text or scrub_audit_risk, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits a text or document for GDPR / DSGVO Art. 32 PII risks and returns an audit score.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze for privacy compliance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does disclose the essential behavioral trait: this is a non-mutating analysis that produces a score rather than modifying the input. It omits anything about data handling, storage, permissions, or the shape/range of the returned score, which matters for a privacy-focused tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler, front-loading the action and ending with the returned artifact. It is appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must say more about the 'audit score' it returns, but it does not define its scale, what the score reflects, or what other findings accompany it. For a one-parameter read tool this is adequate but leaves the response contract vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'text' parameter, so the baseline is 3. The description adds the hint that a 'document' can be passed as well as raw text, but no format, size limit, or language details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (audits) and a specific resource/domain (text or document for GDPR/DSGVO Art. 32 PII risks) plus the result (an audit score). It is distinguishable from the scrub_* siblings because it analyzes rather than transforms, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance. It never says whether to run this before scrub_mask_text or scrub_anonymize_json, whether it is a prerequisite to masking, or any condition under which it is not appropriate. Usage is only inferable from the word 'audits'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Masks sensitive PII (emails, phones, IBANs, IPs, tax IDs) from text and generates a local token_map for zero-leakage prompt forwarding.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The input text to mask |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that a token_map is generated and that it is local (a state/side-effect disclosure beyond the schema), which hints at reversibility via scrub_unmask_text. It does not state whether the original text is mutated or returned, permissions needed, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb and scope, with no filler. Every clause earns its place by naming the PII types and the token_map output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations and no output schema, the description covers the action, the masked data classes, and the notable side output (token_map). The main remaining gap is that return values are not described, though the token_map mention partly compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and the schema already documents it at 100% coverage ('The input text to mask'). The description's PII enumeration adds context about what the input is scanned for but no syntax or format guidance beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (masks) and resource (text) and enumerates the PII classes targeted, plus the secondary effect of producing a token_map. It implicitly contrasts with scrub_anonymize_json (text vs JSON) but never names any sibling explicitly, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for zero-leakage prompt forwarding' implies the context of use, which is better than nothing. However, it gives no explicit when-to-use versus scrub_anonymize_json or scrub_audit_risk guidance, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restores original sensitive values into an LLM response using the local token_map.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The LLM response containing masked tokens like {{EMAIL_1}} | |
| token_map | Yes | The token map dictionary returned during masking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints that the operation is local ('local token_map'), but says nothing about the security sensitivity of reinserting real PII, permission requirements, or what happens if the token_map does not match the masked tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the action front-loaded and the mechanism trailing. No padding, though it is arguably too terse given the security-sensitive nature of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema this is minimally adequate, but with zero annotation coverage and a sensitive-data operation, the description omits ordering, matching requirements between token_map and text, and any safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage on both parameters, the schema already documents 'text' and 'token_map'. The description only restates that the token_map is what was 'returned during masking', adding little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('restores') and resource ('original sensitive values into an LLM response') plus the mechanism ('using the local token_map'). It is clearly the inverse of scrub_mask_text, but the description never names that sibling explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not guidance. The agent must infer that this is called after masking, with a token_map obtained from a masking step, and nothing warns about when unmasking would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0scrub_anonymize_jsonscrub_audit_riskscrub_mask_textscrub_unmask_textScored across 4 tools
Each tool targets a distinct operation: masking text, restoring values, auditing risk, and anonymizing JSON. Mask/unmask are clearly paired complements rather than overlapping, and audit/anonymize are separate concerns.
All tools use a consistent scrub_ prefix followed by a verb_noun pattern (mask_text, unmask_text, audit_risk, anonymize_json) in uniform snake_case.
Four tools is well-scoped for a focused PII-scrubbing server, with mask/unmask round-trip, an audit function, and a JSON variant each earning its place.
Covers the core lifecycle of mask, unmask, audit, and JSON anonymization with no obvious dead ends. Minor gaps exist around token_map persistence/management and document/file-level operations, but agents can work around these.
Detect and redact PII and secrets before text reaches an LLM, with reversible placeholders.
Redact PII from text before it reaches a model. Nothing stored, no third-party AI.
Japanese LLM security — prompt injection detection (jpi-guard) + PII masking (PII Guard). Free.
Stateless PII redaction over MCP/REST. Free ≤1000 words or $0.01/call; file upload supported.
