By
A support agent asks Salesforce's AI to draft a response to an angry customer. The AI reads the case history, the account record, and three months of email threads to write that response. None of that data left the building five years ago. Now it's being read, interpreted, and acted on by a system that didn't exist when most compliance frameworks were written.
That's the real shift behind Salesforce security and compliance today. The question isn't whether Salesforce can lock down a database; it can, and has for two decades. The question is whether the same protections hold up when generative AI and autonomous agents are reading that database in real time, generating responses, and sometimes acting without a human in the loop. For any organization running Agentforce or Data 360, Salesforce security and compliance means understanding both the platform's built-in architecture and where configuration decisions still sit with the customer.
How Salesforce secures data at the platform level
Salesforce security and compliance starts with infrastructure most admins never touch directly: encrypted data centers, redundant failover, and continuous monitoring across the physical layer. On top of that sits a set of platform controls every org can configure.
Field-level security and profile-based permissions determine who sees what, record by record. Salesforce Shield extends this with three components worth knowing by name:
- Platform Encryption encrypts sensitive fields at rest using AES-256, with options for customer-managed keys so Salesforce itself can't read the underlying value.
- Event Monitoring logs more than 50 event types, including logins, API calls, report exports, and Apex execution, giving security teams a forensic trail when something looks wrong.
- Field Audit Trail extends standard field history tracking so organizations can reconstruct exactly who changed what, and when, well beyond the platform default retention window.
None of this is automatic. Shield is a licensed add-on, and its value depends entirely on whether someone configures it against the org's actual risk profile. A manufacturing client and a healthcare payer need different encryption policies, different audit retention windows, and different event monitoring thresholds, even on the identical Salesforce edition.
Multi-factor authentication, IP restrictions, and session security policies round out the baseline layer. Salesforce enforces MFA for direct UI logins by default, but integrations and API connections often need their own hardening; a service account with a static password and no IP allowlist is still one of the more common findings in a Salesforce security review. Getting the baseline right matters because every AI feature built on top of the platform inherits whatever permission and access decisions already exist underneath it.
Where AI changes the security model
Generative AI introduces a problem traditional Salesforce security and compliance frameworks weren't built for: data that used to sit still inside a record now gets extracted into a prompt, sent somewhere for processing, and returned. The Trust Layer exists specifically to govern that movement.
Before any prompt reaches a large language model, whether that's Salesforce's own models or a third-party LLM connected through the platform, the Trust Layer filters the request through the requesting user's existing permissions. If a rep doesn't have field-level access to a customer's payment details, the AI doesn't get that data in its prompt either. The Trust Layer then applies data masking, detecting and replacing identifiers like names, phone numbers, and financial information with placeholders before the prompt leaves the org, and restoring the real values only after the response comes back.
Two features matter most for compliance teams evaluating Agentforce deployments:
- Zero data retention with external model providers, meaning Salesforce contracts guarantee the LLM doesn't store or train on customer prompts.
- Audit logging of every prompt and response pair, which becomes essential when a regulator or internal auditor asks what an AI agent actually said to a customer.
The honest caveat: several of the Trust Layer's most valuable features, including full masking and audit trail depth, depend on Data 360 being configured correctly. Organizations that haven't invested in Data 360 get a thinner version of these protections. That's a real cost-and-complexity decision, not a checkbox, and it's worth mapping out before an Agentforce rollout rather than during one.
Autonomous agents raise the stakes further. Agentforce Assistant and traditional generative AI features wait for a human to ask a question and read a drafted response before it goes anywhere. Agentforce agents can take multi-step actions on their own: updating a case, issuing a refund, escalating a ticket, without a person approving each step. That means the permission model an agent operates under isn't a convenience setting; it's the actual boundary on what the agent can do to a customer's account. An agent scoped too broadly doesn't just risk exposing data. It risks taking an action nobody authorized. Salesforce security and compliance teams evaluating Agentforce need to treat agent permission sets with the same rigor as a new employee's access, not as a technical afterthought bolted on after launch.
Compliance certifications and what they actually cover
Salesforce maintains a substantial certification portfolio: SOC 2 Type II, SOC 1, ISO 27001 (along with ISO 27017 and ISO 27018 for cloud and privacy controls), HIPAA support for healthcare customers, PCI DSS for payment data, and FedRAMP for government workloads.
These certifications matter, but they describe Salesforce's infrastructure and internal controls, not any individual customer's org. A SOC 2 report confirms Salesforce's data centers and processes meet an independent auditor's standard. It says nothing about whether your org has over-permissioned an integration user, left a sandbox unmasked, or skipped field-level security on a custom object holding Social Security numbers. Regulators evaluating a breach or an audit will ask about your configuration, not Salesforce's certificate.
This is the shared responsibility model in practice. Salesforce secures the platform. The customer secures how that platform gets used, which fields get exposed to AI, which integrations run with which permissions, and whether audit logging is actually turned on and reviewed.
The distinction shows up constantly in due diligence conversations. A prospective client will ask for Salesforce's SOC 2 report, receive it, and treat the question as closed. It isn't. The report covers Salesforce's controls over its own infrastructure and processes; it says nothing about whether that specific customer has enabled field-level encryption on the fields that need it, whether their sandbox refresh process re-exposes masked data, or whether a third-party integration has been granted more scope than its function requires. Auditors reviewing a specific org for HIPAA or PCI DSS alignment will ask for evidence of the customer's own configuration, not a copy of Salesforce's certificate.
Building a security posture that holds up
Certifications and built-in tools give an organization the raw materials for Salesforce security and compliance. Turning that into an actual security posture takes work most teams underestimate:
- Permission audits before AI rollout. If a profile has broader field access than a role needs, the Trust Layer will faithfully expose that same broad access to AI. Fixing permissions after Agentforce is live means retroactively discovering what agents already read.
- Data classification. Shield's masking and encryption only protect what's been correctly classified as sensitive. Unclassified custom fields holding health or financial data slip through.
- Monitoring that gets reviewed. Event Monitoring generates the logs; someone still has to look at them. Dashboards nobody checks don't stop a breach.
- A documented data residency and retention policy, especially for organizations in regulated industries with specific requirements about where data lives and how long it's kept.
This is where implementation experience separates a working security posture from a checklist. Configuring Salesforce Shield correctly for a specific industry's risk profile, setting up an Agentforce rollout with permissions scoped before agents ever touch live data, and building the AI and data governance practices that keep pace as the platform adds new AI capabilities: none of that comes out of the box. It's built.
Organizations in regulated sectors feel this most acutely. A financial services firm and a healthcare provider are both subject to Salesforce's platform-level certifications, but they need very different field-level encryption strategies, audit retention windows, and AI grounding rules to satisfy their specific regulators.
Getting this right the first time, rather than remediating after an audit finding or an incident, is the difference between treating Salesforce security and compliance as a vendor's problem and treating it as an implementation discipline. If your organization is planning an Agentforce rollout and wants the permission model, data classification, and Shield configuration built correctly before agents go live, talk to our team about a security and compliance assessment.
