Sensitive Data Detection

MCPProxy includes automatic sensitive data detection to identify potential credential leakage, secrets exposure, and other security risks in AI agent tool calls. This feature helps protect against Tool Poisoning Attacks (TPA) and provides compliance auditing capabilities.

Overview

When AI agents interact with MCP tools, they may inadvertently expose sensitive information such as:

• Credentials passed in tool arguments or returned in responses
• API tokens leaked through error messages or debug output
• Private keys embedded in configuration data
• Database connection strings with embedded passwords

MCPProxy scans all tool call arguments and responses for sensitive data patterns, logging detections in the activity log for security review and compliance auditing.

Supported Detection Types

Cloud Credentials

Private Keys

API Tokens

LLM/AI Provider API Keys

Database Credentials

Credit Cards

Credit card numbers are detected using pattern matching combined with Luhn algorithm validation:

:::note Luhn Validation Credit card detection includes Luhn checksum validation to reduce false positives from random 16-digit numbers. :::

High-Entropy Strings

Strings with high Shannon entropy that may indicate secrets:

Sensitive File Paths

Detection of file paths that typically contain sensitive data:

Detection Categories and Severities

Categories

Severities

Activity Log Integration

When sensitive data is detected, it is recorded in the activity log metadata:

{
  "id": "01JFXYZ123ABC",
  "type": "tool_call",
  "server_name": "filesystem-server",
  "tool_name": "read_file",
  "status": "success",
  "timestamp": "2025-01-15T10:30:00Z",
  "metadata": {
    "sensitive_data_detected": true,
    "sensitive_data": [
      {
        "type": "aws_access_key",
        "category": "cloud_credentials",
        "severity": "critical",
        "location": "response",
        "context": "AKIA...XXXX (redacted)"
      },
      {
        "type": "private_key",
        "category": "private_key",
        "severity": "critical",
        "location": "response",
        "context": "RSA PRIVATE KEY detected"
      }
    ]
  }
}

:::caution Redaction A detection record itself never carries the value that triggered it — only the type, category, severity and location are stored. :::

Masked payloads

A detection is stored alongside the call it came from, and that call's arguments and response are kept for debugging. Serving those verbatim would mean the screen that warns you about a credential also prints it, in cleartext, next to a Copy button — into every screenshot, screen-share and exported page.

So MCPProxy masks them server-side, in the REST layer, before the record leaves the process:

• GET /api/v1/activity and GET /api/v1/activity/{id} replace every detected value inside arguments, response and error_message with a recognisable preview — AKIAIOSFODNN7EXAMPLE becomes AKIA…****. Enough to tell you which credential to rotate, not enough to use. A private key is replaced whole, envelope and body: its pattern matches only the -----BEGIN …----- line, and masking that alone would leave the key readable.
• Masking applies to records the detector flagged (has_sensitive_data: true); an unflagged payload is served unchanged. Detection runs asynchronously just after the call is recorded, so a record read in that sub-second window is not yet flagged and is served unmasked.
• The live event stream (GET /events, and therefore the tray and mcpproxy activity watch) masks unconditionally: those events are emitted at completion time, before the detector has a verdict to gate on.
• GET /api/v1/tool-calls and friends — a separate store with no detection metadata — mask unconditionally too.
• Internal _auth_* arguments (the server-edition identity MCPProxy injects into a call) are stripped from every browsing response.
• The Web UI's activity drawer and mcpproxy activity show both read the activity endpoints, so both are masked.

Full values remain reachable through one deliberate, separately-flagged surface for incident response and compliance:

mcpproxy activity export --include-bodies

That export deliberately keeps _auth_* as well: attributing a call to a user is the point of a compliance export.

Masking follows the same sensitive_data_detection categories as detection — a category you exclude is neither flagged nor masked. It does not follow the enabled flag: records flagged while detection was on stay masked after you turn it off, so disabling the feature never starts serving old credentials.

Web UI Usage

The Activity Log page in the web UI provides filtering and visualization for sensitive data detections.

Filtering by Sensitive Data

1. Navigate to Activity Log in the sidebar
2. Use the Sensitive Data filter dropdown to show only activities with detections
3. Filter by severity level (critical, high, medium, low)
4. Click on an activity row to view detection details

Detection Indicators

Activities with sensitive data detections are marked with visual indicators:

• Red shield icon for critical severity
• Orange warning icon for high severity
• Yellow info icon for medium severity
• Gray info icon for low severity

Detail View

Clicking on an activity with detections shows:

• List of all detected sensitive data types
• Location (arguments or response)
• Timestamp and duration
• The request arguments and response body, with every detected value masked (AKIA…****) and both panels badged Masked — see Masked payloads

CLI Usage

List Activities with Sensitive Data

# Show all activities with sensitive data detections
mcpproxy activity list --sensitive-data

# Filter by severity
mcpproxy activity list --sensitive-data --severity critical

# Combine with other filters
mcpproxy activity list --sensitive-data --server github-server --status success

View Detection Details

# Show full details including sensitive data metadata
mcpproxy activity show 01JFXYZ123ABC

# JSON output for scripting
mcpproxy activity show 01JFXYZ123ABC --output json

Export for Compliance

# Export activities with sensitive data for security review
mcpproxy activity export --sensitive-data --output security-audit.jsonl

# Export critical severity only
mcpproxy activity export --sensitive-data --severity critical --output critical-findings.jsonl

Summary Statistics

# Show sensitive data detection summary
mcpproxy activity summary --period 24h

# Output includes detection counts by category and severity

Configuration

Sensitive data detection is enabled by default. Configure via mcp_config.json:

{
  "sensitive_data_detection": {
    "enabled": true,
    "scan_arguments": true,
    "scan_responses": true,
    "severity_threshold": "low",
    "categories": {
      "cloud_credentials": true,
      "private_key": true,
      "api_token": true,
      "auth_token": true,
      "sensitive_file": true,
      "database_credential": true,
      "high_entropy": true,
      "credit_card": true
    }
  }
}

See Configuration for complete reference.

Cross-Platform Support

Sensitive file path detection adapts to the operating system:

Path detection normalizes separators and expands home directory references for consistent cross-platform detection.

Security Best Practices

Compliance Auditing

Use sensitive data detection for regular security audits:

# Weekly security audit export
mcpproxy activity export \
  --sensitive-data \
  --start-time "$(date -v-7d +%Y-%m-%dT00:00:00Z)" \
  --output weekly-security-audit.jsonl

# Generate summary report
mcpproxy activity summary --period 7d --output json > weekly-summary.json

Real-time Monitoring

Monitor for critical detections in real-time:

# Watch for sensitive data detections
mcpproxy activity watch --sensitive-data --severity critical

Integration with SIEM

Export activity logs for integration with Security Information and Event Management (SIEM) systems:

# Continuous export for SIEM ingestion
mcpproxy activity export --format json --output - | \
  your-siem-forwarder --input -

Incident Response

When a critical detection is identified:

1. Review the activity: mcpproxy activity show <id>
2. Identify the source: Check server name and tool name
3. Assess impact: Determine if credentials were exposed externally
4. Rotate credentials: If exposed, rotate the affected credentials immediately
5. Investigate root cause: Review how sensitive data entered the tool call

Prevention Recommendations

1. Use Docker isolation for untrusted servers with network_mode: "none"
2. Enable quarantine for new servers added by AI agents
3. Review tool descriptions for potential data exfiltration patterns
4. Set up alerts for critical severity detections
5. Regular audits of activity logs for security compliance

Related Features

• Activity Log - Core activity logging functionality
• Security Quarantine - Protection against Tool Poisoning Attacks
• Docker Isolation - Container-based server isolation
• Intent Declaration - Track operation types and data sensitivity