Skip to main content
Glama
teodorofodocrispin-cmyk

trustboost-pii-sanitizer

TrustBoost PII Sanitizer

A precision PII redaction layer for autonomous AI agent pipelines. Detects and redacts personally identifiable information before it reaches LLM providers, across English, Spanish (LATAM), Portuguese (BR/PT), German, Japanese, French, Italian, and Korean.

  • Endpoint: https://api.trustboost.dev/sanitize

  • Stack: FastAPI · OpenAI gpt-4o-mini (temperature 0) · Supabase · Solana payments via Helius

🛡️ Live Demo — no registration required

Try TrustBoost instantly in your browser: 👉 https://huggingface.co/spaces/TrustBoost/pii-sanitizer

Related MCP server: classifinder-mcp

Try it in 10 seconds — no wallet needed

curl -X POST https://api.trustboost.dev/sanitize/preview \
  -H "Content-Type: application/json" \
  -d '{"text": "My name is John Doe, email john@gmail.com, SSN 123-45-6789"}'
{
  "sanitized_content": "My name is [REDACTED], email [REDACTED], SSN [REDACTED]",
  "safety_score": 0.6,
  "risk_category": "PRIVATE",
  "demo": true,
  "requests_remaining": 2,
  "next": "https://github.com/teodorofodocrispin-cmyk/TrustBoost-PII-Sanitizer#trial"
}

3 free previews per IP · no account · no wallet · no setup. Ready for more? See Trial mode below — 50 free sanitizations with a Solana wallet.


The lightest-weight entry point for autonomous agents: pay $0.01 USDC per call, no TRIAL, no tx_hash, no prepaid bundle.

curl -X POST https://api.trustboost.dev/sanitize/quick \
  -H "Content-Type: application/json" \
  -H "PAYMENT-SIGNATURE: <base64-encoded x402 v2 signature>" \
  -d '{"text": "Contact John at john@company.com, SSN 123-45-6789"}'
  • Networks: Base (eip155:8453, preferred) or Solana (solana:5eykt4...) — auto-detected

  • Verified + settled via PayAI facilitator

  • X-PAYMENT header also accepted (x402 v1, legacy)

  • No text or no payment header yet? Returns a standard x402 v2 402 with payment instructions

  • For 10,000+ calls, the prepaid bundle (149 USDC) is cheaper per call


MCP Server — Claude, Cursor & Windsurf native integration

TrustBoost is available as an MCP (Model Context Protocol) server. Add it to any MCP-compatible agent in one line:

{
  "mcpServers": {
    "trustboost": {
      "url": "https://api.trustboost.dev/mcp"
    }
  }
}

Once connected, your agent can call sanitize_pii automatically before sending any text to an LLM:

# Manifest
curl https://api.trustboost.dev/mcp

# Execute
curl -X POST https://api.trustboost.dev/mcp \
  -H "Content-Type: application/json" \
  -d '{"tool": "sanitize_pii", "input": {"text": "My email is john@gmail.com"}}'

Compatible with: Claude Code · Cursor · Windsurf · Any MCP-compatible agent


Quick start

curl -X POST https://api.trustboost.dev/sanitize \
  -H 'Content-Type: application/json' \
  -d '{
    "text": "My email is jane@example.com and my AWS key is AKIAIOSFODNN7EXAMPLE",
    "tx_hash": "TRIAL",
    "wallet_address": "your-agent-id"
  }'

Trial mode (tx_hash="TRIAL") gives 50 free sanitizations per wallet_address. Paid mode requires 149 USDC on Solana to the configured payment wallet, which unlocks 10,000 sanitizations per transaction signature.

Response schema (v2.6.0)

{
  "status": "success",
  "request_id": "TRIAL",
  "data": {
    "message": "Content successfully sanitized and logged.",
    "sanitized_content": "My email is [REDACTED] and my AWS key is [REDACTED]",
    "safety_score": 0.6,
    "risk_category": "CRITICAL",
    "entities_removed": true,
    "entities": [
      { "type": "email",          "category": "PRIVATE",  "redacted_text": "jane@example.com" },
      { "type": "aws_access_key", "category": "CRITICAL", "redacted_text": "AKIAIOSFODNN7EXAMPLE" }
    ],
    "redaction_source": "server",
    "timestamp": "2026-05-03T23:48:14.500705+00:00",
    "usage_metrics": { "quota_remaining": 48, "quota_limit": 50 }
  },
  "billing": { "license_type": "TRIAL", "status": "active" }
}

Field guide

Field

Type

Notes

sanitized_content

string

Same language and structure as input, with PII replaced by [REDACTED].

entities

Entity[]

One element per [REDACTED] tag. Stable, machine-friendly.

safety_score

float 0.0 – 1.0

Server-side, deterministic. Computed from entities, not the model.

risk_category

CRITICAL/PRIVATE/SENSITIVE/CLEAN

Highest tier present in entities.

entities_removed

bool

Convenience: true iff entities is non-empty.

redaction_source

"model" | "server" | "fallback_full_redaction"

Telemetry: who actually performed the redaction (see below).

unmatched_entities

Entity[] (optional)

Entities the model reported but whose redacted_text wasn't found verbatim in the input. Omitted when empty.

Risk weights

safety_score is the sum of per-entity weights, capped at 1.0:

  • CRITICAL → 0.40 (API keys, private keys, seed phrases, credentials, card numbers, …)

  • PRIVATE → 0.20 (emails, phone numbers, national IDs, addresses, names, …)

  • SENSITIVE→ 0.05 (handles, partial identifiers, DOB, …)

risk_category is the highest-severity tier with at least one entity, or "CLEAN" if entities is empty.

Server-side redaction enforcement (v2.6.0)

The model returns two things that have to agree: cleaned_text and entities. In practice they sometimes disagree — the model can correctly identify an entity in entities but fail to actually replace it in cleaned_text. That produces a sanitized_content that still leaks PII while the audit trail says everything is fine, which is worse than no audit trail.

v2.2 fixes this structurally. The model is now treated purely as a detector: it returns the entity list. The server is the redactor: for every entity whose redacted_text is a non-empty substring of the original input, the server replaces all occurrences with [REDACTED]. Long entities are processed before short ones to avoid partial overlap.

Conservative redaction by design: if the same value (e.g. 田中太郎) appears twice in the input, both occurrences are scrubbed.

The redaction_source field tells you what happened:

  • "model" — the model's cleaned_text already matched the entity list, so server-side enforcement was a no-op (the model did its job).

  • "server" — the server-side enforcer replaced one or more entities the model failed to remove. Track this metric over time as a model-reliability signal: a rising server rate means the prompt or model is drifting.

  • "fallback_full_redaction" — the model returned malformed JSON; the failsafe parser triggered and the entire input was redacted as a single CRITICAL entity. Should be near-zero in steady state.

When the model's redacted_text does not appear verbatim in the input (paraphrasing, normalization, or hallucination), the entity is preserved in entities (and counts toward safety_score) but is also returned in unmatched_entities so callers can audit it.

Failure mode: fail-safe, not fail-open

If the upstream model returns malformed JSON, the response degrades to a single CRITICAL entity covering the entire input rather than risking a silent leak. Over-redaction is always preferred over under-redaction.

Languages and patterns

The system prompt covers, among others:

  • English (global): emails, phones, SSN, credit cards, IBAN, IPs, addresses, and provider-specific API keys (OpenAI, Anthropic, GitHub, AWS, Google, Slack, HuggingFace, Stripe), private keys, crypto wallets, seed phrases.

  • Spanish (LATAM): RFC, CURP, CUIT/CUIL, RUT, DNI, RUC, NIT, Cédula, country phones.

  • Portuguese (BR/PT): CPF, CNPJ, RG, NIF, NUS, CEP, country phones.

  • German (DE/AT/CH): Personalausweis, Steuer-IDs, Sozialversicherungsnummer, IBAN DE, addresses.

  • Japanese: マイナンバー, 法人番号, 運転免許証, パスポート, 健康保険証, 電話番号, 住所, and 氏名 (full names in kanji, mixed scripts, katakana, or hiragana).

  • French (FR/BE/CH/CA): NIR (Numéro de Sécurité Sociale), SIRET, SIREN, Carte Vitale, IBAN FR, Numéro fiscal, country phones +33/+32/+41.

  • Italian (IT): Codice Fiscale, Partita IVA, Carta d'Identità (CIE), Tessera Sanitaria, IBAN IT, Patente di Guida, country phone +39.

  • Korean (KR): 주민등록번호 (RRN), 사업자등록번호, 여권번호, 운전면허번호, 건강보험번호, 외국인등록번호, country phone +82.

Running locally

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

cp .env.example .env  # then fill in real keys
uvicorn main:app --reload

Required environment variables:

  • OPENAI_API_KEY

  • SUPABASE_URL, SUPABASE_KEY

  • HELIUS_API_KEY, PAYMENT_WALLET

  • Optional: TRIAL_QUOTA (default 50), PAID_QUOTA (default 10000), REQUIRED_PAYMENT_USDC (default 149)

Tests

pip install pytest
python -m pytest tests/test_sanitize.py -v          # unit tests, no creds needed
TRUSTBOOST_LIVE=1 python -m pytest tests/test_live.py -v   # hits real /sanitize

The live tests consume TRIAL quota; set TRUSTBOOST_WALLET to a CI-specific identifier so they don't share quota with developer wallets.

Versioning

  • 2.6 — Proof of Sanitization on Solana via Helius. Every paid sanitization anchored on-chain. Verifiable at /verify/{anchor_tx}. x402 native — HTTP 402 with autonomous payment instructions. CORS for browser agents. agent-card.json for Circle Agent Stack discovery.

  • 2.5 — Context-Aware Sanitization, Privacy Budget per Agent, TrustBoost Score M2M.

  • 2.2 — server-side redaction enforcer, redaction_source telemetry, unmatched_entities audit field.

  • 2.3 — Context-Aware Sanitization: context field in /sanitize (legal/financial/medical/code/general). Adjusts sanitization depth per context type. Adds context_applied to response.

  • 2.4 — Privacy Budget per Agent: agent_budgets table in Supabase. Operators configure daily limits once, agents operate autonomously within them.

  • 2.5 — TrustBoost Score: /score/{wallet} endpoint. M2M trust verification with trust tier (TRUSTED/VERIFIED/ACTIVE/NEW). Aggregated from audit_log.

  • 2.6 — Proof of Sanitization on Solana: every paid sanitization is anchored on-chain via Helius Memo transaction. Verifiable by anyone at /verify/{anchor_tx}. Returns proof_of_sanitization object with Solscan link.

  • 2.1 — structured entities array, server-side deterministic scoring, hardened JSON parsing, improved Japanese 氏名 detection.

  • 2.0 — multilingual prompt rewrite.

Available Tools

1 tool
sanitize_piiB

Sanitize PII from text before sending to LLMs. Returns sanitized text with PII replaced by [REDACTED].

ParametersJSON Schema
NameRequiredDescriptionDefault
textYes
tx_hashNoTRIAL
wallet_addressNomcp-agent

TDQS

B3.4/5.0
Behavior3/5

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 discloses that PII is replaced with '[REDACTED]' and returns sanitized text, which is reasonable. However, it lacks details on what PII is detected, whether it's reversible, or any side effects.

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

Conciseness4/5

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

The description is a single sentence of 14 words, making it very concise. While it is not verbose, it sacrifices parameter documentation and additional context. It earns a 4 for being tight and front-loaded.

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

Completeness2/5

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

Given the tool has 3 parameters (with defaults) and no output schema, the description is too sparse. It explains the output format but ignores the purpose of the optional parameters, leaving the agent with incomplete guidance for effective use.

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

Parameters1/5

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

The input schema has 0% description coverage, and the description does not explain any parameters (text, tx_hash, wallet_address). For a low-coverage schema, the description should compensate but fails to add any meaning beyond the schema itself.

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?

The description clearly states the tool's purpose: sanitizing PII from text. It uses a specific verb-resource combination ('Sanitize PII from text') and explains the output format. There are no sibling tools, so no differentiation needed.

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 description provides a clear use case: 'before sending to LLMs,' which implies when to use it. However, it does not include explicit guidance on when not to use or mention alternatives, which keeps it from a perfect score.

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. Dates show when Glama detected each change.

  1. 1 tool updatev2.6.0
    • First observedsanitize_pii

TDQS

A3.9/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap. The single tool's purpose is clear and unambiguous.

Naming Consistency5/5

The single tool name 'sanitize_pii' follows a consistent verb_noun pattern, which is clear and predictable.

Tool Count5/5

One tool is appropriate for this narrow, focused purpose (PII sanitization). It is well-scoped without being too few for the task.

Completeness5/5

The tool fully covers its intended functionality: sanitizing PII from text. There are no missing operations for this simple domain.

Maintenance

ActivityActive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/teodorofodocrispin-cmyk/trustboost-api'

If you have feedback or need assistance with the MCP directory API, please join our Discord server