Skip to main content
Glama
scrubguard-dev

scrubguard

Official
by scrubguard-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

ScrubGuard - Deterministic PII & Secret Scrubber + Reversible LLM Tokenizer

Sub-millisecond, zero-dependency PII & secret redaction with mathematical checksum verification (Luhn Credit Cards, ISO 7064 Mod-97 IBANs, SSA US SSN rules) and Reversible LLM Tokenization.

Strip sensitive data before sending prompts to OpenAI, Anthropic, or logs, and rehydrate [EMAIL_1] / [CREDIT_CARD_1] placeholders in the LLM's response automatically.

Features

  • Mathematical Checksum Validation: Cuts false positives on order IDs and random numbers using Luhn (Credit Cards), ISO 7064 Mod-97 (IBANs), and SSA Area/Group/Serial validation (US SSNs).

  • Secret & API Key Detection: Scrubs leaked OpenAI (sk-proj-...), Anthropic (sk-ant-...), Stripe (sk_live_..., sk_test_..., whsec_...), AWS (AKIA...), GitHub PAT (ghp_..., github_pat_...), Slack, Google API, JWT, and PEM Private Keys.

  • Reversible LLM Tokenization: Replaces PII with consistent placeholders ([EMAIL_1], [US_SSN_1]) and returns a vault map so LLM outputs can be restored via rehydrateText or POST /v1/rehydrate.

  • Deep JSON Sanitizer: Recursively scrubs strings and sensitive keys (password, secret, api_key, ssn) up to 32 levels deep without breaking JSON schemas.

  • Linear-Time Regex Engine: Disjoint character classes and bounded repetitions prevent catastrophic backtracking (ReDoS).

Related MCP server: mcp-secret-scrub

Quick Start (Hosted Edge API)

1. Scrub & Tokenize Prompt Before Sending to an LLM (POST /v1/scrub)

curl -X POST https://scrubguard-api.scrubguard.workers.dev/v1/scrub \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Refund customer sarah@acme.io on card 4532 0151 1283 0366 (SSN 412-55-9821)",
    "mode": "tokenize"
  }'

Response:

{
  "output": "Refund customer [EMAIL_1] on card [CREDIT_CARD_1] (SSN [US_SSN_1])",
  "findings_count": 3,
  "findings_by_type": {
    "CREDIT_CARD": 1,
    "US_SSN": 1,
    "EMAIL": 1
  },
  "vault": {
    "[CREDIT_CARD_1]": "4532 0151 1283 0366",
    "[US_SSN_1]": "412-55-9821",
    "[EMAIL_1]": "sarah@acme.io"
  }
}

2. Rehydrate LLM Output (POST /v1/rehydrate)

curl -X POST https://scrubguard-api.scrubguard.workers.dev/v1/rehydrate \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Processed refund for [EMAIL_1] ending in [CREDIT_CARD_1].",
    "vault": {
      "[CREDIT_CARD_1]": "4532 0151 1283 0366",
      "[EMAIL_1]": "sarah@acme.io"
    }
  }'

Node.js / Edge SDK (ScrubGuardClient)

import { ScrubGuardClient } from 'scrubguard-mcp'; // npm install scrubguard-mcp

const guard = new ScrubGuardClient({
  apiKey: process.env.SCRUBGUARD_API_KEY, // Optional: uses hosted Pro Edge API (100k req/mo)
});

// 1. Scrub user prompt
const { output: safePrompt, vault } = await guard.scrub(
  'Email alice@company.com with key AKIAIOSFODNN7EXAMPLE'
);

// 2. Send `safePrompt` to OpenAI / Anthropic...
const llmResponse = `Sent confirmation to ${safePrompt.match(/\[EMAIL_\d+\]/)[0]}.`;

// 3. Restore original values
const { output: finalReply } = await guard.rehydrate(llmResponse, vault);

Model Context Protocol (MCP) Server for Claude Desktop & Cursor

ScrubGuard runs locally by default with no network calls. Add it to your claude_desktop_config.json or .cursor/mcp.json:

{
  "mcpServers": {
    "scrubguard": {
      "command": "npx",
      "args": ["-y", "scrubguard-mcp"]
    }
  }
}

To use the optional hosted Pro API, or to run from a local clone:

{
  "mcpServers": {
    "scrubguard": {
      "command": "node",
      "args": ["/path/to/scrubguard/mcp/index.js"],
      "env": {
        "SCRUBGUARD_API_KEY": "sg_live_optional_pro_key"
      }
    }
  }
}

Exposes three MCP tools to your AI assistant:

  • scrub_text: Scrub or reversibly tokenize PII & secrets in text.

  • rehydrate_text: Restore [TOKEN_1] placeholders using the vault map.

  • scrub_json: Recursively sanitize nested JSON objects and logs.

Support & Contact

Questions, bug reports, or higher volume plans: scrubguard@fastmail.com

Available Tools

3 tools
rehydrate_textA

Restore tokenized placeholders (e.g., [EMAIL_1], [CREDIT_CARD_1]) in LLM responses using the vault map returned by scrub_text.

NameRequiredDescriptionDefault
textYesText containing placeholder tokens
vaultYesKey-value vault map from scrub_text

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does reveal the transformation's direction and its dependency on a prior scrub_text call, but it says nothing about side effects, whether it is a pure transformation, or what happens with unknown or malformed placeholder tokens (left as-is vs. error).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the action, the token examples, and the data dependency. No filler, no redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter transformation with full schema coverage and no output schema, this is close to sufficient, but the lack of any statement about the return value and about handling of unmatched or unknown tokens leaves a real gap for an agent deciding how to react to unexpected results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description adds modest value by naming the placeholder token format and clarifying that the vault is the one returned by scrub_text, but it gives no detail on key/node structure of the nested vault object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Restore') and resource ('tokenized placeholders'), gives concrete placeholder examples, and ties the input to the vault map produced by scrub_text. This makes it trivially distinguishable from its siblings scrub_text and scrub_json, which go in the opposite direction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'using the vault map returned by scrub_text' makes the prerequisite and the correct call ordering explicit, and 'in LLM responses' scopes where it applies. It stops short of stating when not to use it (e.g., raw text containing no tokens, or text not scrubbed by this vault).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scrub_jsonB

Recursively scrub PII and sensitive keys (password, secret, api_key, ssn) in a JSON object or array while preserving schema types.

NameRequiredDescriptionDefault
dataYesJSON object or array to sanitize
modeNotokenize

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It usefully discloses recursion, the specific key set scrubbed, and schema-type preservation, but omits critical behavior: whether the input is mutated in place or a sanitized copy is returned, and whether 'tokenize' output is reversible via rehydrate_text.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One tight sentence with the action and scope front-loaded, the key list inline, and the type-preservation guarantee last. Nothing is wasted or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 annotations and no output schema, the description should at minimum clarify return shape and mutation semantics and the meaning of the mode enum. It covers scope and target keys well but leaves these operative gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: 'data' is documented but 'mode' has only an enum and default with no description. The description never explains what tokenize vs redact vs mask actually produce, which is the single most consequential choice an agent must make when calling this tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('scrub'), a precise resource ('JSON object or array'), and enumerates target keys (password, secret, api_key, ssn), plus recursive scope and type preservation. It implicitly distinguishes itself from scrub_text by operating on structured JSON, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the JSON-object-or-array scope hints at when to pick this over scrub_text, but the description never states when to use it versus scrub_text or rehydrate_text, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scrub_textB

Scrub or reversibly tokenize PII (emails, SSNs, Luhn-verified credit cards, IBANs, phones, IPv4) and leaked API keys/secrets from text.

NameRequiredDescriptionDefault
modeNotokenize ([EMAIL_1] + reversible vault), redact, or masktokenize
textYesRaw text or prompt to sanitize
typesNoOptional whitelist of detector types

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It usefully discloses that tokenize mode is reversible via a vault and that credit cards are Luhn-verified (implying false-positive avoidance), but says nothing about return shape, whether the original is preserved, ordering/idempotency, or performance on large inputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the verb and enumerates exactly which entity classes are covered. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should convey what comes back (sanitized text alone, or findings/counts, and where the vault token references go). For a low-complexity 3-param transform this is adequate but leaves the result contract undefined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all three parameters and the mode enum. The description only adds 'reversibly' to the tokenize mode, which the schema does not say; otherwise it adds no semantics beyond the structured fields. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('scrub or reversibly tokenize') plus an explicit resource list (emails, SSNs, Luhn-verified cards, IBANs, phones, IPv4, secrets). The phrase 'from text' implicitly distinguishes it from scrub_json, but no sibling is named, so the 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to pick this tool over scrub_json or rehydrate_text, and no guidance on choosing between tokenize/redact/mask beyond the enum's parenthetical. 'Reversibly tokenize' hints that a rehydration path exists but never points at rehydrate_text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedrehydrate_text
    • First observedscrub_json
    • First observedscrub_text
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation and input type: scrubbing free text, rehydrating tokenized text, and scrubbing structured JSON. The descriptions make the text-vs-JSON and forward-vs-reverse boundaries unambiguous, so misselection is unlikely.

Naming Consistency5/5

All three tools follow a strict verb_noun snake_case pattern (scrub_text, rehydrate_text, scrub_json), with the verb signaling direction (scrub vs rehydrate) and the noun signaling the target (text vs json). Fully predictable.

Tool Count4/5

Three tools is lean but each earns its place for a focused PII-scrubbing utility; there is no filler. The surface is on the small side, but the scoping is deliberate rather than thin.

Completeness4/5

The core scrub/rehydrate lifecycle is covered for text and scrubbing is covered for JSON, so primary workflows are complete. Minor gaps remain: there is no rehydrate_json counterpart for restoring tokens in structured data, and no way to inspect or manage the vault map.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • privacyscrubber-mcp

    moxno
    A
    license
    A
    quality
    A
    maintenance
    Sanitizes text and files by removing PII, secrets, and custom patterns locally before sending to LLMs, with optional reverse-scrubbing.
    3
    303 npm
    124 PyPI
    2
    MIT

  • mcp-secret-scrub

    sudo-ai-git
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables deterministic, no-LLM scrubbing of secrets from text or logs before they enter agent context, supporting redaction, masking, and hashing without ever leaking the original value.
    33 PyPI
    MIT
  • genpark-personal-vault-zero-knowledge-sanitizer-skill by alphaparkinc

    genpark-personal-vault-zeroofficial

    alphaparkinc
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables local zero-knowledge encryption of a personal vault and sanitization of PII such as credentials, credit cards, and addresses before dispatch to cloud LLMs, with client-side rehydration of masked data.
    7
    -

  • genpark-personal-vault-zero

    Alpha-Park
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables agents to encrypt and sanitize sensitive data such as credentials, credit card numbers, and addresses locally before dispatching prompts to cloud LLMs, then rehydrate the masked values client-side. It runs deterministically with zero external dependencies over MCP JSON-RPC stdio, so no plaintext PII leaves the user's machine.
    7
    -