AI in Salesforce is only as safe as the access you give it. The boundary is your existing permissions and sharing: an AI feature or agent should see and change only what the user or dedicated agent user behind it is allowed to. Salesforce's Einstein Trust Layer adds protections around the model call, such as grounding with the user's access and zero data retention with third-party models, but prompt injection, over-broad agent users and outside AI tools remain your responsibility to control and monitor.
Permissions and sharing are the boundary
Salesforce describes the first step of the Trust Layer as secure data retrieval: prompts are grounded only with data the executing user can access, with role-based controls and field-level security kept in place. That is reassuring and also a warning. If a sales rep can already open every account in the org because sharing was left public, an AI summary will happily draw on all of them. AI does not create access problems; it finds the ones you already have, faster and at scale.
So the first security task for any AI rollout is an access review of the objects the use case touches. Check organization-wide defaults, who holds View All or Modify All, and which sensitive fields are readable by broad permission sets. Our Salesforce security review checklist walks through that review; run it before the pilot, not after.
Who the AI acts as
Every AI feature runs in some user's context, and the security question is always which one. The answer differs by type of AI, so list each one you use:
| AI type | Runs as | Main risk | Control to set |
|---|---|---|---|
| Assistive features for employees, such as summaries and drafts | The logged-in employee | Over-shared records surface in outputs | Fix sharing and field-level security for those users |
| Agentforce agents serving customers | A dedicated agent user, or a site guest or portal user on external sites | Agent user granted more than its job needs | Keep the agent user’s permission set to the minimum objects and fields |
| Scheduled or background AI jobs | The user or integration user that owns the job | Broad read access used for batch analysis | Separate read-only user; write access only where approved |
| External AI tools connected through the API | An integration user or connected app | Data leaves Salesforce under that tool’s terms | Dedicated integration user, restricted connected app, vendor review |
Salesforce creates service agent users with minimal access by default, and admins grant more through a permission set tied to the agent. Keep it that way. The common failure is an admin who hits a permissions error during testing and fixes it by adding a broad permission set rather than the one object the action needed.
Separating reading from writing is the most useful single control. For a payments company, we connected an AI assistant to Salesforce for scheduled, read-only pipeline analysis, and piloted follow-up task creation separately with restricted access, approval before each write and an audit trail. Leadership kept control of every Salesforce write in that pilot, which made the read-only work easy to approve.
What the Einstein Trust Layer does
The Trust Layer is Salesforce's set of controls around generative AI calls. In its own materials, Salesforce lists secure data retrieval and dynamic grounding, masking of personal and sensitive data, zero data retention with third-party model providers so prompts and responses are not stored or used for training, toxicity detection on generated content, and security guardrails. A few details matter for planning:
- Pattern-based and field-based data masking is disabled for Agentforce agents, because masked context can make agent answers less accurate; the zero data retention terms still apply.
- Some Salesforce-managed models are hosted inside the Salesforce trust boundary, so data sent to them does not leave it.
- Geo-aware model options route requests to a data center near where your Data 360 instance is provisioned.
- The Trust Layer protects the model call; it does not decide what an agent is allowed to do or who may use it.
Prompt injection and data leakage
Prompt injection is text written to make an AI ignore its instructions: a customer message saying the agent should reveal other orders, or a line hidden in an uploaded document or web form telling the model to change a record. Salesforce says system policies and security guardrails help defend against prompt injection and jailbreak attempts, and that is worth having. No filter catches everything, so design as if some injected instructions will get through.
In practice that means limiting what a successful injection could achieve. An agent that can only read order status for the verified customer in the conversation cannot leak another customer's orders, whatever it is told. Require verification before an agent reveals account details, keep refunds, credits and record deletions behind human approval, and treat any content the AI reads from customers, emails or files as untrusted input.
Leakage also happens outside Salesforce. Staff who paste pipeline exports or customer lists into a personal AI chat tool bypass every control above. Give people an approved route instead, whether Salesforce's own AI features or a connected tool reviewed by IT, and state plainly in policy which data may not leave approved systems.
Audit and monitoring
Plan what you will be able to prove after an incident. Salesforce can store generative AI audit and feedback data in Data 360, and Agentforce session tracing records how an agent handled a conversation. Pair those with the org's standard tools: Setup Audit Trail for changes to agent users and permission sets, field history on the records agents update, and Event Monitoring if you need to see API activity from connected AI tools. Name a person who reviews them on a schedule; logs nobody reads are evidence only after the fact.
Questions to ask vendors about data and residency
Whether the AI is Salesforce's or a connected product, get written answers to these before signing:
- Where are prompts and responses processed and stored, and can we choose the region?
- Is any of our data retained by the model provider, and is it ever used for training?
- Which Salesforce user or connected app does the tool use, and what is the minimum access it needs?
- Can it write to Salesforce, and can writes require human approval?
- What logs do we get, how long are they kept and can we export them?
- How are prompt injection and unsafe output handled, and how are incidents reported to us?
For Salesforce itself, Hyperforce lets customers choose the region where their org's data resides, but Salesforce notes that Einstein features can process data outside the local geography in some regions. If residency is a contractual requirement, confirm the specifics for your region and features with Salesforce in writing. For wider policy on ownership, allowed uses and human review, see our AI governance guide.
