This guide provides an overview of how sensitive data is handled on the Meya platform.
To set up the Sensitive Data integration, check out the Sensitive Data integration page.
Imagine a user requests to be transferred to an agent. Let’s take a look at what will happen to their sensitive data throughout the conversation.
In this example, the user’s email address has been marked as sensitive data, which is why it is encrypted while the
When the chat is transferred to the agent, all of the data is considered sensitive (which is the default behaviour when
agent) and is encrypted.
Want to know how to access encrypted, decrypted, and redacted versions of sensitive data from your app code? Check out this guide:
Here’s an overview of the encryption/decryption process.
Data Encryption Key (DEK): A key designed to encrypt and decrypt data. The same symmetric DEK that encrypted the data must be used to decrypt it. When the DEK is expired or destroyed, the data can no longer be decrypted. On the Meya platform, DEKs are unique to each piece of sensitive data.
Key Encryption Key (KEK): A key that is used for encrypting and decrypting other keys. Two types of KEKs are generated by the Meya platform for sensitive data:
- the app KEK, which is unique per app and cycles every 24 hours, and
- the ref KEK, which is unique per piece of sensitive data.
Time-To-Live (TTL): The period during which the sensitive data is valid. After the TTL has expired, the sensitive data is only available in redacted (★★★★★) form.
- app KEKs have a TTL of 24 hours
- sensitive data has a TTL of 24 hours
- Data flagged as sensitive is given a TTL which, by default, is 24 hours.
- A unique ref KEK is generated for the data, along with an ref ID that can be used to find the sensitive data later for decryption.
- A unique DEK is generated for the data.
- The data is encrypted with the DEK.
- The DEK is encrypted with the ref KEK, and then again encrypted with the app KEK.
- The encrypted data and encrypted DEK are stored using the ref ID and the TTL.
- The ref KEK and ref ID can now be used for future decryption.
- The ref KEK and ref ID are extracted.
- The encrypted data and encrypted DEK are retrieved from storage using the ref ID.
- The DEK is decrypted first using the app KEK, then decrypted again using the ref KEK.
- The sensitive data is decrypted using the DEK.
Entries can have certain fields flagged as sensitive. For example, the meya.text.event.say entry has the
text field flagged as sensitive. Sensitive fields are encrypted if the entry itself is flagged as sensitive.
In order to enable encryption, the sensitive data integration needs to be added to your app.
Assuming that the Sensitive Data integration is enabled and has
transcript: true (the default), the
result field of the
Response class will be encrypted since the component’s
sensitive property is
True by default:
When the Sensitive Data integration file has
transport: true (the default), all HTTP and WS entries are flagged as sensitive and are encrypted.
When the Sensitive Data integration file has
transcript: true (the default), events can either be flagged as
sensitive: true or
sensitive: false based on the
thread.mode, and based on the event user’s type.
bot mode is not considered sensitive; anything else (e.g.
prechat) is and will be encrypted. The
system user types are considered sensitive.
Sensitive data is encrypted and stored for a duration that dependent on the type of entry. See the table below:
|event||24 hours||Covers conversation transcript. For example, say events from user, bot or agent as well as events like button clicks and form submission.|
|bot||1 hour||Flow execution.|
|http||1 hour||Http payloads.|
|ws||1 hour||Websocket payloads (similar to http).|
|log||1 hour||Log messages.|
|presence||1 hour||Typing indicators, etc.|
|thread||1 hour||Thread scope write entries, but the thread data itself persists indefinitely.|
|user||1 hour||User scope write entries, but the user data itself persists indefinitely.|
|blob||24 hours||Used for media storage (files, images, video, etc.).|
Data marked as sensitive CANNOT be decrypted after the TTL expires. It will only be available in its redacted form.
Sensitive data is automatically detected and encrypted at the incoming edge of integrations, based on the rules outlined above.
Sensitive data is auto-decrypted at the outgoing edge of integrations only when that integration has been flagged to process sensitive data.
- Messaging integrations will always process sensitive data.
- Customer support integrations will always process sensitive data.
- Other integrations require a manual override in order to decrypt sensitive data.
- Authorized developers (typically admins) can view sensitive data on the Logs page of the Console until the sensitive data TTL expires:
When the sensitive data’s TTL expires, the encrypted data and encrypted DEK are deleted. Trying to decrypt expired sensitive data always results in the redacted form: ★★★★★
Sensitive data can be used by your app, in its encrypted form or (until the TTL expires) in its decrypted form. For example, you can copy encrypted sensitive data from an original event to flow scope, thread scope, or user scope, or you can pass decrypted sensitive data to a component for processing.
Be careful when handling sensitive data in BFML or Python. If you decrypt sensitive data, you need to make sure you aren’t logging it or using it for other non-sensitive entries. Also avoid decrypting then re-encrypting sensitive data, because this will extend the built-in TTL.
Updated 2 months ago