Tool surface does not mention PII
Authored by Stanley Hong · AgentReserve (founder).
No tool name, description or input schema references obvious PII fields (email, phone, ssn, password, …). This is a governance prompt, not a security failure — many legitimate CRM, HR, and support servers handle PII by design and will trip the rule. The intent is to make the PII surface visible during review, not to block it. Treat a fail as 'document data minimization, retention, and access controls', not 'remove the tool'.
When this rule runs
Requires a successful MCP `initialize` / `tools/list`. Skipped on perimeter-only scans where the server refused or failed the MCP handshake.
Why it matters
Tools that handle PII (email, phone, ssn, password, address, …) should be governed individually — both for legal exposure and to prevent agents from leaking user data into untrusted contexts. The low weight reflects that PII handling itself is not a vulnerability; the rule exists to flag the surface for human review.
Pass condition
No tool name, description or schema field references obvious PII keywords.
Fail condition
At least one tool surfaces PII vocabulary.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"matches": [{"toolName": "lookup_user", "keyword": "email", "source": "schema"}]}
Remediation
Where PII handling is required, document the data minimization, retention, and access controls in the tool description; otherwise remove the PII references from the public schema.
Methodology
This rule belongs to the Tool surface risk dimension. What an agent could do if it trusted every advertised tool. Covers destructive actions, credential disclosure, code execution, filesystem mutation, PII handling, prompt-injection-shaped input fields, and injection-bearing tool descriptions — i.e. the agent-specific threat surface, not just generic verb risk.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.