Governing Salesforce Agentforce Deployments

Agentforce agents run as a dedicated agent user created specifically for that agent — not the human or customer who happens to be chatting with it — and it is that agent user's own assigned permission sets and profile that govern what CRM data and actions the agent can reach. Salesforce's trust layer then applies data masking, toxicity screening, and audit logging on top of whatever access the agent user has. For an agent user configured with a narrow, task-appropriate permission set, that is a coherent, well-integrated model. The governance question that actually needs attention is two-fold: first, confirming exactly which agent user a given Agentforce agent executes as and what its permission sets actually grant, and second, what happens in custom actions — the Flows, Apex code, and external API calls a builder wires an Agentforce topic to invoke — because those execute with whatever permission the underlying automation was built with, not necessarily the same scope as the agent user itself.

The agent user is the permission boundary, not the invoking human

Salesforce's decision to give each Agentforce agent its own dedicated user record, governed by the same permission architecture Salesforce already uses for every other user, rather than inventing a separate access model for agents, is the right default — but it means the single most consequential configuration decision in any deployment is who that agent user is and what it can do:

• Agentforce runs as a dedicated agent user. Salesforce provisions a specific user record for the agent (for a Service Agent deployment, this is commonly a purpose-built agent user such as an "Agentforce Service Agent User"), and that user's own profile and permission sets — not the customer's or employee's who is chatting with the agent — determine what the agent can see and do.
• Object and field-level security governs the agent user directly. An Agentforce agent answering a question about a customer record is subject to the same sharing rules that would apply if the agent user itself queried that record directly, which makes auditing the agent user's own access the highest-leverage review available.
• The trust layer sits between the agent and the underlying large language model, applying data masking to sensitive fields before they reach the model and providing an audit record of what data was exposed during an interaction — a control aimed at the risk of CRM data leaking into a model provider's context, independent of whatever the agent user's permission set otherwise allows.
• Permission sets assigned to the agent user let an administrator constrain what an individual Agentforce agent can do, independently of any human's own profile, rather than the agent inheriting a broad, template-driven permission set assigned for convenience during setup.

For an agent user configured with a permission set scoped tightly to the objects and fields a given agent's topics actually require, this is a coherent, low-risk configuration. It also generalizes: because an agent's authority is a property of the user it runs as, not of the human invoking it, confirming which agent user backs a given agent and auditing that user's permission sets directly is a different exercise from reviewing a human employee's access — and, in practice, an easier one to skip, since an agent user rarely appears in the access-review processes built around human headcount.

Where custom actions concentrate the risk

The gap opens at custom actions: an Agentforce topic wired to invoke a Flow, an Apex class, or an external API to complete a task the conversational layer alone cannot. Each of those integration points was built by a developer or administrator at a specific point in time, for a specific purpose, and its permission scope reflects that original intent — not necessarily a scope reviewed against the possibility that an agent, rather than a predictable button click, will decide when to invoke it.

Concretely, this matters because:

1. A Flow or Apex action can run in system context, meaning it executes with elevated permissions regardless of the invoking user's own access, depending on how it was configured. An Agentforce agent triggering that action inherits whatever elevation the Flow or Apex class was built with, which can be considerably broader than the conversational permissions the agent otherwise appears to operate under.
2. External API calls from a custom action leave Salesforce's own trust layer and audit logging behind the moment data crosses into the external system, similar to how an external function call leaves a data platform's native governance perimeter. The receiving system's own security posture, not Salesforce's, governs what happens to that data next.
3. A natural-language interface makes invocation less predictable than a fixed UI. A button in a page layout is invoked deliberately, by a user who knows what it does. An Agentforce action can be triggered by how the agent interprets a conversational request, which means testing an action's permission scope requires thinking about what a manipulated or unexpected input could cause the agent to invoke, not just what a well-intentioned user would ask for.

A comparable industry incident worth learning from

The ServiceNow Now Assist agent discovery incident is a documented case, on a different platform, of exactly the composition risk that matters here: a low-privilege trigger recruited a higher-privilege agent to perform actions the original invoker's role should not have permitted, and the exploited behavior was a configuration and privilege-design gap rather than a patchable bug. The specific feature involved — agent-to-agent discovery — is not identical to Agentforce's custom action model, but the underlying question generalizes directly: when a low-code orchestration layer lets one component recruit or trigger another, does an explicit authorization check govern that handoff, or does the recruited component simply run with whatever privilege happens to be available? Any organization building custom Agentforce actions should test for that pattern specifically rather than assuming it does not apply because the feature names differ.

A governance checklist for Agentforce custom actions

Beyond Salesforce's native trust layer

The generic layer this comparison keeps landing on — a cross-platform agent inventory, identity mapping from a Salesforce credential to whatever an agent's custom actions use downstream, and a unified audit trail spanning Salesforce and external systems — is the same shared control set covered in what is an AI control plane, and it applies to Agentforce without much platform-specific texture. What is specific to Agentforce is narrower and matters more:

• Auditing the agent user itself. Every Agentforce agent's backing agent user should be documented and its permission sets reviewed on the same cadence as a privileged service account, since — unlike a human's access — nothing prompts a periodic review of an agent user by default. Building an AI agent inventory covers what a record needs to capture, including which agent user backs which agent.
• Inventorying every custom action, Flow, and Apex integration reachable by an Agentforce agent, with execution context and external call targets documented alongside the agent user review above.
• Explicit authorization checks at delegation points, rather than relying on implicit trust between an agent and the automation it triggers — the same structural fix relevant to the ServiceNow pattern below. The confused deputy problem in AI agents covers this pattern generally.
• Monitoring for shadow Agentforce deployments built by teams outside central IT oversight, since low-code agent building tends to proliferate faster than governance review cycles. The rise of shadow AI covers why this pattern is common across low-code and no-code agent platforms generally.

What good looks like

1. The agent user backing each Agentforce agent is documented, and its permission sets are reviewed with the same rigor as any privileged service account.
2. Every custom action reachable by an Agentforce agent is inventoried with its execution context — system or user — explicitly documented.
3. External API calls from custom actions are reviewed against the receiving system's own security posture, not assumed to inherit Salesforce's trust layer protections.
4. Custom actions are tested against manipulated conversational inputs specifically, not just expected user requests.
5. Explicit authorization checks govern any point where one Agentforce component triggers another with elevated privilege.

Agentforce's core conversational and standard-object governance is a legitimate extension of Salesforce's mature permission model, provided the agent user each deployment runs as gets the same scrutiny a privileged human account would. The custom actions layer — Flows, Apex, and external API calls wired into an agent's topics — is where that maturity has to be deliberately extended rather than assumed, because it is where the platform's own trust layer stops being the thing that decides what happens next.

Common questions

Does an Agentforce agent operate under the permission set of the person talking to it? No. An Agentforce agent runs as its own dedicated agent user, and that user's assigned permission sets and profile — configured independently of any human's access — govern what CRM data and actions the agent can reach. Confirming which agent user backs a given agent, and what that user's permission sets actually grant, is the starting point for governing an Agentforce deployment.

Does the Salesforce trust layer protect against a custom action with an over-broad permission scope? No. The trust layer is focused on what data reaches the underlying language model and on masking sensitive fields before that exposure, plus providing an audit record of the interaction. It does not review or constrain what a Flow, Apex class, or external API call configured as a custom action is permitted to do once the agent decides to invoke it — that is a separate review responsibility.

Is a narrowly scoped agent user permission set enough to prevent an elevated-privilege custom action? It constrains what the agent user can do directly, but a Flow or Apex action configured to run in system context executes with its own elevation regardless of the agent user's permission set. Reviewing the agent user's permission set without separately reviewing each custom action's execution context leaves that elevation unchecked.

How is this different from the ServiceNow Now Assist incident? The specific mechanism differs — that incident involved agent-to-agent discovery recruiting a more privileged agent, while Agentforce's risk concentrates in the agent user's own permission scope plus custom actions invoking Flows, Apex, or external APIs with their own privilege. The underlying question is the same: when one component in a low-code orchestration layer triggers another, does an explicit authorization check govern that handoff, or does the recruited component simply run with whatever privilege was already configured.

What is the highest-priority thing to review first in an existing Agentforce deployment? Start by identifying which agent user backs the Agentforce agent and confirming its permission set is scoped narrowly — that is the foundation everything else sits on. Then move to any custom action configured to run a Flow or Apex class in system context, since that is where effective privilege can exceed what the agent user's permission set alone suggests. Cross-reference that list against which of those actions can be triggered by a request pattern an external user, not just an internal employee, could plausibly generate.