A service team switched on an agent to answer account questions. It worked well for a week. Then a caller who supplied nothing but an email address received another customer's contract terms back in the chat window. No vulnerability was exploited. No attacker bypassed a Salesforce control. The agent did exactly what it had been built to do: it ran as an identity that could see the contract, and it handed the contract to someone nobody had verified was entitled to receive it.
This is the first thing to understand about an autonomous agent in a Salesforce org, and the thing most teams skip in the rush to demo. An agent is not a new security model. It is a new consumer of the security model you already have. Before you tune a single instruction or shape its tone of voice, the question that governs your risk is the oldest one on the platform: who does this thing run as, and what can that identity reach?
Identity has two sides here, and the opening story fails on both. There is the identity the agent runs as, and there is the identity of the person asking it to act. For private or customer-specific requests, the design has to verify the end user and carry that verified context into everything the agent retrieves or changes. This post covers the first side. Part 3 of this series returns to the second.
That question does not care which agent you bought. Some orgs are building on Agentforce. Many are wiring external models into Salesforce instead: a custom agent, an agent platform, or a model behind their own middleware. The vendors differ. The access question is identical. It just enters through a different door.
Door one: the agent built on the platform
In Agentforce, every agent is tied to a running user: the identity whose access defines what the agent can reach and what it can do. That is not a footnote in the setup guide. It is the control plane. Anything that identity can access sits inside the agent's potential reach; the topics, actions, and retrieval paths you expose determine how much of that potential becomes real in a conversation.
Which identity applies depends on the agent type, the channel, and how users are verified. Employee agents, and agents on channels restricted to logged-in users, generally operate in the context of the authenticated user, so their exposure tracks your existing permission hygiene, good or bad. Service agents on unauthenticated messaging channels generally run as a dedicated agent user you provision: a standing service identity whose access surface is a deliberate design decision that outlives any single conversation. Authenticated experiences can instead apply the verified end user's own identity and access. The answer changes per agent, which is exactly why it has to be asked per agent rather than settled once for the org. Salesforce's own architecture guidance is blunt on one point regardless: each agent user should be unique, never reused across agents, and scoped to least privilege.
Either way, effective access starts with object and field permissions from the identity's assigned authorization, combined with record-level visibility from the sharing model, then gets shaped further by broad system permissions, session and token boundaries, and the execution context of the components the agent invokes. Agentforce does not replace that platform model. It adds a layer of its own on top: agent access permissions, user verification, and topic and action availability all govern how the underlying access can be used through the agent. The data access still rests on the standard layers, which is the good news and the trap in a single sentence.
Door two: the agent built outside the platform
The external agent looks like a different animal. It is not. Inbound, it reaches your org through OAuth against an External Client App, or one of the Connected Apps you already had before Salesforce restricted new Connected App creation by default in Spring '26. The token it presents represents either a dedicated integration identity or an end user's delegated identity, depending on the OAuth flow you chose, and that choice is itself an access decision. Outbound is a separate leg: when Salesforce calls external tools or services on the agent's behalf, Named Credentials and External Credentials govern the endpoint and the authentication. And increasingly the external agent arrives speaking MCP, which Salesforce itself now supports with hosted MCP servers that any compatible AI client can connect to. The protocol is new; the entry is not. The MCP client still authenticates through OAuth and acts as an authorized identity, which is this post's whole point wearing a new transport. These are the same components that anchored my dependency graph series, and an external agent inherits every governance problem that series described, plus a new one. A traditional integration executes the queries a developer wrote. An agent decides at runtime what to ask for, within everything its identity is allowed to touch.
That changes the risk math on a pattern most orgs already have: the over-scoped integration user. An integration user with broad read access behind a middleware that only ever ran four fixed queries was a dormant liability. Put an agent behind that same identity and the dormant part is gone. The agent will use what it can reach, because reaching things is its job.
So the design questions for an external agent are the mirror image of the running user questions. Which app definition does it enter through, and with which OAuth scopes and flow? Which identity does its token represent, and what does that identity's authorization actually add up to? Is that identity shared with anything else, so that the agent's activity and some other system's activity are now indistinguishable in your audit trail? I have sat on the build side of this exact problem, integrating an external AI agent platform with Salesforce at consumer scale, and the lesson was the same one this post opened with: the model was never the risk surface. The identity was. (I wrote more about that experience here.)
The trap is the build, not the platform
Salesforce ships platform agents locked down. A new agent carries no grants of its own; its effective floor is whatever identity and permissions someone assigns to it, which in practice is often a cloned user or a template permission set rather than zero. Most teams stand up external integration users the same way, starting narrow. The defaults are correct on both paths. The problem is what happens next, and it happens the same way on both paths.
During the build, an agent that cannot see the data fails its test cases. The fastest way to make the demo work is to widen access until the answers come back. On the platform side, that is a broad permission set here, a generous sharing rule there, an org-wide default nudged from Private to Public Read. On the external side, it is an app approved for OAuth scopes broader than the integration requires, or View All Data granted to the integration user because the demo was due Friday. Those are two different widenings, and both matter: scopes broaden what the token can do with the identity's existing access, while permission grants broaden the access itself. The agent starts answering. The demo ships, and the widened access ships with it.
Now recall the identity. If the access surface is loose, the agent is not cautious on your behalf. It is helpful with everything the identity can reach. The identity that could see the contract will offer the contract. Be precise about the opening story, though, because it is the case least privilege alone cannot fix: an agent built to answer account questions must be able to read contracts, so a shared service identity carries a high access floor by design. The unmapped access surface made that leak possible. The missing end-user verification made it happen. Access is the half you can map before go-live. Verification is the half Part 3 takes up.
There is a second, quieter layer. An agent does not only read data, it takes actions, and those actions carry their own access. On the platform, an action wrapping a Flow, an Apex class, or a prompt template inherits that component's permissions. On the external path, an agent's API calls can invoke whatever its token and identity allow. So the agent's effective power is not a simple sum. It is the full execution path: identity, session and token boundaries, the topics and actions exposed to it, and the execution context of every component those actions invoke. Some of those layers constrain each other. Others quietly elevate, and the elevation mechanisms have names: on older API versions, Apex runs its database operations in system mode, ignoring the user's object and field permissions unless the code opts into user mode (Summer '26 flipped that default to user mode for classes on the new API version, which is exactly why the answer is per class, not per org); a class declared without sharing drops record-level visibility; and a Flow can be configured to run in system context without sharing. The question is never what the platform defaults to. It is which mode each component behind each action actually runs in. Nobody sees that path unless someone deliberately maps it.
Five questions to answer before go-live
If you are deploying an agent this quarter, on either path, these are the access questions that should have written answers before activation:
- What identity does the agent run as, and is that identity dedicated to this agent alone? Shared identities make attribution, agent-specific least-privilege analysis, and blast-radius assessment substantially harder.
- What is the identity's effective access? Not the intended access. The computed result of assigned authorization, the sharing model, broad system permissions, and, for external agents, the OAuth flow and scopes the token carries.
- What can each action reach beyond the agent's own identity? Every Flow, Apex class, prompt template, and API surface an action touches runs in its own execution context, and some of those contexts elevate.
- What access was widened during the build, and is each widening still justified? If nobody kept that list, the answer is discoverable, but only through a deliberate review.
- Who signs off on this access surface, by name, before the agent goes live? If the answer is "the project team," the answer is no one.
Teams that can answer all five tend to have boring go-lives. Teams that cannot are running the opening story on a delay.
Where this series goes next
Access is the front door, and it is only the first of four questions. Part 2 treats the agent as what it actually is architecturally: a new integration surface with its own blast radius, including the retrieval and grounding paths that feed it. Part 3 covers control: what the agent is allowed to say and do once it is inside, including the end-user verification question the opening story turned on. Part 4 covers accountability, who owns the agent and whether you can reconstruct what it did.
If you want the access question answered for your org before your agent ships rather than after, that is exactly what the Org Access Assessment does: a fixed-scope review of who and what can reach your Salesforce data, agents included.