Securing Salesforce Agentforce

Salesforce Agentforce security starts with one uncomfortable fact: an agent does not query your org as the person talking to it. It queries as its own assigned running user. When a sales rep asks an agent to "summarize the top deals at risk this quarter," the agent reads Opportunity records as its service account, which is frequently provisioned far wider than the rep. The agent hands back data the invoker could never have pulled from a standard report.

Take the hero case. An Agentforce agent is stood up to summarize deals, and its running user is a service account that can read the entire Opportunity object: every stage, every amount, every close date, across every team. That is not a misconfiguration in the platform's eyes. It is exactly how the running-user model is designed to work. But it means the agent's effective access becomes the ceiling for every invoker, not the floor.

Agents inherit whatever the running user holds, and admins tend to over-provision during rollout for convenience. Security sees it much later. Default access patterns worth auditing on day one:

• Read access to whole standard objects (Opportunity, Contact, Case, Account)
• Access to custom objects that hold regulated or contractual data
• Field-level access to compensation, pricing, or margin fields
• Related-list access that quietly expands the reachable data graph
• API access that lets the agent call external systems

The question that matters is not "what does the config page say." It is "which service account is this agent, and which objects and actions can that account actually reach right now."

The running-user model is the largest single source of privilege escalation in Agentforce today. Two patterns cause most of the damage.

Pattern one: a service user with admin-adjacent permissions. An agent runs as a dedicated service account carrying "View All" on Opportunity or "Modify All" on Case. A support rep invokes the agent to look up a customer and the response returns revenue figures or executive escalation notes the rep was never entitled to see. The agent did nothing wrong. It answered as the identity it holds.

Pattern two: Apex or Flow in System Mode. Agentforce actions built on Apex classes running in System Mode bypass user-level sharing entirely, and the same holds for Flows set to run in System Context. Anyone who can invoke the agent can trigger those actions with system-level reach. This is the maker mode problem in Agentforce clothing: whoever built the automation baked their own privilege into it, and every later invoker inherits it.

This is the confused-deputy shape. The agent is not malicious, and no single log line looks wrong. What is missing is anyone checking whether the invoker should have been allowed to trigger that action against that data at all.

Ask most admins how many Agentforce agents they run. The answer is usually off by an order of magnitude. Sales ops built one, service ops built three more, marketing switched on a templated agent, and a managed package quietly shipped two more. You cannot govern what you cannot see, so inventory comes before every other conversation.

Discovery has to resolve, per agent:

• Identity: name, purpose, and publisher (first-party build vs installed package)
• Owner: who created it, whether that person is still active, and whether they still work here
• Running user: the exact service or human identity the agent operates as
• Actions: the Apex, Flows, prompt templates, and API calls it can invoke
• Channels: where it is exposed (internal chat, web, Slack, external customer surface)
• Usage: whether it is actually being used, and by whom

Orphaned agents are the common trap. A sales enablement lead builds an agent, changes roles, and leaves. The agent keeps running under a service account no one maps to a business owner. It is the stale service account problem carried into the agent era, moving faster and reaching wider. The Salesloft Drift campaign attributed to UNC6395, which reached roughly 700 organizations through connected Salesforce integrations, is a plain reminder that a forgotten machine identity with live access is not a low-severity item.

Configuration is not reality, and that gap is the whole game. The Salesforce profile view shows theoretical configuration: object permissions, field-level security, sharing settings on paper. What it does not show is effective access, the actual rows and objects the agent can reach once every permission set, sharing rule, role hierarchy, group membership, and Apex context resolves at runtime.

Two agents can look identical on the config screen and behave nothing alike. One sits under a permission set group that grants "View All" on a custom object full of PII. The other does not. The profile page never surfaces that. Runtime behavior does. Mapping effective access means correlating:

1. The agent's assigned user identity
2. Every permission set and permission set group on that user
3. Sharing rules, criteria-based sharing, and manual shares
4. Role hierarchy and group membership
5. Apex and Flow execution context (System vs User)
6. External credentials reached through named credentials or connected apps

Done by hand across a large org, this does not hold up. Done for every agent, every week, it is impossible without tooling. The point is to tie an agent's real activity back to its effective access inside Salesforce, which service account it is, which objects and fields that account can touch, and which actions it can fire, rather than trusting a static configuration page.

Effective governance needs a small set of deterministic policies applied the same way everywhere, not artisanal per-agent review. A workable baseline:

Ownership. Every agent has a named human owner. When that owner is disabled, the agent is flagged for review inside 24 hours, and orphaned agents are quarantined rather than left running.

Least privilege. No agent runs as a user with "View All" or "Modify All" on any standard object without written business justification and recurring recertification.

System Mode control. Apex and Flow in System Mode require security review before deployment, and existing System Mode automations reachable by agents are inventoried and risk-scored.

External exposure. Any agent exposed to unauthenticated or external customer channels carries tighter object and field limits than internal-only agents.

Credentials. No hardcoded secrets in agent metadata. Credentials rotate on a schedule and are not shared across agents.

The reason to write these as policies rather than run ad-hoc reviews is that each one translates into a detection rule, a repeatable query against the agent inventory that produces evidence on its own instead of waiting for the next audit.

Anti-patterns that keep recurring

The same mistakes show up across enterprise deployments:

1. Assigning one "AgentUser" service account to every agent, so a single compromise carries the whole fleet's blast radius.
2. Turning on Apex in System Mode to get past a sharing-rule inconvenience during development, then never revisiting it.
3. Treating an internal demo channel as low-risk, then reusing that same agent configuration on an external customer channel.
4. Building agents in a sandbox with admin-level permissions and shipping to production without trimming them.
5. Not tracking which prompt templates feed which agents, so one template edit silently changes behavior across the org.
6. Assuming Salesforce audit logs answer incident-response questions. They record activity but not the identity correlation you need to answer "who invoked this, and should they have been able to."

Runtime enforcement means deterministic guardrails on probabilistic agents at the moment of action: blocking a tool call, denying a data read, or forcing step-up authentication before an action completes. Today that capability ships for only a narrow set of assistants, Microsoft Copilot and Claude. For Agentforce it is future roadmap, not a present-tense feature, and it should be planned for as such.

What is available for Agentforce right now is discovery and governance:

• Discovery of every Agentforce agent across connected orgs
• Effective access mapping (running user plus permissions plus Apex and Flow context)
• Risk scoring against known factors like shared credentials, System Mode use, and hardcoded secrets
• Toxic combination detection, for example an agent that pairs hardcoded secrets with broad Opportunity read access
• Ownership and orphaned-agent tracking

What it does not yet do for Agentforce is block an action in real time. When runtime does reach more platforms, the model is not an inline chokepoint sitting in the request path. It is an "Intel Inside" decision engine: the platform enforces, and the intelligence about what to allow rides along with it. Obsidian is not an inline gateway. That distinction is why the sensible posture today is a two-phase plan, discover and govern now, add runtime enforcement when it ships for the platform.

Do you need extra tooling to secure Agentforce

Salesforce gives you the primitives: profiles, permission sets, sharing rules, and audit logs. What it does not give you is a system of record that answers, at scale, which agents exist, what each one's effective access is, and which of them break policy right now. Native tools enforce policy inside Salesforce. They do not tell you when an agent's running user picked up a new permission set last week, and they do not connect an invocation to the person who triggered it and flag that the person lacked direct access to the underlying data. That correlation across identity, configuration, and behavior is the visibility gap to close, and it is the same gap that runs across the other agent platforms in the stack. One control plane over all of them means fewer fire drills, because agents reach across those platforms whether or not your tooling does.