Context
Dogfooding the Claude Code hook (datafog-hook via the datafog-claude-plugin) in a real agent session: browser-automation MCP tools return JSON like
{"availableTabs":[{"tabId":<9-digit int>,"title":"New Tab"}],"tabGroupId":<10-digit int>}(Literal values redacted here because — fittingly — the hook blocked this issue from being filed with the real examples in the body.)
The PostToolUse scan flags these numeric IDs as SSN x2 / PHONE x1 on nearly every tool call in the session. Any bare 9-digit integer apparently matches the SSN pattern (and 10-digit ones match PHONE), so sessions that touch tab IDs, database row IDs, epoch timestamps, ticket numbers, etc. get a constant stream of advisory warnings — which trains users to ignore the hook entirely.
Observed
PostToolUse advisory context repeatedly reported SSN x2, PHONE x1 for MCP tool results whose only numeric content was tabId/tabGroupId values.- The warnings fired on ~every browser tool call in a session, drowning out one legitimate catch (real placeholder PII in a README).
PreToolUse in ask/deny mode hard-blocked a gh issue create command whose body merely described the pattern with redacted-but-9-digit example numbers.
Ideas (not prescriptive)
- Require SSN candidates to be delimited (
NNN-NN-NNNN or NNN NN NNNN) rather than matching bare 9-digit integers, or at minimum apply SSN structural validation (area/group/serial ranges — e.g. area 000/666/9xx are invalid).
- In structured (JSON) tool output, skip values whose keys match an ignorelist of obvious machine-ID names (
*id, *Id, timestamp, port, ...).
- Consider a confidence tier: bare-integer matches downgraded to opt-in via
DATAFOG_HOOK_ENTITIES.
Precision is the product here — the high-precision default entity set is the right call, but bare-integer SSN/PHONE matches undercut it in exactly the agent-session context the hook targets.
Context
Dogfooding the Claude Code hook (
datafog-hookvia the datafog-claude-plugin) in a real agent session: browser-automation MCP tools return JSON like{"availableTabs":[{"tabId":<9-digit int>,"title":"New Tab"}],"tabGroupId":<10-digit int>}(Literal values redacted here because — fittingly — the hook blocked this issue from being filed with the real examples in the body.)
The PostToolUse scan flags these numeric IDs as
SSN x2/PHONE x1on nearly every tool call in the session. Any bare 9-digit integer apparently matches the SSN pattern (and 10-digit ones match PHONE), so sessions that touch tab IDs, database row IDs, epoch timestamps, ticket numbers, etc. get a constant stream of advisory warnings — which trains users to ignore the hook entirely.Observed
PostToolUseadvisory context repeatedly reportedSSN x2,PHONE x1for MCP tool results whose only numeric content wastabId/tabGroupIdvalues.PreToolUseinask/denymode hard-blocked agh issue createcommand whose body merely described the pattern with redacted-but-9-digit example numbers.Ideas (not prescriptive)
NNN-NN-NNNNorNNN NN NNNN) rather than matching bare 9-digit integers, or at minimum apply SSN structural validation (area/group/serial ranges — e.g. area 000/666/9xx are invalid).*id,*Id,timestamp,port, ...).DATAFOG_HOOK_ENTITIES.Precision is the product here — the high-precision default entity set is the right call, but bare-integer SSN/PHONE matches undercut it in exactly the agent-session context the hook targets.