googleapis / googleapis/mcp-toolbox

feat: Add policy-based automatic PII detection and dynamic masking

Open
#3,373 17 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: p2 type: feature request
Dominant language
Go
Stars
16.5k
Forks
1.7k
Avg merge
4d 9h
Merged PRs (30d)
85

Description

## Feature Request

**Is your feature request related to a problem? Please describe.**
Enterprises using MCP Toolbox to connect AI agents to databases face significant privacy compliance challenges (GDPR, CCPA, HIPAA, etc.) when query results contain personally identifiable information (PII). While MCP Toolbox provides secure access controls, it lacks intelligent output filtering to automatically detect and mask PII in query results before they reach LLMs or applications.

## Describe the solution you'd like
Add a policy-based automatic PII detection and dynamic masking layer that:
1. Scans query results for PII using configurable patterns, dictionaries, and optional NLP
2. Applies dynamic masking (partial/full/tokenization) based on data classification policies
3. Respects user/role-based permissions for different masking levels
4. Preserves data utility where possible (e.g., statistical masking for analytics)
5. Logs masking actions for audit trails without exposing raw sensitive data

### Example Policy Configuration (in tools.yaml):
```yaml
kind: pii-policy
name: gdpr-compliant
rules:
- pattern: "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Z|a-z]{2,}\\b"
type: EMAIL
action: MASK_PARTIAL # Shows first/last char: j*****n@example.com
- pattern: "\\b\\d{3}-\\d{2}-\\d{4}\\b"
type: SSN
action: MASK_FULL # Shows ***-**-****
- column: credit_card_number
type: CREDIT_CARD
action: TOKENIZE # Reversible tokenization for authorized users
```

### Integration:
- As a configurable middleware layer in the tool execution pipeline
- Works with all prebuilt tools (execute_sql, query_table, etc.)
- Compatible with custom tools framework
- Role-based policy application

## Describe alternatives you've considered
- External services like Shynk (issue #2895) but preference for native, zero-dependency solution
- Manual tool-level masking (doesn't scale, error-prone)
- Application-level filtering (defeats purpose of Toolbox as unified data layer)

## Additional context
This feature would transform MCP Toolbox from a secure conduit into an intelligent privacy-aware data fabric, addressing a critical gap for regulated industries adopting AI agents. It aligns with the project's goals of enhanced security and enterprise readiness.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No implementation file or test is named. Start by tracing the tool execution pipeline for execute_sql, query_table, and custom tools, then determine where a configurable policy layer and role-based masking would apply. Done would require an agreed policy format, detection and masking behavior, audit handling, and coverage across the supported tool paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend-api-design, databases, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.