Platform
Shield Platform Encryption: what breaks, and why your agent still sees it
Shield Platform Encryption protects data at rest. It is not masking and not access control, so the users and the agents allowed to read a field still see plaintext. Here is the filtering you lose when you turn it on, why encryption on a CRM field does not follow it into Data 360, and why the Trust Layer won't hide it from an Agentforce agent.
Compliance says to encrypt the national ID field, so you do. On Monday, a report that filtered on it returns nothing, and no error explains why. The filter stopped matching the moment the field went encrypted.
Shield Platform Encryption protects data at rest, which is a genuine control against a stolen disk or a breach below the application layer. The trap is assuming it does more than that.
Encryption here is not masking and not access control, so every user and every agent allowed to read a field still sees the plaintext. The real work is choosing where you can afford to lose filtering, and knowing that encrypting a CRM field does not carry that protection into Data 360 or past the Trust Layer to your agent.
I’ll go through the one idea most teams get wrong first, then the filtering you trade away, then the two places people assume encryption reaches and it doesn’t: Data 360 and Agentforce.
Encryption is not masking, and not access control
Shield encrypts the bytes on disk and in the search index. It does nothing to who can read the field in the app. A user with field-level read access sees the decrypted value exactly as they would without encryption, and so does an integration user, and so does an agent running as a permissioned user.
This surprises people because of an old permission. “View Encrypted Data” used to govern whether a user saw unmasked values, but that stopped being true back in Spring ‘17. Today field-level security, page layouts, and sharing decide who sees a value; encryption decides only how it rests on disk.
If your goal is to stop a support rep from reading a card number, encryption is the wrong tool. You want FLS, or classic data masking in sandboxes, or the Trust Layer, depending on where the exposure is.
Keep this straight and the rest of Shield makes sense. Encryption answers “what if someone bypasses Salesforce and reads the storage directly.” It does not answer “who inside Salesforce can see this.”
One naming note. The free, built-in option is Classic Encryption, a separate “Encrypted Text” custom field type capped at 175 characters on AES-128, and it can’t be used in formulas, workflow criteria, or default values.
Shield Platform Encryption is the paid add-on on AES-256 that encrypts standard fields, many custom field types, files, and the search index, and it ships alongside Event Monitoring and Field Audit Trail in the Shield bundle. The 175-character cap is a Classic limit, not a Shield one.
Probabilistic or deterministic, and the filtering you lose
Shield has two encryption schemes, and the choice between them is the single most consequential decision in a rollout.
Probabilistic is the default and the more secure one. The same plaintext encrypts to a different ciphertext every time, so there is nothing stable to match against. A probabilistically encrypted field can’t appear in a SOQL WHERE, GROUP BY, ORDER BY, or an aggregate. It is for data you store and display but never filter on.
Deterministic trades a little secrecy for the ability to filter. The same plaintext always encrypts to the same ciphertext, so exact-match queries work.
| Probabilistic | Deterministic | |
|---|---|---|
| Same value, same ciphertext | No | Yes |
WHERE filter | Not supported | Exact match only (=, <>) |
ORDER BY, GROUP BY, LIKE, aggregates | Not supported | Not supported |
| Relative security | Higher | Lower |
Deterministic buys you exact-match filtering on non-formula fields, plus compatibility with unique and external-ID fields and single-column indexes. It does not buy you sorting, grouping, partial match with LIKE or starts-with, or aggregates.
If you need case-insensitive matching, Salesforce stores a lowercase shadow copy of the field, which consumes one of your org’s custom field slots per encrypted field. A compound field like a full name is only queryable column by column, because the ciphertext of the whole is not the concatenation of the parts.
The design rule that falls out of this: encrypt probabilistically by default, and reserve deterministic for the specific fields you must filter on, knowing each one still loses sort, group, and partial match.
What you can’t encrypt, and what stops working
Some field types are off the table. Currency, Number, Formula, Reference, and auto-number fields can’t be encrypted, and the roll-up summaries built on currency and number fields are protected as a result. Field-Level Encryption covers Email, Phone, Text, the Text Area types, URL, Date, and Date/Time among custom fields, and the search index and files besides.
Turning encryption on a field also changes features that read it:
- Matching and duplicate rules degrade. Custom matching rules work only with deterministic encryption, standard matching rules containing an encrypted field stop detecting duplicates, and the matching service searches fewer candidate records than its usual 200. Rotate a key and you have to deactivate and reactivate the affected rules.
- Criteria-based sharing rules can’t reference an encrypted field.
- Encrypted fields can’t be the key in an external lookup relationship.
- A formula that references encrypted data renders only in Salesforce Classic, not in Lightning Experience and not through SOQL.
- Ciphertext is longer than plaintext, so each field type has a reduced effective length. Test your longest values and your non-ASCII data before you trust the field in production.
None of these throw a loud error. A duplicate rule that no longer catches duplicates looks exactly like a quiet success, which is why a full-copy sandbox test pass matters more here than almost anywhere else.
Data 360 is a separate encryption boundary
Here is the gap that catches data teams. Encrypting a field in CRM with Shield does not mean that field arrives encrypted in Data 360.
The two are separate features with separate keys. Shield Platform Encryption protects CRM data at rest.
Data 360 has its own at-rest encryption, with a Salesforce-managed key by default, and a distinct paid capability, Platform Encryption for Data 360, that lets you hold a customer-managed root key over the keys that protect the data lake, vector search indexes included. Enabling one does not enable the other.
Salesforce’s documentation is clear on those two features and noticeably silent on the seam between them. I could not find an official statement of what happens to a Shield-encrypted CRM field when the connector ingests it into Data 360: whether it lands encrypted, decrypted, or masked, and how identity resolution and segmentation treat a formerly encrypted field. So I won’t assert one.
What the architecture implies, and what I’d verify in your own org first: a connector reads CRM as an authorized integration user, so it reads the plaintext, the same way CRM Analytics reads encrypted data and then stores its own copy under its own key. The landed copy in Data 360 is protected only if you have separately enabled Platform Encryption for Data 360 on that store.
Treat Shield-on-CRM and encryption-in-Data-360 as two decisions, not one. If a regulator needs the field encrypted everywhere it lives, plan to turn on both and test a sample record end to end. When you unify CRM and external data into one governed profile, design the encryption story across that boundary rather than inheriting it across.
Your agent still reads it
The second place encryption doesn’t reach is the model. An Agentforce agent that grounds on a record reads the same decrypted value a permissioned user would, because grounding respects the running user’s access and encryption never hid the value from authorized readers.
You might expect the Einstein Trust Layer to catch it. The Trust Layer can mask sensitive data in a prompt before it reaches the LLM, and its field-based masking even reads field classification metadata, including fields you’ve tagged through Shield, to decide what to mask. For many generative features, that works.
For agents it does not. Salesforce documents that LLM data masking, both pattern-based and field-based, is disabled for Agentforce agent actions.
The same prompt template that masks when used directly in a feature like service replies does not mask when an agent action runs it. So the control that governs what an agent exposes is not encryption and not Trust Layer masking: it is field-level security and the permissions of the user the agent runs as.
The practical consequence is a governance one. If a field is sensitive enough to encrypt, it is sensitive enough that you should decide, deliberately, whether the agent’s running user can read it at all. Encryption will not make that decision for you, and for agent actions, neither will the Trust Layer.
The operational reality
A few mechanics decide whether a rollout is smooth or a weekend incident.
Enabling encryption does not encrypt the data already in the field. New and updated records get encrypted going forward, and to encrypt the back catalogue you run the background encryption service from the Encryption Statistics and Data Sync page, or touch the records.
Rotating a key doesn’t re-encrypt existing data either, so old records stay under the previous key until they’re synced. You can generate a new tenant secret about once a day in production, and more often in a sandbox.
Disabling is the dangerous direction. Turning encryption off a field kicks off an automatic mass decryption, and long text and rich text fields can’t be auto-decrypted. Destroy key material with no backup and the data under it is gone for good.
A deployment or package can carry at most 80 encrypted fields at once, so large rollouts deploy in waves. A sandbox refreshed from production inherits the production encryption settings and tenant secrets, which is convenient and also means your sandbox holds real keys.
Treat Shield as what it is: a control for data at rest, chosen field by field, with filtering traded away deterministically where you need it and given up entirely where you don’t.
Encrypt for the threat it addresses, decide separately who and what can read the plaintext, and design the Data 360 and agent layers as their own encryption and access problems. Do that and encryption goes back to being the boring, load-bearing control it should be, instead of the thing that silently broke a report.
Understanding the basics
Does Shield Platform Encryption hide data from users?
No. Shield encrypts data at rest, so it protects against someone reading the storage layer directly, but any user with field-level read access sees the decrypted value in the app exactly as before. Encryption is not masking or access control. Who can see a field is governed by field-level security, page layouts, and sharing, not by encryption, and the old “View Encrypted Data” permission stopped controlling visibility in Spring ‘17.
What is the difference between probabilistic and deterministic encryption in Salesforce?
Probabilistic encryption, the default, produces a different ciphertext each time, which is more secure but means the field can’t be used in SOQL WHERE, ORDER BY, GROUP BY, or aggregates. Deterministic encryption produces the same ciphertext for the same value, which enables exact-match (= and <>) filtering on non-formula fields, but still doesn’t support sorting, grouping, LIKE, or aggregates. Encrypt probabilistically by default and reserve deterministic for fields you need to filter on.
Does Shield encryption carry over into Data 360?
Not automatically. Shield Platform Encryption for CRM and Platform Encryption for Data 360 are separate features with separate keys. A connector that ingests CRM data reads it as an authorized integration user, and the copy that lands in Data 360 is only encrypted at rest if you have separately enabled encryption there. Salesforce’s documentation doesn’t spell out the exact handling of an encrypted CRM field through ingestion, so verify it on a sample record and plan to enable encryption on both sides if a field must be protected everywhere.
Can an Agentforce agent read encrypted fields?
Yes, if the user it runs as has access to them. Encryption never hid the value from authorized readers, and grounding respects the running user’s permissions. The Einstein Trust Layer can mask sensitive fields in prompts for many features, but LLM data masking is disabled for Agentforce agent actions, so for agents the real control is field-level security and the agent user’s permissions, not encryption or Trust Layer masking.
Weighing Shield across CRM, Data 360, and an agent that grounds on the same records, and need the encryption and access model designed as one? Talk to us. Getting data trustworthy and governed enough to ground an agent without leaking it is the work we do.
