This document describes the security model, best practices, and vulnerability reporting process for the Attio MCP Server.

We take security seriously. If you discover a security vulnerability, please report it through GitHub Security Advisories:

1. Go to Security Advisories
2. Click "Report a vulnerability"
3. Provide a detailed description of the issue

Response Timeline:

• 48 hours: Initial acknowledgment
• 7 days: Preliminary assessment
• 90 days: Target fix timeline for confirmed vulnerabilities

Please do not disclose vulnerabilities publicly until we've had a chance to address them.

The MCP server supports two authentication methods:

export ATTIO_API_KEY=your_api_key_here

Get your API key from Attio Settings → API.

export ATTIO_ACCESS_TOKEN=your_oauth_token_here

Used for delegated authentication via Smithery or Cloudflare Worker deployments.

Resolution Order:

1. ATTIO_API_KEY (from MCP config)
2. ATTIO_ACCESS_TOKEN (from MCP config)
3. ATTIO_API_KEY (from environment)
4. ATTIO_ACCESS_TOKEN (from environment)

When creating an Attio API key or OAuth application, ensure it has the appropriate scopes:

Principle of Least Privilege: Only grant the scopes your use case requires.

• Store credentials in .env file (automatically gitignored)
• Set file permissions: chmod 600 .env
• Never commit credentials to version control

• Use Docker secrets or environment variables
• Avoid baking credentials into images
• Use --env-file for local testing only

• Secrets stored in Workers KV with AES-256-GCM encryption
• Use wrangler secret put for sensitive values
• Never expose secrets in wrangler.toml

• Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password, etc.)
• Rotate credentials regularly
• Implement secret versioning for rollback capability
• Monitor for credential exposure (GitHub secret scanning, etc.)

The server implements configurable rate limiting to prevent abuse:

See src/config/security-limits.ts for full configuration options.

All logs automatically redact sensitive information:

• Email addresses
• Phone numbers
• API keys and tokens
• Credit card numbers
• UUIDs and identifiers (masked)

• Credentials are never logged
• Error messages are sanitized before returning to clients
• Binary data is redacted from logs

See src/utils/log-sanitizer.ts for the redaction implementation.

• Production deployments MUST use TLS
• The Cloudflare Worker example enforces HTTPS
• Local development may use HTTP for testing only

• Cloudflare Worker includes CORS headers for Claude.ai and ChatGPT
• Configure allowed origins for your deployment

• Sensitive data should never be passed in query parameters
• Use request bodies for credentials and PII

When running in Docker:

# docker-compose.yml security settings
services:
  attio-mcp:
    user: '1001:1001' # Non-root user
    read_only: true # Read-only filesystem
    security_opt:
      - no-new-privileges:true # Prevent privilege escalation
    tmpfs:
      - /tmp # Writable temp directory

See the Dockerfile for the hardened container image.

All authenticated users can access all fields. Attio's API does not currently support field-level permissions through API keys.

The server relies on TLS for transport security. There is no request signing or HMAC verification.

For audit trails, use external observability tools:

• Structured JSON logs (LOG_FORMAT=json)
• Forward to your SIEM or log aggregator
• Monitor the /health endpoint

Rate limits are enforced by this server, not by Attio. A malicious actor with valid credentials could bypass these limits by calling Attio directly.

Before deploying to production:

• Credentials stored in secrets manager (not env files)
• TLS enabled and enforced
• Rate limits tuned for expected load
• Health monitoring configured
• Log aggregation set up
• Incident response plan documented
• Regular credential rotation scheduled

• Attio API Documentation
• OAuth Authentication Guide
• Remote Deployment Guide
• Cloudflare Worker Example