> Source: https://builder.ema.ai/v2/administration/pii-and-governance > Title: PII and Data Governance # PII and Data Governance Ema can detect personally identifiable information (PII) in the content it processes and apply a masking policy before that content is shown to a user or sent to an external model or integration. As a tenant admin you control two things: how detected data **appears** to people inside Ema, and what detected data is **allowed to leave** Ema for LLMs and third-party integrations. These controls live on the **PII Management** tab at `/admin/governance/pii`, alongside the [audit log](/builder/v2/administration/audit-log). > [INFO] > **Enabled per tenant.** PII governance is gated by the `pii_masking` feature flag. When it is off, the PII Management tab is hidden and the Governance page shows only the audit log. If you don't see the tab, the feature isn't turned on for your tenant — contact your Ema representative. > [INFO] > **Who can manage PII policy.** PII governance is a `system_admin` surface. The PII access log is restricted to `system_admin` as well — see [the audit log](/builder/v2/administration/audit-log#pii-access-log). ## How detection works Ema classifies detected data into a fixed taxonomy of **entity types** (for example `EMAIL_ADDRESS`, `US_SOCIAL_SECURITY_NUMBER`, `CREDIT_CARD_NUMBER`, `PERSON_NAME`). Each entity type belongs to one or more categories — financial, credentials, healthcare, personal, government, device, or protected. The taxonomy follows the Google Cloud DLP infoType naming convention (`UPPER_SNAKE_CASE`), which aligns with common compliance references. When PII is detected, Ema can replace it with a stable **pseudonym token** (for example `PERSON_48291037` or `EMAIL_73920156`) that can be reversed back to the original only where policy permits. ## Display levels Each entity type has a **display level** that determines how a detected value is shown to users inside Ema. There are four levels, from most to least restrictive: Level UI label What the user sees Example `full_mask` Fully Masked The value is hidden entirely. — `pseudonym` Pseudonym Only A stable, non-reversible token. `SSN_61038472` `partial` Partial (last 4) A redacted form revealing only a tail or fragment. `***-**-6789` `original` Show Original The cleartext value. `123-45-6789` ### System ceilings Every entity type has a **system maximum** — the most permissive display level you are allowed to choose. You can set a display level at or below the ceiling, never above it. The ceilings are fixed by the platform and reflect regulatory baselines (HIPAA Safe Harbor, PCI DSS, NIST SP 800-122, GDPR, CCPA). For example: - **Secrets and credentials** (passwords, API keys, JWTs, SSH keys) are capped at **Fully Masked** — even a `system_admin` cannot reveal any portion. - **Financial and government identifiers** (SSN, credit card number, passport) are capped at **Partial** — you may reveal the last few digits but never the full value. - **Names and organization names** allow **Show Original** because they are routinely needed in business context. When an entity type's ceiling is Fully Masked, its display control is locked and cannot be changed. ### Setting a display level On the **Display Policy** card, each detected entity type has a dropdown listing only the levels allowed for it (up to its ceiling), each annotated with an example of what the result looks like. Choose a level and it saves immediately. The default display level for most sensitive types is Fully Masked. ## Sharing policy (integration egress) The **Sharing Policy** card controls what detected data is allowed to leave Ema in cleartext for external LLMs and integrations. Each entity type has one of three states: - **Always sent.** A small baseline set of business-context entities is always allowed to egress: `PERSON_NAME`, `EMAIL_ADDRESS`, `ORGANIZATION_NAME`, `PHONE_NUMBER`, `STREET_ADDRESS`, `EMPLOYMENT_INFORMATION`, and `EDUCATION_INFORMATION`. These show a green **Always sent** badge and cannot be toggled. - **Never sent.** Sensitive types — all credentials, financial identifiers, healthcare data, government IDs, device identifiers, and protected attributes — are hard-locked against cleartext egress. They show a red **Never sent** badge and cannot be toggled. When such a value must reach a model, it crosses the boundary as a pseudonym token, never as cleartext. - **Configurable.** Any remaining entity type defaults to **not sent** (tokenized) and can be switched on with a toggle. There is no implicit grant — you opt each one in deliberately. > [WARNING] > **Egress locks are absolute.** Entity types marked Never sent must never cross an external LLM vendor boundary in cleartext, regardless of tenant configuration. This is a platform-level guarantee, not a tenant preference. ## Reference The PII service backs these surfaces. The display-policy dropdowns read and write per-entity overrides; the sharing toggles read and write the tenant egress policy. Action Endpoint List per-entity display overrides `GET /tenant-config` Set an entity's display level `PUT /tenant-config` List egress (sharing) policy rows `GET /tenant-egress-policy` Set an entity's egress allowance `PUT /tenant-egress-policy` Revert an egress row to default `DELETE /tenant-egress-policy` Every PII decision — what was tokenized, partially masked, redacted, or passed through, and at which boundary — is recorded for compliance. See the [PII access log](/builder/v2/administration/audit-log#pii-access-log). ## What's next - [Audit log](/builder/v2/administration/audit-log) — review the PII access log and the full event history. - [Governance and permissions](/builder/v2/administration/governance-and-permissions) — the roles that can manage governance. - [Tenant management and SSO](/builder/v2/administration/tenant-and-sso) — configure model providers that data egresses to.