Securing Salesforce Agentforce: Agent Users and Actions

An Agentforce agent can read and change CRM records with whatever permissions its running user holds, and it reads untrusted text from forms, emails and cases while it does so. That combination turns ordinary Salesforce access control questions (profiles, permission sets, sharing, field-level security) into agent security questions, because a prompt injected into a lead record can steer an agent that has access to every lead. This guide explains which identity each kind of Agentforce agent runs as, how to scope the agent user and its actions, how to secure the Agent API and its external client app, what the Einstein Trust Layer does and does not cover, and what to log. It is written for Salesforce administrators, platform security teams and architects who are putting employee or service agents into production.

Key takeaways

Know which identity runs the agent. Employee agents act with the permissions of the logged-in user; service agents on unauthenticated channels act as the dedicated agent user, so that user's permission sets are the real blast radius.
Scope actions, not just the agent. Flows and Apex behind each action must enforce CRUD, field-level security and sharing themselves, run queries in user mode, and refuse record IDs or object names supplied by the conversation.
Treat every record the agent reads as untrusted input. ForcedLeak showed that a Web-to-Lead description field plus one stale allowlisted domain was enough to exfiltrate lead data through an image URL.
Keep Trusted URLs and outbound paths tight. Salesforce now enforces trusted URL allowlists for Agentforce output; review that list like a firewall rule set and remove anything expired or unowned.
Turn on tracing before go-live. Session Tracing and Audit and Feedback capture each turn, LLM call and action, but only if they are enabled in Setup and exported somewhere you keep for longer than the 72 hour API window.

How identity and access work in Agentforce

Agentforce agents are configured in Agent Builder (or Agent Script) as topics, instructions and actions. Actions are the parts that touch data: flows, Apex invocable methods, prompt templates and standard actions. The large language model decides which action to call; the Salesforce platform decides whether the running user is allowed to do what the action asks. Which user that is depends on the agent type and the channel.

Agent type and channel	Runs as	What limits it	Main risk
Employee agent (inside Lightning, Slack and similar internal surfaces)	The logged-in user who submitted the prompt	That user's profile, permission sets, sharing and field-level security	Over-privileged users get an over-privileged agent; injected content in records they can see can steer actions they are allowed to take
Service agent on an unauthenticated channel (web chat, messaging)	The agent user assigned when the agent was created	The agent user's permission sets plus whatever each action enforces	Every anonymous visitor shares one identity; any data that user can read is potentially reachable
Service agent on an authenticated Experience Cloud site	The logged-in Experience Cloud user, but only when Credential-Based User Verification is turned on	Community user licence, sharing sets and permission sets	If verification is off, the agent falls back to the agent user
Agent called through the Agent API	The agent-assigned user when `bypassUser` is true, otherwise the user tied to the access token	External client app scopes, the Run As user and the agent user	A leaked consumer secret gives an outside caller a full agent session

The agent user

When the Salesforce CLI creates an agent user (sf org create agent-user) it uses the Einstein Agent User profile and assigns three permission sets: AgentforceServiceAgentBase, AgentforceServiceAgentUser and EinsteinGPTPromptTemplateUser. The user has no password, so nobody can log in as it, and only administrators can see or edit it in Setup. The risk comes later, when permission sets are added to make an action work and never removed. Treat the agent user as a non-human identity with an owner, a documented purpose and a periodic access review. See the AI Agent Authorisation Guide.

One agent user per agent: sharing one agent user across a public FAQ agent and an order-management agent gives the FAQ agent order access. Separate users keep each agent's permission sets reviewable.
Permission sets, not profile edits: keep the Einstein Agent User profile minimal and grant object and field access through named permission sets (or a permission set group) per agent, so the access review shows exactly what was added and why.
Sharing for the agent user: an agent user that owns no records and has Private org-wide defaults sees little; one placed high in the role hierarchy or given "View All" on an object sees everything. Check both.
No "Modify All Data" or "View All Data": these system permissions bypass sharing for every object and have no place on an agent user.

Admin roles and privileged access

Whoever can edit topic instructions, action assignments, prompt templates, Trusted URLs or Trust Layer settings can change what an agent does for every user.

Capability	Why it is privileged	Control
Editing agents, topics and instructions in Agent Builder	Instructions shape which actions the model calls and with what inputs	Limit to a named group of agent builders; build in a sandbox and deploy through change control
Assigning permission sets to agent users	Directly widens what service agents can reach	Separate the person who requests access from the one who grants it; log through Setup Audit Trail
Creating flows and Apex used as actions	Code that runs in system context can ignore the user's permissions	Code review for `with sharing`, user mode queries and input validation
Trusted URLs and CSP settings	Defines where agent output and pages can send data	Quarterly review; remove expired or unowned domains
External client apps for the Agent API	Issue tokens that start agent sessions from outside Salesforce	Owner per app, secret rotation, IP and scope limits
Einstein Trust Layer and data masking settings	Controls what sensitive data reaches the model	Change only through change control; alert on edits

Separate builders from administrators: agent builders need Agent Builder and prompt template access, not the ability to manage users or permission sets. Keep "Manage Users" and "Customize Application" on a small administrator group protected by phishing-resistant MFA.

See the Salesforce Security Guide for the wider administrator and MFA baseline.

Actions, data access and the Trust Layer

The model chooses actions, but the action code decides what data comes back. Salesforce's own security guidance for Agentforce custom actions sets out the checks every action needs.

Securing actions

Classify each action: by agent type (employee or service) and by sensitivity. Private actions return non-public data or create, change or delete records, and require at least user verification.
Enforce access in the action: apply CRUD, field-level security and record-level sharing. In Apex use with sharing and run DML and SOQL in user mode (for example AccessLevel.USER_MODE). For public actions, select only the fields the answer needs.
Do not let the conversation pick targets: never accept record IDs, object names or field names as user-controlled input. Turn off "Collect data from user" for those inputs, or set copilotAction:isUserInput to false in the action schema.
Scope service actions to the verified customer: store the verified identity in the VerifiedCustomerId context variable using "Assign a Variable" in Agent Builder, check it is not null, and filter every query by it. Salesforce notes that the Customer Verification topic (email plus one-time code) is verification, not authentication.
Treat model output as untrusted: request structured output such as JSON, validate length, character set and ID format before using values in DML or SOQL, and output-encode anything shown in Lightning web components or Visualforce.
Require confirmation for side effects: for actions that change data or send email on a user's behalf, enable "Require user confirmation" (isConfirmationRequired on the GenAiFunction metadata). Salesforce links this to the OWASP excessive agency risk.

What the Einstein Trust Layer covers

Salesforce describes the Trust Layer as grounding in CRM data, masking of sensitive data such as national identifiers, zero data retention commitments with LLM providers such as OpenAI, toxicity detection on generations, and an audit trail with feedback. These protect data on its way to and from the model. They do not decide whether the agent user should be able to read a record, and they do not stop a prompt injected into a record from asking the agent to call an action it is allowed to call. Access control and action design remain your job. See the Enterprise AI Copilot Security Guide.

Untrusted content and outbound URLs

Agents read Web-to-Lead submissions, Web-to-Case text, inbound emails, chat transcripts and knowledge articles, much of it written by people outside your organisation. Indirect prompt injection (MITRE ATLAS AML.T0051.001, OWASP LLM01:2025) hides instructions in that content. The ForcedLeak research by Noma Security, reported in September 2025, placed instructions in the 42,000 character Web-to-Lead description field. When an employee later asked the agent about the lead, the agent gathered lead email addresses and rendered an image tag pointing at a domain that was still on the Content Security Policy allowlist but had expired; the researchers bought it for $5. Salesforce began enforcing trusted URL allowlists for Agentforce and Einstein generative AI agents from 8 September 2025 and re-secured the domain. Every allowlisted outbound domain is an exfiltration path for an agent that can be persuaded to build a URL. See the Prompt Injection Guide and the Data Exfiltration Guide.

Trusted URLs: find the list with Quick Find "Trusted URLs". Every entry should have an owner, a reason and a check that the domain is still registered to you or the supplier.
Inbound forms: restrict field lengths on Web-to-Lead and Web-to-Case to what the business needs, add spam and bot protection, and consider keeping externally submitted free text out of the fields agents ground on.

Integrations, API tokens and service accounts

Agentforce reaches outside Salesforce, and outside systems reach into Agentforce. Both directions run on non-human credentials.

The Agent API and external client apps

To call an agent programmatically, Salesforce's Agent API documentation has you create an External Client App with the OAuth scopes api, refresh_token/offline_access, chatbot_api and sfap_api, enable the Client Credentials Flow, and set a Run As user with at least API Only access. The app's consumer key and secret then mint JWT-based access tokens at /services/oauth2/token. Anyone holding that secret can open agent sessions, so treat it like a privileged service account password.

Dedicated Run As user: an API Only user that exists only for this integration, with no interactive login and no administrative permissions.
Secret storage: keep the consumer secret in a secrets manager, never in client code or a front-end app. Rotate it on a schedule and when staff with access leave. See the Secrets Management Guide.
Restrict the app: limit who can use the app, apply IP restrictions where the caller has fixed egress, and remove scopes that a given integration does not need.

Logging and detection

The evidence you need is the trace: which topic was chosen, which actions ran, on what inputs.

Source	What it records	Use it for
Agentforce Session Tracing (enable in Einstein Audit, Analytics, and Monitoring Setup)	Turns, messages, LLM calls and actions per session, stored in Data 360	Investigating what an agent did and why
Generative AI Audit and Feedback	Trust Layer audit trail and user feedback	Masking, toxicity and feedback review
Session Tracing API (beta), `GET /services/data/v66.0/einstein/audit/otel/{session-id}`	The trace in OpenTelemetry (OTLP v1.0) format	Export to an observability platform or SIEM; only sessions started in the previous 72 hours, one session per request
Setup Audit Trail	Configuration changes	Detecting edits to agent users, permission sets, Trusted URLs and apps

Do not log prompts in debug logs: Salesforce advises against writing prompts or responses through System.debug; use the enhanced event logs in Agent Builder instead.
Detections worth building: agent output containing URLs or image markup to domains not on your list; agent user query volume well above baseline; actions invoked with record IDs that do not belong to the verified customer; new permission set assignments to agent users; new or changed Trusted URLs; consumer secret use from new IP ranges.
ATT&CK and ATLAS mapping: exfiltration through agent output maps to ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation and to ATT&CK T1567 Exfiltration Over Web Service; abuse of the agent or Run As user maps to T1078.004 Cloud Accounts; theft of external client app tokens to T1528 Steal Application Access Token.

Metrics

Agent user privilege: number of permission sets and objects with edit access per agent user, tracked over time (should not creep up).
Action coverage: percentage of custom actions with a recorded security review covering sharing, user mode and input validation (target 100%).
Confirmation coverage: percentage of data-changing and email-sending actions with user confirmation required.
Trusted URL hygiene: entries without an owner or past their review date (target zero).

Hardening baseline

Roll this out in phases rather than all at once, because tightening an agent user or action can break conversations that worked in testing.

Inventory (week 1 to 2): list every agent, its type, channel, agent user, actions, prompt templates, named credentials and external client apps. Record an owner for each.
Instrument (week 2 to 3): enable Session Tracing and Audit and Feedback, forward Setup Audit Trail and traces to your SIEM, and capture a baseline of normal action volume.
Reduce agent user access (week 3 to 5): in a full sandbox, remove permission sets one at a time and rerun your agent test conversations. Promote the reduced set to production for one agent first, with the previous permission set assignment documented so you can restore it in minutes if conversations fail.
Fix actions (week 4 to 8): review flows and Apex for sharing, user mode, ID inputs and output validation. Add user confirmation to side-effecting actions.
Close outbound paths (week 5 to 6): review Trusted URLs and CSP entries, remove stale domains, and test that agents can no longer render content from removed domains.
Test adversarially (before each release): seed sandbox leads, cases and emails with indirect injection text and check the agent neither leaks data nor calls unexpected actions.
Review (quarterly): agent user permissions, external client apps and secrets, Trusted URLs, and the trace-based detections.

Small and large organisations: a small org with one service agent can usually get most of the value from a single dedicated agent user, user mode Apex, confirmation on side effects and a short Trusted URL list. A large enterprise needs per-agent users, a release pipeline for agent metadata, central trace export and an owner for every external client app. Choose employee agents where the task needs the user's own access; choose service agents for external audiences, accepting that you are designing a shared identity's access from scratch.

Common misconfigurations

Agent user collects permission sets: each new action gets "just one more" permission set until the service agent can read every account. Fix with per-agent users and quarterly review.
Apex actions without sharing: invocable methods in classes declared without sharing or running SOQL in system mode return records the user should never see.
Record IDs from the chat: an action that accepts any record ID lets a customer ask for someone else's order by guessing or injecting an ID.
Stale allowlisted domains: ForcedLeak turned one expired Trusted URL into an exfiltration channel; nobody had checked whether the domain was still owned.
Tracing left off: without Session Tracing there is no reliable record of which action ran on which input, which turns an incident review into guesswork.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Threat reference
Agent user and Run As user lifecycle	AC-2 Account Management	PR.AA-05	T1078.004 Cloud Accounts
Least privilege for agent users and builders	AC-6, AC-6(5)	PR.AA-05	OWASP LLM06:2025 Excessive Agency
Action input and output validation	SI-10 Information Input Validation	PR.PS (platform security)	AML.T0051.001, OWASP LLM01:2025
Limiting outbound URLs and actions	CM-7 Least Functionality	PR.PS	AML.T0086, T1567
Tracing and audit logs	AU-2, AU-12, AU-6	DE.CM-09	OWASP LLM02:2025 Sensitive Information Disclosure
Agent and app inventory	CA-7 Continuous Monitoring	ID.AM-02	T1528 Steal Application Access Token

For the cross-platform view of low-code agent builders, see the Low-Code Agent Platforms Guide and, for the Microsoft equivalent of this page, the Securing Microsoft Copilot Studio Agents Guide.

Practitioner checklist

Record every Agentforce agent with its type, channel, running identity, actions and owner.
Give each service agent its own agent user, with access granted only through named permission sets and no View All or Modify All permissions.
Turn on Credential-Based User Verification where service agents serve authenticated Experience Cloud users.
Review every flow and Apex action for sharing, user mode, ID inputs, output validation and user confirmation.
Scope service actions to VerifiedCustomerId and never to IDs supplied in the conversation.
Review Trusted URLs and CSP entries quarterly and remove any domain you cannot prove you own or need.
Store Agent API consumer secrets in a secrets manager, use a dedicated API Only Run As user and rotate on a schedule.
Enable Session Tracing and Audit and Feedback, export traces within the 72 hour window and alert on agent output containing unknown URLs.
Test agents with indirect prompt injection seeded into leads, cases and emails before each release.

Securing Salesforce Agentforce Guide: Permissions, Data Access and Trust Layer