Redacting Personally Identifiable Information

Back to App Settings Personally identifiable information (PII) or sensitive personal information (SPI) refers to information that can be used alone or in conjunction with other information to identify, contact, or locate a single person. Examples include Social Security Numbers, email addresses, credit card numbers, card verification values (CVV), passport numbers, and home addresses. The platform allows you to redact any sensitive information that users share with your AI Agent. When you enable redaction for an information type, you can transform its value into a pattern that doesn’t contain comprehensible data. The platform redacts any end-user input that matches the PII pattern in the context object, chat logs, chat history, and other places to protect sensitive data. The original values are stored in a secure vault and can be used in the following scenarios:

If a PII value is used in Dialog Task transitions, the platform automatically uses the original value for transition-condition evaluation (for example, validating the entity value’s format, such as whether it’s a valid number).
If a PII value is used in the Service Node definition, the platform uses the redacted value by default to make service calls. However, you can send the original data for scenarios such as passing it to a backend system. Select the appropriate option while configuring the Service Node.
You may use the Redaction of PII Data configuration of the Entity Nodes to present the original values of a redacted entity to users for confirmation. Select the appropriate option while configuring the Entity Node.
You may use the Redaction of PII Data configuration of the Agent Nodes to present the original values of a redacted entity to users for confirmation. Select the appropriate option while configuring the Agent Node.

The ‘Redaction of PII Data’ option selected at the node level only affects those instances during runtime or live interaction. PII data is always redacted/masked in chat history and internal logs, irrespective of the option selected at the node level.

The platform provides three modes to redact specified information types:

Option	Description	Example
Redaction	Replaces the data with a unique random alphanumeric value	An email address gets replaced with a random value such as jjh4ezb2
Replacement	Replaces the data with a static value that you enter in the PII Redaction settings	If the static value entered is asdf1234, any email address entered is replaced with asdf1234
Mask with Character	Replaces the first few and last few characters of the data with `+` or `#` symbols. You can select the number of characters to mask and the symbol for masking.	If you configure the first four and last four characters to be masked with `+`, an email address such as helpdocs@kore.ai gets redacted as ++++docs@kor++++

How to Redact

Open the App for which you want to configure PII settings.
Navigate to App Settings > Advanced Settings > PII Settings.
The PII Redaction page opens.
If PII Redaction isn’t enabled for the app, toggle the switch to Yes. The page now shows a list of information types whose redaction settings are configured by default.
To activate redaction for any out-of-the-box information type, toggle the switch next to it to Enable. To edit redaction settings, click the information type name.
To configure redaction settings for other information types, click Add New in the top-right corner of the PII Redaction page.

Configuration Fields

Field	Description
Information Type	Enter a name for the information type you want to secure, for example, Credit Card Number.
Definition	Enter a regular expression for recognizing the information type from user entries. For example, a regex for a Visa credit card could be `^4[0-9]{12}(?:[0-9]{3})?$`
Map Entities	Map all the entities in the app’s Dialog tasks that correspond to the information type. Note: If you don’t map entities corresponding to redacted information types, even valid user entries for those entities cause errors in the dialog tasks. For example, if redaction is enabled for the email information type and a user enters an email address, the platform redacts it before the entity node captures it. The entity node receives redacted data and, since the entity isn’t mapped in the redaction settings, treats the redacted value as an invalid email entry. Mapping the entity in the redaction settings allows the entity to recognize the redacted data and accept it.
Display Type	Select one of these modes to display the redacted data anywhere in the platform: Redaction, Replacement, Mask with Character. Note: The displayed value is prefixed with a platform-generated random unique identifier, which is the key used internally to retrieve the original value for conditional transitions.
Access to Original Value	It controls whether end users can view original PII values. It’s enabled by default at the Node Level. Yes: End users can view the original value. - Global Level: Applied across all Agent and Entity nodes automatically; no additional configuration needed. - Node Level (default): Configured per Agent and Entity node; requires manual setup at each node. No: End users see only masked or redacted values.

Configure Contextual Sensitive Data

The Platform allows you to secure sensitive data input during a conversation. Enabling sensitive data redaction and using custom regex patterns to identify and secure sensitive information is an effective approach. Enable the Sensitive Entity settings at the Entity Node to secure sensitive user input such as PINs or OTPs (typically 4 to 6-digit numbers). These values must not be stored in plain text in conversation logs or chat history. Redacting or masking at the entity node level prevents plain-text storage, reducing the risk of unauthorized access or misuse. Custom regex patterns allow the AI Agent to identify and handle sensitive information based on conversation context, balancing conversational functionality with data security.

Sensitive Data Use Case Scenarios

Scenario 1: String patterns for sensitive data conflict or overlap in different contexts. For example, a password is 6-8 digits, and a phone number (TPN) is 9 to 12 digits long. In TPN cases, a user may miss typing a digit or two. Due to the password PII pattern of 6-8 digits, the TPN gets masked as if it’s a password, and TPN entity recognition fails. Enabling the Sensitive Entity setting redacts and replaces contextually sensitive data to resolve this conflict. Scenario 2: A customer tries to change their password by interacting with the AI Agent. Passwords are sensitive and must be secured everywhere. However, defining a PII pattern for passwords may mask or redact other inputs that match the same pattern.

PII vs. Sensitive Entity

Personally Identifiable Information: Identifies and redacts or masks sensitive data in common PII categories, such as Social Security Numbers, email addresses, or credit card numbers. Provides a broad, predefined set of sensitive data patterns detected and handled uniformly across the entire conversation.
Sensitive Entity: Provides fine-grained control and customization of redaction or replacement actions based on specific sensitive data contextual conditions. Enables you to define rules specific to your use case, where the same sensitive data pattern may require different handling depending on context.

Sensitive nodes are needed when overlapping or conflicting string patterns require different treatment in different contexts. Configuring sensitive nodes ensures the platform correctly recognizes and handles sensitive data even when it matches multiple patterns. For example, in the TPN/password scenario, the sensitive entity option lets you define a context-specific rule that identifies TPNs and applies the appropriate redaction or replacement action, even if the same pattern matches a password in a different context. The Sensitive Entity option provides flexibility in managing sensitive data within specific conversation flows, allowing you to tailor behavior to your use case. Both PII and Sensitive Entity complement each other in providing comprehensive protection for sensitive data. PII offers broad coverage for common patterns; Sensitive Entity handles sensitive data in a more granular and contextually aware manner. Leverage both features together for comprehensive protection throughout your conversations. For more information, see the Entity Node article.

Anonymize Sensitive Data in LLM Interactions

The platform enables you to define sensitive information and its handling before sending it to large language models (LLMs). To learn more, see Data Anonymization.

Reuse Sensitive Entities Across Dialogs

When PII redaction is enabled, the platform protects sensitive information— such as phone numbers, email addresses, and credit card numbers — by redacting the values when users provide them. You can reuse sensitive entity values across dialogs within the same session by storing their associated PII tokens in the botUserSession.piiEntities namespace using a Script node. When a supported node or response references a stored PII token, the platform automatically resolves it to the original value. This allows multiple dialogs to use the same sensitive information without asking users to provide it again. For example, a user starts a registration dialog and provides a phone number. The bot captures the phone number as a sensitive entity and stores its associated PII token in botUserSession.piiEntities. Later in the same session, the user starts an OTP verification dialog. Instead of asking for the phone number again, the bot references the stored PII token. The platform automatically resolves the token to the original phone number and sends the verification code. The user completes the verification without re-entering the phone number, while the platform continues to protect the sensitive data throughout the session. Prerequisites

Enable PII capture at both the global and node levels.
Define the required sensitive entities in the Script node before storing their associated PII tokens in botUserSession.piiEntities.

How it works

Capture a sensitive entity in a Script node.
Store the entity’s associated PII token in botUserSession.piiEntities.
Reference the stored PII token from another dialog in the same session.
The platform automatically resolves the PII token to the original value when a supported node or response references it.
The platform removes stored PII tokens when the session ends or when the configured PII retention period expires.

​How to Redact

​Configuration Fields

​Configure Contextual Sensitive Data

​Sensitive Data Use Case Scenarios

​PII vs. Sensitive Entity

​Anonymize Sensitive Data in LLM Interactions

​Reuse Sensitive Entities Across Dialogs

​How it works

How to Redact

Configuration Fields

Configure Contextual Sensitive Data

Sensitive Data Use Case Scenarios

PII vs. Sensitive Entity

Anonymize Sensitive Data in LLM Interactions

Reuse Sensitive Entities Across Dialogs

How it works