Agentforce Security Layers Explained: How Salesforce Protects AI Data

⚡ Key Points: 1-Minute Summary

• Four Security Layers: Agentforce protects data using a strict four-layer model encompassing User Context, Field-Level Security (FLS), Sharing Rules, and the Einstein Trust Layer.
• The Trust Layer is Built-In: The Einstein Trust Layer operates at an architectural level. It handles zero-retention agreements, toxicity scoring, and PII masking automatically before data reaches external LLMs.
• Direct Apex Callouts Bypass Protections: If you build direct Apex callouts to external LLMs instead of using standard Agentforce actions, the Trust Layer is bypassed. You are solely responsible for data masking and audit logging.
• Never Bypass Sharing: Custom agent actions utilizing Apex should always enforce security using with sharing and USER_MODE.

🛡️ The Four Security Layers of Agentforce

💬 In plain words: Salesforce relies on four distinct layers to protect your data in the AI era. The first layer acts as a hard ceiling, controlling who the agent is acting on behalf of. The final layer is the platform itself, ensuring data privacy when interacting with LLMs. In between, standard Salesforce declarative security applies exactly as you already know it.

📌 Real-Life Example: A sales rep without read access to a specific enterprise account asks their Agentforce assistant for the latest billing meter details on that account. The agent refuses the request. The agent doesn't refuse because a prompt instructed it to be secretive—it refuses because the user context the agent is running under physically lacks the sharing visibility to read the record.

To fully grasp how Agentforce remains secure, you must understand how these four concepts stack together:

• Layer 1: User Context. Employee agents inherit the exact permissions of the logged-in user making the request. Customer-facing service agents operate under their own dedicated, heavily restricted integration user. This creates the absolute ceiling of access.
• Layer 2: Field-Level Security (FLS). The agent can only read or process fields the running user is explicitly granted permission to view.
• Layer 3: Sharing Rules. Record-level visibility works normally. If the user cannot see a record via Org-Wide Defaults, Role Hierarchy, or Sharing Rules, neither can the agent.
• Layer 4: Einstein Trust Layer. Before passing contextual data to an LLM, Salesforce strips PII, enforces zero-data-retention policies with model providers, runs toxicity checks, and logs a secure audit trail.

Here is how the hierarchy maps out in practice:

Four layers
├─ 1. USER CONTEXT    employee = caller | service = own user
│                     ← the hard ceiling
├─ 2. FLS             field access, enforced normally
├─ 3. SHARING         record access, enforced normally
└─ 4. TRUST LAYER     zero retention, toxicity, audit trail
                      ← architectural, not a toggle
  

🧠 Core Takeaway: "Cannot read" always beats "Will not say." Security is strictly defined by what the user profile can reach, never by what the AI system prompt asks the agent to hide.

🧭 360 Card — The Four Security Layers

Rule: Prove every layer by testing with restricted users and document the evidence. Never describe a security boundary you haven't successfully demonstrated in a sandbox.
Gain: Ironclad security audits. When you have screenshots of a restricted user being denied access by the agent, compliance teams cannot push back.
Price: Real administrative effort. Building highly restricted test personas and running thorough integration tests takes significant time.
Limits: There is no override. An Agentforce agent does not possess a "run-as-system" mode to bypass visibility rules on the fly.
Mirror: Instructing the agent via prompt engineering to "not share data" is the most common wrong answer in Agentforce architectural interviews.
At volume: Service agent profiles demand the strictest auditing because every permission grant extends your public attack surface.

⚠ INTERVIEW TRAP: If asked how to secure Agentforce, never say, "We instructed the agent in the prompt not to reveal sensitive customer data." Interviewers ask this specifically to see if you rely on easily bypassed prompt constraints or robust Salesforce permission models.

💬 Core Q&A

Q: How is data protected in Agentforce?

🎯 Say this first: "Agentforce protects data using four layers: user context, field-level security, sharing rules, and the Einstein Trust Layer underneath."

A: Always start by explaining the ceiling, because every other security control sits beneath it. The agent runs strictly within a user's permissions. For an internal employee agent, that is the actual person typing the prompt. For an external service agent, it utilizes a dedicated, scoped integration user.

Inside that ceiling, standard Field-Level Security and Sharing Rules apply. Any custom Apex actions you build for the agent must inherit these rules using with sharing and USER_MODE database queries.

Finally, the Einstein Trust Layer handles the external handoff. It enforces zero-retention policies with LLM providers, runs toxicity checks, masks PII, and captures an audit trail. A live demonstration is the best way to prove this: log in as a restricted user, ask the agent for an inaccessible record, and document the automated refusal.

Q: What happens if an Apex action used by Agentforce is written using `without sharing`?

A: This is a massive security risk. If you assign an Apex class running without sharing to an agent action, you are effectively bypassing the first three layers of Salesforce security. The agent will read and return records as the system, exposing data the invoking user should never see. Always use with sharing for agent-invoked code.

Q: Does the Einstein Trust Layer mask data internally within the org?

A: No. The Einstein Trust Layer handles PII masking and toxicity scoring specifically for the payload traveling outbound to the LLM. Internal data visibility between the user and the Salesforce database is governed entirely by standard profiles, permission sets, and sharing rules.