How to Govern Salesforce Agentforce: Security Checklist
A practitioner guide to auditing Agentforce identity, permissions, tool-call access, and audit logging, and understanding where native Salesforce controls stop.
Four Layers of Agentforce Security
Effective governance starts by treating each of these layers as a distinct control surface. Gaps at any one layer undermine the others.
-
01
Agent Identity
The running user context and its profile define what the agent can access.
-
02
Tool-Call Scope
Actions assigned per topic in Agent Builder define what the agent can invoke.
-
03
LLM-Layer Protection
Einstein Trust Layer masks data before it reaches the model.
-
04
Audit Depth
Setup Audit Trail vs. Shield determine action-level log retention.
How Agentforce Agents Inherit Salesforce’s Permission Model
Agentforce agents execute under a Salesforce user context. Object access, field-level security, and record visibility flow from the profile and permission sets assigned to that running identity, the same way they do for interactive users and integration accounts. Topic configuration in Agent Builder then narrows which actions (tool calls) the agent may invoke within that already-authorized scope.
That dual model is powerful, but it also means least privilege is only as strong as the narrowest intentional configuration of both surfaces. A purpose-built agent with a carefully scoped topic can still overreach if it runs as a broadly privileged user. Conversely, a tightly permissioned identity can still expose unnecessary capabilities if every available action is left attached to its topics.
Where Native Controls Stop
The Einstein Trust Layer addresses data protection at the point an agent interacts with a large language model. It masks sensitive information before it reaches the model, logs prompts and responses, and Salesforce states a zero-retention commitment with underlying LLM providers. This is a meaningful control for data exposure, but it operates at the LLM interaction layer. It does not perform object- or field-level authorization checks on the actions an agent executes against Salesforce records.
Audit logging presents a similar layering issue. Setup Audit Trail records configuration and setup changes but has limited retention and is not built for comprehensive, action-level conversational logging. Granular, longer-retention event logging is available through Salesforce Shield, a separately licensed product covering Event Monitoring and Field Audit Trail. Enterprises that need to attribute individual agent tool-call actions for compliance purposes should confirm whether Shield is already licensed before assuming that capability exists natively.
Because both permission scoping and topic and action configuration are set manually per agent, and Agentforce configuration is scoped per org, none of this is enforced continuously or consistently by default. Least privilege depends on administrator discipline at the time an agent is built, not on a platform-enforced runtime policy.
Architecture and Configuration Recommendations
Use the following checklist when designing or reviewing Agentforce deployments. Each item maps directly to one of the four control layers above.
- Dedicated permission sets per agent: Map each agent’s assigned actions to a purpose-built permission set instead of reusing broad existing profiles.
- Separate run-as identity per function: Use a distinct run-as user or permission set per agent function rather than a shared system or integration user.
- Action library review: Audit the full set of actions available to each topic and remove anything not required for that agent’s defined purpose.
- Compensating audit logging: Where compliance requires action-level, long-retention logs, enable Shield Event Monitoring or an equivalent mechanism rather than relying on Setup Audit Trail alone.
- Cross-org configuration standard: For multi-org or sandbox environments, define a standard Agentforce permission and topic template to reduce configuration drift between orgs.
Runtime Governance Beyond Native Settings
Native Salesforce controls scope identity and mask data at the model layer. They do not, by default, continuously enforce least privilege against live tool calls, nor do they guarantee action-level audit trails with enterprise retention without additional products and configuration.
Organizations with strict compliance, segregation-of-duties, or multi-org consistency requirements should treat Agent Builder configuration as necessary but not sufficient. A runtime governance approach sits alongside those native controls: it evaluates agent actions against policy at execution time and retains attributable logs for the full lifecycle of sensitive operations.
Common Questions on Agentforce Governance
Does Salesforce Shield fully solve Agentforce audit requirements?
Shield provides more granular, longer-retention logging than native Setup Audit Trail, but it is a separate license and its logging is not the same as a governance layer that enforces policy before an action executes. Confirm what Shield captures for agent tool calls specifically against your compliance requirements.
Can Agentforce enforce least privilege automatically?
No. Least privilege depends on how administrators configure the running user’s profile, permission sets, and the actions assigned to each topic. Salesforce does not automatically restrict agent permissions below what has been configured.
How should multi-org deployments handle Agentforce governance consistency?
Because Agentforce configuration, including topics, actions, and permissions, is scoped per org, multi-org enterprises need a defined configuration standard applied and audited separately in each org to avoid inconsistent policy enforcement.
Close the Gap Between Agentforce Configuration and Runtime Behavior
Native Salesforce controls scope identity and mask LLM-layer data, but continuous policy enforcement and audit-grade logging for agent actions often require a runtime governance layer.
Explore Runtime Governance