Topic starter
21/08/2026 4:53 pm
TL;DR: Hiding email, phone numbers, and other personal data in SaaS support workflows reduces unnecessary exposure, supports privacy obligations, and lowers the chance of insider misuse or accidental disclosure, according to Strac. The governance issue is not whether support teams can use data, but how tightly access is scoped when most cases do not require full visibility.
Editorial analysis by NHI Mgmt Group, based on content published by Strac: “How to hide email, phone number, pii data on SaaS apps?”.
Key questions
Q: What breaks when support teams can see full customer PII by default?
A: Default visibility widens the attack and error surface.
Q: Why does PII redaction matter for privacy and access governance?
A: PII redaction matters because it reduces unnecessary data exposure before a person interacts with the record.
Q: What are the signs that support workflows expose too much sensitive data?
A: Common signs include agents seeing complete email addresses, phone numbers, account numbers, or other identifiers in routine cases that should not require them.
Practitioner guidance
- Redesign support views around minimum necessary data Limit agent-visible fields to the smallest set needed for verification, routing, or case resolution.
- Classify support tickets by data sensitivity Separate routine cases from cases that legitimately require raw PII, and require a higher-approval path for the latter.
- Review third-party SaaS support exposure Check Zendesk, Intercom, and similar workflows for hidden copies of personal data, including comments, previews, and integrations that can re-expose what the main screen hides.
Bottom line: Support workflows often reveal more personal data than the case actually requires, which turns everyday service operations into a privacy and access-risk issue.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:11 pm
PII visibility is an access-control problem, not just a privacy preference. If support teams routinely see full customer identifiers, organisations have already expanded the data access boundary beyond operational need. Redaction changes the control point from user behaviour to workflow design. For IAM and privacy programmes, that is a stronger model because it reduces reliance on training alone and makes misuse harder in the first place.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
A question worth separating out:
Q: Should support teams use redaction or masking for sensitive fields?
A: Use the control that matches the task. Redaction is strongest when the agent does not need to see the value at all. Masking is useful when a limited pattern is enough for recognition or verification. The decision should be driven by what the workflow actually requires, not by convenience or habit.
👉 Read our full editorial: Hiding PII in SaaS support workflows reduces access risk