Privacy & PII
How PII masking works, workspace privacy settings, and how to configure unmasked access
The MCP server masks personally identifiable information (PII) by default. This page explains how masking works and how to configure access to unmasked data.
Default behavior
When a tool returns customer data (e.g. explain_customer_journey), PII fields are masked:
| Field | Masked value | Unmasked value |
|---|---|---|
j***@e****.com | [email protected] | |
| Phone | *******5678 (last 4 digits only) | +1 234 567 5678 |
| Name | First name only (Jane) | Full name (Jane Smith) |
This applies automatically -- no configuration needed.
Requesting unmasked data
To see full PII, three conditions must be met simultaneously:
Token scope
Your MCP token must include the mcp:read_pii scope. Create or rotate a token with this scope from Developer > MCP Tokens.
Explicit request
Pass include_sensitive: true in the tool call. The AI tool will do this when you explicitly ask for unmasked data (e.g. "show me the actual email addresses").
Workspace setting
A workspace admin must set the workspace PII mode to full_default in Settings > Privacy & MCP. The default is masked_default.
If any condition is not met, the response is masked and meta.pii_level_applied is set to "masked". No error is returned -- the tool gracefully falls back to masking.
Workspace admin controls
Workspace administrators can configure two MCP-related settings from Settings > Privacy & MCP:
| Setting | Default | Description |
|---|---|---|
| PII mode | masked_default | Controls whether tokens with mcp:read_pii can see full PII |
| Write-back | Disabled | Controls whether tokens with mcp:write can CHANGE the workspace at all — create profiles, install tracking, define conversions, configure Meta CAPI, send conversions. Off means read-only: reads and every write tool's preview still work |
These settings apply to all MCP tokens used to access the workspace, regardless of which user created the token.
One exception to the "Disabled" default. A workspace created by create_workspace (or POST /api/v1/workspaces) through an MCP user token whose grant carries mcp:write starts with write-back already on — the person already consented to writes on the MCP OAuth screen, and is that workspace's only member and owner, so there is no one else's setting to protect. A workspace created from the console, from a connected app, or by a token holding only mcp:read, still starts Disabled. Either way this switch stays reachable only from Settings > Privacy & MCP — an MCP user token can never flip it, on a workspace it just created or any other.
What is logged
MCP tool invocations log metadata only:
- Tool name, duration, status code, units debited
- Workspace ID, profile ID, request ID
- Record count, PII level applied
Raw tool arguments, response data, and PII are never logged. The request_id in every response can be used for support inquiries without exposing sensitive data.