Three access reports return identities as IDs only

Three access reports return identities as IDs only

Plans: The Seed and above (backend 2.5.14). Where: the /mcp endpoint — uar_status, access_normalization_health, access_anomaly_discovery

Every MCP result is masked by field name before it leaves the server. Three of the original access reports carried a person’s identity under a field the mask did not cover, so an mcp:read token could read it without pii:read:

• uar_status → overdueItems[].subjectName (the account name as the connected system reported it) and reviewerName;
• access_normalization_health → lowConfidenceItems[].rawName;
• access_anomaly_discovery → items[].description, a sentence that embedded the account name and email.

What changed

The three tools now return a projected item, in the same envelope as before:

The removed fields are gone from the wire, not blanked: subjectName, reviewerName, reviewerEmail, rawName, rawEmail, description, name and email no longer appear in these results. Counts, buckets and per-asset breakdowns are unchanged. A pii:read token resolves any of the returned employee IDs to a name with employee_resolve, which records the lookup in the audit trail.

The console pages behind these reports are not affected — they still show names to signed-in users with the right role.

If you integrate with these tools

• Read the identity from subjectEmployeeId / suggestedEmployeeId / employeeId. An item without one is an account the matcher could not attribute to an employee — that is itself the finding for a ghost-account review.
• Drop any parsing of description; type and severity carry the classification.
• The TypeScript and Python SDKs regenerate from the manifest; the tool descriptions now state what each item carries.