When you set up an Agentforce agent, it doesn’t really feel like you’re onboarding someone new. You’re configuring topics, actions, or maybe writing a few instructions. But behind the scenes, you technically just created a user – a real one too – complete with a login, a license, and permissions of its own.
Most guides gloss right past this part, but it’s worth knowing exactly what this user is, what it can see, or how its permissions differ from a human user’s. In this article, we’re going to walk through the Agent User, the permission sets that govern it, how “running user” actually works for an agent (it’s not what you’d assume), and how to apply least privilege to something that isn’t a human.
The Agent User
When you create a new agent and choose the “New User” option, Salesforce auto-creates a user record for it.
Check that user afterward, and you’ll see it has the Einstein Agent license and Einstein Agent User profile, not a standard Salesforce license. Why, you might ask? For two reasons:
- So it doesn’t consume one of your paid user seats,
- So it doesn’t inherit anything from your existing profiles or permission set groups.
It starts essentially blank, and you decide what it can touch.
If you’re managing (or planning to manage) more than one agent, it’s also good to rename each Agent User’s first name to match its agent, since they can otherwise pile up in your Users list looking identical. You can then just filter your User list view to show those assigned the Einstein Agent User profile to make it easy to find them as a group.
Choosing to create an Agentforce Service Agent automatically assigns this new Agent User a permission set group as well: the AgentforceServiceAgentUserPsg (which contains the Agentforce Service Agent User, Data Cloud User, and Prompt Template User permission sets), along with two separate permission sets: Agentforce Service Agent Secure Base and [Agent_Name]_Permissions (mine was Support_Agent1172457834 Permissions, and the numbering will be randomized/unique to your org).
The former grants your agent basic access to Service objects such as Case and Contact, while the latter is completely empty, allowing you to add custom permissions of your own.
This out-of-the-box footprint is deliberately minimal, and Salesforce’s own way for showing how an agent is “secure by default” by starting with the ability to do almost nothing, and you expand from there based on what it actually needs. Whatever it can do has to be put there on purpose.
The Principle of Least Privilege (for a Non-Human Colleague)
With all the recently introduced security enhancements, you probably have already heard about the Principle of Least Privilege. This isn’t a new concept, and it basically just instructs you to give someone (or something) only the access it actually needs to do its job, nothing more.
It’s generally taken as best practice, but usually for human users. How do we apply it to agents, then? Does that change the stakes in any way? Well, the answer is yes, and the biggest difference lies in human vs. agent behavior.
A human with more access than they strictly need will still usually hesitate before opening a record that feels outside their lane, or think twice before acting on something ambiguous, or maybe even just ask someone first. That feeling of hesitation isn’t really a formal control, and an org’s admin does not dictate this. Nobody designed it on purpose – it’s just what people do.
An agent, on the other hand, doesn’t have that instinct. If it has access to something, it uses that exactly as instructed, and at whatever speed or volume your automation allows it to run. It does not pause, nor second-guess, nor stop to ask if it should even be looking at a certain record.
Over-permissioning a person is still a risk, of course, but doing the same to an agent only makes that risk more severe because it can run unattended and at scale for every conversation it has.
This makes more sense of why the Agent User is a blank-slate default. Salesforce has built in the least-privilege principle into the model from day one, so that whatever the agent can eventually do has to be something an admin deliberately chose to grant it.
The Permission Sets
Looking at all the permission sets involving Agentforce can get pretty overwhelming.
The way I’ve found it useful to think about them is by what they actually govern. These permission sets can be categorized into three rough buckets:
- Access permissions: who can see and use an agent at all?
- Management permissions: who can build, edit, or configure an agent?
- Execution permissions: what can the agent do and touch when it runs?
These permission set names can get long and confusing as they seem similar at times. However, they are not to be treated as interchangeable. You wouldn’t want to mix them up and assign a “management” permission set to an Agent User, or an “execution” set to the human admin – they control different sides of the relationship!
Keeping these three categories distinct in your mindset and naming conventions will surely save a lot of confusion later on. It’s good that Salesforce has already included a description for each, so you know exactly what it does or what it’s for.
The Running User
Or, in simpler words, who is the agent acting as? Salesforce’s own help doc draws the distinction by end-user type, and it’s specific to Service agents (the ones connecting to channels that aren’t restricted to logged-in users, like Enhanced Messaging, for example). I can simply say what the three tiers are and how they differ, but connecting three situations using a single scenario might help visualize things better.
Scenario: Imagine a shopper named Jill messages your company’s chatbot to ask, “Where’s my order?“
- Jill hasn’t proven who they are at all (unidentified end user): They just opened the chat window and started typing the question. Your agent has no idea if this is really Jill or someone else entirely. In this case, the agent runs as itself, using its own login (the Agent User) and its own permissions to answer the question. Jill is treated as a random visitor.
- Jill types in an order number and their email, and the bot confirms it matches (identified or verified end user): Jill is now “verified” in the sense that the bot believes it’s really them. However, take note that this does not change who the agent is acting as. The agent is still running as itself, using its own permissions, exactly like Scenario 1 above. Verifying Jill’s identity told the agent WHO the person is, but does not change WHAT the agent is allowed to look at.
- Jill is logged into your company’s customer portal with an actual account, and messages the bot from inside that logged-in session (authenticated user): Now, and only now, the agent runs as Jill. It uses Jill’s own account permissions and not its own. Jill has access to all the objects she’s supposed to.
The authenticated user can sometimes be confused with the identified or verified user, but remember that someone’s identity does not move them into that third tier. An identified user who’s confirmed themselves via OTP is still, from a data-access standpoint, running on the Agent User’s permissions rather than their own. Confirming who someone is and controlling what they can see turn out to be two completely separate mechanisms.
Identity Isn’t Access
This is what makes the second scenario above particularly dangerous. In that instance, Jill is verified, and the system does know Jill’s identity and stores it in something like a “who is this” tag behind the scenes. But knowing who Jill is doesn’t automatically mean the agent only shows Jill her own stuff.
If we were to use a metaphor, think of it like a delivery driver who’s confirmed your name at the door, but has the master key to the whole building. Doesn’t make much sense, right?
Confirming your identity and restricting what they can access are two completely separate things. So unless someone specifically built in a rule that says “only show records that belong to this verified person”, the agent that’s running on its own permissions could technically pull up any customer’s order, not just Jill’s. It knows Jill’s name, but nothing is stopping it from fetching someone else’s data if asked the right way.
Now that we’ve got that common assumption out of the way, the fix Salesforce recommends is basically a three-part fix, and it has to be built deliberately. First, capture the verified identity into the VerifiedCustomerId variable (the standard Customer Verification and Service Customer Verification subagents handle this for you, and if you’re not using either, you’ll need a custom action to do it).
Second, wire that variable into the Apex or flow behind any action touching customer records, something like WHERE ContactId = VerifiedCustomerId. This is the part that adds security. Third, add a filter at the subagent or action level, using a condition like VerifiedCustomerId is None, so an unverified conversation can’t even reach the actions that require it in the first place.
Some of Salesforce’s built-in actions already do this check automatically, but if you’re bound to make custom ones, it’s a good thing to keep in mind as best practice.
Summary
Far from simply being a feature you toggle on, agents should be considered as a new user. It’s technically another “person” in your org with its own license as well as its own access to your data. Every piece of this article I’ve discussed above – the Agent User, its permission sets, the running user differences – all comes back to that one idea.
The good news is that Salesforce has already built a lot of the hard part. Agent Users start blank, and verified identity gets passed along as a variable specifically so you can build real restrictions around it, if you choose to.
The part left for you to work on is the deciding: what an agent can see, touch, or do is still a judgment call that belongs to the person configuring it. If you are to take home one big lesson from this article, it’s that you should treat that judgment call with the same weight you’d give to onboarding an actual new hire. You wouldn’t hand a new hire the keys to everything on day one, would you? So don’t do it for your agent either.
