← All rules

mcp-scan rule

PII handling

data-controls-piicritical

What mcp-scan saw

Two detectors feed this. PII_PATTERNS regexes run over the whole serialized server config (email, phone with a 2-9 area code, Luhn-valid card, SSN, public IPv4, IBAN, IPv6, MAC, UK NINO), and a keyword table runs over descriptive text only: server name, server description, schema description, and every tool name and tool description. Severity is HIGH by default and CRITICAL when the detected set contains Credit Card, SSN, Password, or API Key.

Why it fires

This is the gate rule for the whole data-controls family. When it fires, the scanner then runs the consent, retention, deletion, encryption, and minimization checks against the same server, so one PII hit can produce five findings. It is graded on what the config claims to touch, because a config is all the scanner has: it never connects to the server or reads live traffic.

When this is a false positive

  • The API Key keyword regex matches api_key, api-key, access_token, auth_token, bearer_token, and refresh_token in any tool description. Documenting an authentication parameter is enough to push this to CRITICAL, even when no personal data is ever handled.
  • The Email keyword matches the bare word 'email' in a tool name. Any mail-adjacent server (send_email, list_emails) is labeled a PII processor before a single address exists.
  • The Email PII regex runs over the serialized config, so a support address in a description field, or a maintainer address in a schema, counts the same as a stored user record.
  • The Password keyword matches the word 'password' in a description, which is exactly what a credential-manager server would say about the thing it deliberately never exposes.

How to fix it

  1. Read the finding text. It lists every detected category by name, which tells you whether the hit came from a real value or from a word in a description.
  2. If it came from a description, decide whether the wording is accurate. Renaming a parameter from api_key to credential_ref removes the keyword hit and is usually the honest description anyway.
  3. If it came from a real value in the config (an address, an IP, a card-shaped number), move that value out of the config into an env var reference.
  4. If the server genuinely handles PII, treat the four gap findings that follow as the actual work list rather than dismissing them.
  5. To mask values instead of removing them, set privacy.maskPii to true in .mcp-scan.json so reports carry the masked form.
  6. To suppress, add 'data-controls-pii' to suppressRules in .mcp-scan.json. Note this also silences the consent, retention, deletion, encryption, and minimization checks, since they only run when this one fires.