PII Access Control
Overview
Zyphe applies role-based access control (RBAC) to Personally Identifiable Information (PII) so that sensitive customer data is only visible to the people who need it. This page explains the principles behind that model. For the concrete roles and the exact permission matrix (who can do what in the dashboard and API), see Manage Users.
Problem statement
In many KYC/KYB systems, everyone with dashboard access can see every customer's PII. That creates avoidable risk:
- Insider threat: internal actors with legitimate access can exfiltrate large volumes of sensitive data.
- Over-privileged access: people with no need to view PII can see it anyway.
- Compliance risk: broad access makes data-minimization obligations under GDPR, CCPA, and similar regimes hard to meet.
- Weak audit trail: without granular controls it is difficult to reconstruct who accessed what, and when.
How Zyphe reduces PII exposure
Zyphe addresses this on two fronts:
- Decentralized storage. PII lives in the user's own vault, not in a central Zyphe database. Only the minimum attributes required for a given operation are read, and every access is recorded in a hash-chained audit trail. See Decentralized Identity and Why decentralized PII storage.
- Role-based access. Within your organization, what each member can see and do is governed by their role. Roles are least-privilege by default: a member is granted the narrowest set of permissions that lets them do their job, and elevated access is the exception rather than the rule.
Roles
Access is governed by the organization roles Zyphe enforces today:
| Role | Typical use |
|---|---|
| Admin | Organizational management and oversight; full access. |
| Operator | Reviewing and operating on verification results and AML cases. |
| AML Officer | AML monitoring and case management. |
| Developer | Integration work, flows, API keys, webhooks. |
| Partner | External collaborators, limited to flows explicitly shared with them. |
The authoritative, per-permission breakdown of these roles, including what each can access and how partner flow access is granted, is maintained in Manage Users. Treat that page as the single source of truth; this page covers only the principles.
:::info Least privilege in practice Default new members to the lowest role that lets them work, review elevated roles periodically, and keep the number of full-access accounts small. Grant broader access deliberately, not by default. :::
Webhooks and PII
Webhook payloads respect your organization's PII configuration. You can choose how much a webhook carries:
- No PII (recommended): the webhook signals that a result is ready; PII is fetched separately, subject to role permissions.
- Identifier only: the webhook includes a session/result identifier and nothing sensitive.
- PII included: only for organizations that explicitly opt in and accept the added handling responsibility.
See Webhooks for delivery and payload details.
Best practices
For organizations
- Assign full-access (Admin) roles sparingly and secure those credentials with strong authentication.
- Review who holds elevated roles on a regular cadence.
- Monitor for unusual access patterns.
- Default to the least-privileged role and grant more only when there is a demonstrated need.
For developers
- Never cache PII in client-side storage or logs.
- Check access on every request rather than assuming it from a previous one.
- Handle missing PII gracefully, your UI should work when PII fields are absent for the current role.
- Test your integration against every role your users may have.
Support
For questions about PII access control, contact support@zyphe.com.