Agent Security: What Data an Agent Can See and Change
5 minutes
5 Questions
In Salesforce Agentforce, agent security governs what data an autonomous or assistive agent can access and modify, ensuring it operates within the boundaries defined for its associated user context. Agents run under a specific user, often called the Agent User or a service account, and they inherit…In Salesforce Agentforce, agent security governs what data an autonomous or assistive agent can access and modify, ensuring it operates within the boundaries defined for its associated user context. Agents run under a specific user, often called the Agent User or a service account, and they inherit that user's permissions. This means an agent can only see and change data that the underlying user is permitted to access through the standard Salesforce security model.
Several layers control this access. First, profiles and permission sets determine object-level and field-level permissions, dictating which objects the agent can read, create, edit, or delete, and which specific fields are visible. Second, organization-wide defaults, role hierarchy, and sharing rules control record-level visibility, ensuring the agent respects who owns records and how they are shared across the org. Third, field-level security hides sensitive fields such as personal or financial details, so the agent cannot expose them even if it can view the record.
Agentforce also relies on Actions and Topics, which are curated capabilities that define what an agent is allowed to do. Administrators explicitly grant these actions, so an agent performs only the tasks that have been approved, such as looking up a case, updating a contact, or creating an opportunity. If an action is not assigned, the agent cannot perform it.
Data masking, encryption, and the Einstein Trust Layer add further protection, helping keep sensitive information secure during processing and preventing it from being retained inappropriately. Audit trails and monitoring allow administrators to review agent activity for compliance.
By configuring profiles, permission sets, sharing settings, field-level security, and assigned actions carefully, administrators ensure an agent sees and changes only appropriate data. This layered approach keeps Agentforce aligned with the same trust and governance principles that protect all Salesforce data.
Agent Security: What Data an Agent Can See and Change
Agent Data Access & Sharing is a foundational concept in Agentforce that determines exactly what records, fields, and objects an AI agent can view and modify when it acts on behalf of users. Understanding this topic is essential for any Salesforce Administrator preparing for certification, as it combines Salesforce's core security model with the newer capabilities of autonomous agents.
Why It Is Important
When you deploy an Agentforce agent, it does not operate outside your org's security. Instead, it inherits permissions from a specific user context. This means the data an agent can retrieve, summarize, or update is governed by the same layers that protect human users. If you misconfigure these settings, an agent could either be blocked from doing useful work or, worse, expose sensitive data to people who should not see it. Getting this right protects your organization while still allowing automation to add value.
What It Is
Agent data access refers to the combination of security controls that define an agent's visibility and editing rights. These controls include:
• Running user context: Every agent action runs as a particular user, inheriting that user's profile, permission sets, and role. • Object-level security: Determined by profiles and permission sets, controlling which objects the agent can read, create, edit, or delete. • Field-level security (FLS): Restricts which specific fields are visible or editable to the agent. • Record-level access: Governed by organization-wide defaults, role hierarchy, and sharing rules, deciding which individual records the agent can reach.
How It Works
When an agent performs a task, Salesforce evaluates the running user's permissions before returning any data or committing any change. The agent can never see or alter more than its assigned user is permitted to.
The evaluation flows through these layers in order:
1. Object permissions check whether the user can access the object at all. 2. Field-level security filters which fields are returned or updatable. 3. Sharing settings determine which specific records fall within scope.
Because the agent respects sharing, a support agent user will only surface cases they own or that are shared with them, while a manager higher in the role hierarchy may see a broader set. To grant an agent additional capability, you adjust the underlying user's permission set or sharing rules rather than the agent itself.
How To Answer Exam Questions
Exam scenarios often describe an agent that is either seeing too much or too little data, then ask you to identify the cause or the fix. The key is to trace the problem back to the running user's security configuration. Ask yourself: which layer would explain this behavior? If an agent cannot edit a field, suspect field-level security. If it cannot find certain records, suspect sharing rules or role hierarchy.
Exam Tips: Answering Questions on Agent Security: What Data an Agent Can See and Change
• Remember that an agent always runs in a user context and inherits that user's permissions. • When a question mentions an agent missing specific records, focus on sharing rules, org-wide defaults, and role hierarchy. • When a question mentions an agent unable to access a specific field, focus on field-level security. • When an agent cannot touch an entire object, look to profiles and permission sets for object permissions. • The correct fix is usually adjusting the running user's security rather than changing the agent configuration. • Watch for distractor answers suggesting agents bypass the security model; an agent always honors it. • If a scenario shows an agent exposing sensitive data, the root cause is often overly broad permissions granted to the running user.
