Do Agentforce agents bypass Salesforce sharing?

Every security conversation about Agentforce starts with the same question: do the agents bypass our sharing rules? The short answer is no — and understanding why explains both why Agentforce is safe by design and where the real risk lives.

Agents run as a user — and inherit that user’s access

An Agentforce agent doesn’t have its own magic view of your data. It executes as a Salesforce user, and every data retrieval it performs is checked against that user’s:

• Object permissions (profile + permission sets)
• Field-level security
• Record-level sharing — org-wide defaults, role hierarchy, sharing rules, manual and implicit shares

If the running user can’t see a record, the agent can’t either. Agentforce operates inside the same enterprise security model — profiles, permission sets, sharing, role-based access — that governs the rest of your org. It also supports attribute-based policies on top, for rules like “only EU sales agents can trigger this workflow.”

Agentforce agents don’t bypass Salesforce permissions. They aggressively use whatever access already exists.

That second sentence is the whole story.

The real risk: amplified exposure, not bypass

Here’s the uncomfortable part. Most orgs have far more open sharing than anyone remembers configuring — years of sharing rules, broad permission sets, role-hierarchy roll-ups, and “temporary” manual shares that never got removed.

A human almost never bumps into the full extent of what they can technically access. They open the records they work on and ignore the rest. An agent doesn’t. Ask it a question and it will retrieve, join, and summarize everything within the running user’s reach — including data that user forgot they could see.

So the agent doesn’t grant new access. It surfaces the access you already had, conversationally, instantly. Over-broad sharing that was latent for years becomes a one-sentence prompt away.

Why agents change the risk math

Two things make this different from a person with the same permissions:

1. Speed and scale. An agent reads and combines records far faster than any human, so a mis-scoped permission is exploited immediately and repeatedly.
2. No approval checkpoint. Once deployed, agents act on configuration and context without pausing for human review — removing a checkpoint the traditional security model quietly relied on.

The permission model didn’t get weaker. The thing using it got far more thorough.

What to do before you deploy

The fix isn’t to distrust Agentforce — it’s to know what its user can see before you turn it on:

1. Run an access review for the agent’s running user — at object and record level. The relevant question is the same one this whole blog is about: who can see what, and why. For a step-by-step playbook, see auditing record access before you deploy an AI agent.
2. Tighten the baseline. Set org-wide defaults as restrictive as the business allows; access only widens from there.
3. Prune sharing rules and permission sets. Remove the broad, stale grants the agent would otherwise inherit.
4. Give the agent its own least-privilege identity rather than a broad human profile, plus attribute-based policies.
5. Re-check after every sharing change — access drifts, and so does what the agent can reach.

Knowing what the agent can see — in plain English

Steps 1 and 5 are the hard ones: reconstructing a user’s true effective access across CRUD, field-level security, and six sharing mechanisms, then keeping it current as the org changes.

That’s precisely what AgentForceAccess does. Ask, in plain English, what a user — or your agent’s running user — can actually see, and it traces every grant and cites the mechanism behind it. It’s the access review that turns “we think the agent is scoped correctly” into “we know it is” before you deploy.

Frequently asked questions

Do Agentforce agents ignore sharing rules and run as admin?

No. An agent executes as a specific Salesforce user and is bound by that user's profile, permission sets, field-level security and the record sharing model. It cannot see records that user could not see. If the running user is over-privileged, however, the agent inherits that over-privilege.

So why is AI access considered a security risk if it respects permissions?

Because most orgs have accumulated more open sharing than anyone realizes. A human rarely stumbles onto every record they technically can access; an agent will happily retrieve and summarize them on request. The agent does not create new access — it exposes the access you already had.

What is the single most important thing to do before deploying an agent?

Audit what the agent's running user can actually see — object by object, and at the record level. Tighten org-wide defaults, sharing rules and permission sets so the user (and therefore the agent) has only the access it needs, then deploy.

Can I give an agent narrower access than the user running it?

Yes. Provision a dedicated, least-privilege user or permission-set configuration for the agent rather than reusing a broad human profile, and layer attribute-based policies on top. The agent should have the minimum access required for its task.