Privacy & PII

Privacy-First Design

Surfa is built with privacy as a core principle. We help you track analytics without collecting personal information.

TL;DR: Surfa tracks technical metrics (latency, errors, tool names) but never user prompts, responses, or personal data by default.

What We Track

✅ We DO Track

Technical Metrics:

Tool names (e.g., “search”, “get_weather”)
Event types (tool_call, session_started, etc.)
Status (success, error)
Latency in milliseconds
Timestamps

Session Data:

Session IDs (random UUIDs, not linked to users)
Request IDs (for correlation)
Client IDs (MCP client identifier)

Runtime Metadata:

Provider (e.g., “anthropic”, “openai”)
Model (e.g., “claude-3-5-sonnet”)
Mode (stdio, sse, http)

Example of what we track:

{
  "kind": "tool",
  "subtype": "call_completed",
  "tool_name": "search",
  "status": "success",
  "latency_ms": 245,
  "session_id": "uuid-random-123",
  "timestamp": "2026-03-04T12:00:00Z"
}

❌ We DON’T Track

User Content:

❌ User prompts or queries
❌ Tool responses or outputs
❌ File contents
❌ API keys or credentials
❌ Personal identifiable information (PII)

Sensitive Data:

❌ Email addresses
❌ Names
❌ IP addresses (beyond basic geolocation)
❌ Device identifiers
❌ Cookies or tracking pixels

User Opt-Out

Users can disable Surfa tracking entirely via environment variable:

export SURFA_DISABLE_TRACKING=true

When set, the SDK will:

✅ Not send any events to Surfa
✅ Not make any network requests
✅ Fail silently (no errors)
✅ Continue to work normally otherwise

Respect user privacy by documenting this opt-out option in your MCP server’s README.

What You Control (MCP Builders)

As an MCP builder, you decide what data to track. Here’s how to do it responsibly:

✅ Good Practices

Track technical metrics only:

from surfa_ingest import SurfaClient

analytics = SurfaClient(ingest_key="sk_live_...")

# ✅ Good - no PII
analytics.track({
    "kind": "tool",
    "subtype": "call_completed",
    "tool_name": "search",
    "status": "success",
    "latency_ms": 245
})

Track aggregated data:

# ✅ Good - counts, not content
analytics.track({
    "kind": "tool",
    "subtype": "call_completed",
    "tool_name": "search",
    "results_count": 10,  # How many results, not what they are
    "status": "success"
})

Track error types, not messages:

# ✅ Good - error type only
analytics.track({
    "kind": "tool",
    "subtype": "call_failed",
    "tool_name": "database_query",
    "error_type": "DatabaseUnavailable",  # Type, not message
    "status": "error"
})

❌ Bad Practices

Don’t track user input:

# ❌ Bad - contains user's query
analytics.track({
    "kind": "tool",
    "tool_name": "search",
    "query": "user's private search query",  # Don't do this!
    "status": "success"
})

Don’t track tool outputs:

# ❌ Bad - contains response data
analytics.track({
    "kind": "tool",
    "tool_name": "get_user_info",
    "response": {"name": "John Doe", "email": "..."},  # Don't do this!
    "status": "success"
})

Don’t track error messages with PII:

# ❌ Bad - error message might contain PII
analytics.track({
    "kind": "tool",
    "tool_name": "send_email",
    "error_message": "Failed to send to john@example.com",  # Don't do this!
    "status": "error"
})

Surfa is designed to be GDPR-compliant out of the box:

Data Minimization

We only collect the minimum data needed for analytics:

Technical metrics (latency, errors)
Session correlation (random UUIDs)
No personal data by default

User Consent

Data Deletion

Users can request data deletion:

Contact support@surfa.dev
Provide workspace ID
Data deleted within 30 days

Or delete via dashboard: Settings → Delete Workspace

Data Isolation

Each workspace is isolated:

No cross-workspace data sharing
Workspace-scoped API keys
No data aggregation across workspaces

Data Retention

Data retention by tier:

Free: 7 days
Pro: 30 days
Team: 90 days
Enterprise: Custom (up to 1 year)

After retention period, data is automatically deleted.

Best Practices for MCP Builders

1. Document What You Track

Add a privacy section to your MCP server’s README:

## Privacy

This MCP server uses Surfa for analytics. We track:
- Tool usage (which tools are called)
- Success/error rates
- Performance metrics (latency)

We DO NOT track:
- Your prompts or queries
- Tool responses
- Any personal information

To disable tracking:
```bash
export SURFA_DISABLE_TRACKING=true

### 2. Sanitize Error Messages

Remove PII from error messages before tracking:

```python
def sanitize_error(error_msg: str) -> str:
    """Remove potential PII from error messages."""
    # Remove email addresses
    error_msg = re.sub(r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b', '[EMAIL]', error_msg)
    # Remove URLs with potential tokens
    error_msg = re.sub(r'https?://[^\s]+', '[URL]', error_msg)
    return error_msg

# Use it
try:
    result = call_api()
except Exception as e:
    analytics.track({
        "kind": "tool",
        "subtype": "call_failed",
        "tool_name": "api_call",
        "error_type": type(e).__name__,
        "error_message": sanitize_error(str(e)),  # Sanitized
        "status": "error"
    })

3. Use Custom Fields Wisely

Only track what you need:

# ✅ Good - useful for debugging
analytics.track({
    "kind": "tool",
    "tool_name": "database_query",
    "query_type": "SELECT",  # Type, not actual query
    "table_name": "users",   # Table, not data
    "row_count": 42,         # Count, not content
    "status": "success"
})

# ❌ Bad - too much detail
analytics.track({
    "kind": "tool",
    "tool_name": "database_query",
    "sql": "SELECT * FROM users WHERE email='...'",  # Don't do this!
    "results": [{...}],  # Don't do this!
    "status": "success"
})

4. Respect User Preferences

Check for opt-out before tracking:

import os

def should_track() -> bool:
    """Check if tracking is enabled."""
    return os.getenv("SURFA_DISABLE_TRACKING", "").lower() != "true"

if should_track():
    analytics.track({...})

The Surfa SDK already handles this automatically. This is just for reference.

Data Security

In Transit

✅ All data encrypted with TLS 1.3
✅ HTTPS only (no HTTP)
✅ Certificate pinning

At Rest

✅ Encrypted database storage
✅ Workspace-level isolation
✅ Role-based access control (RBAC)

Access Control

✅ API key authentication
✅ Workspace-scoped permissions
✅ No cross-workspace access

Compliance Certifications

Surfa is working towards:

SOC 2 Type II
GDPR compliance certification
ISO 27001

Enterprise customers can request compliance documentation at support@surfa.dev

Transparency

We believe in transparency:

✅ Open source MCP server - View on GitHub
✅ Public SDK - View on GitHub
✅ Clear documentation - You’re reading it!
✅ No hidden tracking - Only what you explicitly send

Questions?

Contact Support

Email us with privacy questions

View SDK Source

See exactly what we track

Authentication Guide

Learn about API key security

Best Practices

More tips for responsible tracking

Summary

Surfa is privacy-first:

No PII collected by default
Users can opt-out anytime
You control what data is tracked
GDPR-compliant design
Transparent and open source

Remember: Track technical metrics, not user content. When in doubt, don’t track it!

Getting Started

MCP Server

Guides

Privacy-First Design

What We Track

✅ We DO Track

❌ We DON’T Track

User Opt-Out

What You Control (MCP Builders)

✅ Good Practices

❌ Bad Practices

Best Practices for MCP Builders

1. Document What You Track

3. Use Custom Fields Wisely

4. Respect User Preferences

Data Security

In Transit

At Rest

Access Control

Compliance Certifications

Transparency

Questions?

Contact Support

View SDK Source

Authentication Guide

Best Practices

Summary

Getting Started

MCP Server

Guides

​Privacy-First Design

​What We Track

​✅ We DO Track

​❌ We DON’T Track

​User Opt-Out

​What You Control (MCP Builders)

​✅ Good Practices

​❌ Bad Practices

​GDPR Compliance

​Best Practices for MCP Builders

​1. Document What You Track

​3. Use Custom Fields Wisely

​4. Respect User Preferences

​Data Security

​In Transit

​At Rest

​Access Control

​Compliance Certifications

​Transparency

​Questions?

Contact Support

View SDK Source

Authentication Guide

Best Practices

​Summary

Privacy-First Design

What We Track

✅ We DO Track

❌ We DON’T Track

User Opt-Out

What You Control (MCP Builders)

✅ Good Practices

❌ Bad Practices

GDPR Compliance

Best Practices for MCP Builders

1. Document What You Track

3. Use Custom Fields Wisely

4. Respect User Preferences

Data Security

In Transit

At Rest

Access Control

Compliance Certifications

Transparency

Questions?

Summary