> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://developers.alephant.io/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developers.alephant.io/_mcp/server. # Privacy Dictionary > Maintain organization-level sensitive entity rules for masking, local routing, blocking, and review before model calls. The Privacy Dictionary lets administrators define sensitive business entities that AIvis should detect before chat, Agent, and model requests leave the trusted deployment boundary. Use it for organization-specific identifiers such as customers, projects, code names, regulated records, or confidential terms that generic detectors may not know. The page is available in the administrator configuration area at **Admin > Configuration > Privacy Dictionary**. Entries created there are drafts until they are published into a dictionary version. Runtime protection uses the latest published version, so unfinished drafts do not affect active sessions. ## Capability Boundary | Area | Guidance | | ------------------ | ---------------------------------------------------------------------------------------------------------------- | | Organization rules | Define sensitive entities, aliases, and actions that apply across the current organization. | | Model requests | Apply dictionary rules before approved model providers receive request content. | | Private deployment | Keep source values and dictionary drafts inside the enterprise-controlled deployment. | | Review state | Treat review-required entries as a policy signal; do not assume every deployment has a user-facing preview step. | ## Entry Fields | Field | Description | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Entity ID | Stable administrator-defined identifier, such as `customer_alpha` or `project_mercury`. Use a value that can survive renames. | | Entity type | Category used for reporting and replacement labels, such as organization, project, person, location, email, mobile number, or credential type. | | Sensitive value | Canonical value to detect. The value remains masked by default outside the edit form. | | Aliases | Alternate names or abbreviations that should match the same entity. Separate aliases deliberately to avoid broad matches. | | Action | Runtime handling strategy for matches. Choose the least permissive action that still supports the business workflow. | | Scope | Current public documentation covers organization-wide entries. If a deployment exposes narrower scopes, confirm the runtime contract before relying on them. | ## Actions | Action | What it does | Use when | | ------------------------ | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Tokenize | Replaces the value with a stable privacy placeholder, preserving that repeated mentions refer to the same entity. | The model needs consistency but not the original value, such as customer names, project codes, email addresses, or account identifiers. | | Generalize | Replaces the value with a category label and does not preserve a reversible mapping. | The model only needs the entity category, such as organization, location, person, or project. | | Local only | Prevents external processing and allows the request only when a compliant local route is available. | The content may be processed by an approved local model or local service, but must not leave the deployment boundary. | | Block | Stops the request when the entity is present. | The value must not be processed, even locally, or the risk outweighs the workflow benefit. | | Allow after confirmation | Marks the request as requiring review before it can continue. | The business case may justify processing, but a human or policy-controlled review step should decide. | ## Runtime Flow | Stage | Behavior | | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Draft | Administrators create or edit entries without affecting runtime behavior. Sensitive values are visible only in the active form or reveal window. | | Publish | Approved drafts are published into an immutable dictionary version. The version becomes the runtime contract for future checks. | | Detect | AIvis scans outgoing model-request content for published values and aliases. | | Decide | The most restrictive matching action controls whether content is tokenized, generalized, routed locally, blocked, or marked for review. | | Send | External providers receive only the sanitized payload when the decision allows external processing. Blocked or unavailable local-only requests do not continue. | ## Recommended Actions by Data Type | Data Type | Recommended Action | Reason | | --------------------------------------------------------------------- | ------------------------ | -------------------------------------------------------------------------------------------------- | | Customer, vendor, or project code name | Tokenize | Preserves repeated references without exposing the original value. | | Organization, person, or location where exact identity is unnecessary | Generalize | Keeps enough context for reasoning while reducing disclosure. | | Password, private key, connection string, or production credential | Block | These values should not be sent to a model or handled as ordinary prompt context. | | Regulated record that may be processed only in the private deployment | Local only | Keeps processing inside a compliant local route when available. | | Borderline business content needing case-by-case approval | Allow after confirmation | Gives administrators a review policy signal instead of automatically allowing external processing. | ## Operating Practices * Use stable entity IDs that do not include the sensitive value itself. * Keep aliases narrow. Very broad aliases can over-match and block unrelated work. * Prefer Tokenize for business terms that the model needs to track across a conversation. * Prefer Generalize when exact identity does not matter. * Use Block for secrets and values that should never appear in prompt context. * Publish small batches and verify the resulting dictionary version before broad rollout. * Revisit inactive or retired entries during privacy reviews. ## Verification Before relying on dictionary rules in production: * Create a draft entry and confirm the sensitive value remains hidden after closing the form. * Publish the draft and confirm the current dictionary version increases. * Send a test chat that contains the canonical value and an alias. * Confirm the model response does not reveal the raw sensitive value. * Test one Tokenize entry and confirm repeated mentions remain coherent. * Test one Generalize entry and confirm the response uses category-level context. * Test Local only and Block entries with the deployment's configured model routes. * Review tracing, query history, or administrator logs according to your deployment policy. ## Troubleshooting | Symptom | Likely Cause | Resolution | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | A new entry does not affect chats | The entry is still a draft or the session started before the published version was available. | Publish the draft, start a new session, and verify the active dictionary version. | | Too many requests are blocked | The canonical value or alias is too broad, or Block was chosen where Tokenize or Generalize would be sufficient. | Narrow aliases and choose the least permissive action that still supports the workflow. | | A sensitive term is not detected | The term is missing as an alias, uses another spelling, or was added after the last published version. | Add the alias, publish a new version, and test with the exact spelling users use. | | Local only requests are blocked | No compliant local processing route is available for the selected model configuration. | Configure a local route or change the entry action to Block if local processing is not approved. | | Review-required requests do not show a preview step | The deployment may treat review-required as a policy state without exposing an interactive confirmation workflow. | Confirm the deployed review workflow before using this action for user-facing approvals. | ## Related Pages * [Chat Preferences](/aivis/features/chat-preferences) * [Language Models](/aivis/models/language-models) * [Model Credentials](/aivis/models/model-credentials) * [Data Flows](/aivis/governance/data-flows) * [Security](/aivis/governance/security)