Guide
How to Manage AI Agent Permissions in Salesforce
Managing AI agent permissions in Salesforce means separating who builds an agent from who talks to it, and from what the agent itself is allowed to touch.
To manage AI agent permissions in Salesforce, assign the 'Manage AI Agents' system permission to administrators who build and configure agents in Agentforce Builder. For end users, create a permission set, open its Agent Access section, and move each agent from 'Available Agents' into 'Enabled Agents' before assigning that set. Salesforce also creates a dedicated user record for every agent, licensed under the Agentforce User License, so the agent's own reads and writes are restricted by standard profile, sharing, and field-level security settings, the same way a human user's are.
Three different permissions, not one toggle
Salesforce splits agent access into three separate decisions, and conflating them is the most common mistake. There is the permission to build or edit an agent, the permission for a human to talk to an agent that's already built, and the permissions the agent's own user record carries when it acts on data.
Agentforce is Salesforce's platform for building and running these agents. It absorbed Einstein Copilot in January 2025, which today ships as a specific agent called Agentforce (Default) rather than a standalone product, and Salesforce's release notes were explicit that the change affected permissions and UI labels, not the underlying functionality.
Keeping those three decisions separate is also what makes an Agentforce deployment auditable. If a support rep can suddenly reconfigure an agent's instructions, that is a sign the three layers got collapsed into one.
- Decision one: who can build or edit an agent.
- Decision two: who can open and talk to an agent that already exists.
- Decision three: what the agent's own user record is allowed to touch.
Granting the build permission
Administrators need the 'Manage AI Agents' permission to open Agentforce Builder and create or edit an Agentforce Employee agent. If you're managing the Agentforce (Default) agent specifically, the one that replaced Einstein Copilot, you need 'Manage AI Agents' plus a second permission on top of it, 'Manage Agentforce Default Agent.'
Salesforce's own guidance is not to hand these permissions to individual profiles directly. Bundle them into a Permission Set Group instead, so you can see at a glance who can touch agent configuration, and pull the whole group in one step when someone changes roles.
This permission also gates the Agentforce Testing Center, where you define test criteria for an agent and review how it responded, which needs 'Manage AI Agents' alongside the permission for that agent's type, or the broader 'Customize Application' permission.
- 'Manage AI Agents' is required to build or edit an Agentforce Employee agent.
- The Agentforce (Default) agent, the renamed Einstein Copilot, needs 'Manage Agentforce Default Agent' in addition.
- Bundle these into a Permission Set Group rather than a profile, so access is easy to audit and revoke.
Granting end users access to an agent
An agent that's built and active is still invisible to your workforce until you explicitly open it up. That happens through a permission set's Agent Access section, not through the build permission above.
In Setup, create a permission set for the users who should reach this agent. Under the Apps section, open Agent Access, find the agent in the 'Available Agents' column, and move it into 'Enabled Agents.' Save, then assign that permission set to the relevant users. If the agent still doesn't show up, check that it's Active rather than Draft; a draft agent won't appear correctly even to a permission set that lists it.
This lets you run several specialized agents side by side, a sales assistant and a support agent, say, and give each department only the one it actually uses.
- Agent Access lives under the Apps section of a permission set, separate from system permissions.
- Move the agent from 'Available Agents' to 'Enabled Agents,' then assign the set to your users.
- An agent stuck in Draft status won't resolve correctly even in a permission set that lists it.
What the agent's own user record can touch
Every agent you create gets a dedicated Salesforce user record of its own. That record is not a shortcut around your security model, it's subject to the same sharing rules, field-level security, and object permissions as a human user. Salesforce licenses that record today under the Agentforce User License (in an org that hasn't been updated recently, you may still see this called the Einstein Agent license, an older name for the same idea).
This is where least privilege actually gets enforced. If an agent is meant to summarize support cases, give its record read access to Case and related Contact fields, and nothing else. If someone asks the agent to pull a financial record it has no access to, the standard Salesforce security model blocks it, the same way it would block a human user without that access.
Verify this in the Agentforce Testing Center rather than assuming it. Run the test scenarios you've defined and check the actual responses against what the agent's permissions should and shouldn't allow.
- An agent's user record follows the same sharing rules and field-level security as a human user.
- Give an agent's record read access only to the specific objects and fields its job requires.
- Confirm the boundary in the Agentforce Testing Center instead of assuming the permission set is correct.
Permissions for actions and outside connections
An agent can do more than read data if you let it. Every action it can take, updating a record, sending an email, triggering a Flow, has to be explicitly added to its configuration. An action that isn't on that list simply isn't available to the agent, regardless of what a user asks it to do.
When an action needs to reach outside Salesforce, Agentforce uses the same Named Credential and External Service pattern any other Salesforce integration uses. The agent's permission set needs explicit access to the external credential principal behind that connection, which keeps the authentication details separate from the action's own code.
Setup with Agentforce, a natural-language assistant for Setup tasks, can help you navigate permission sets and Flow configuration if you'd rather describe what you want than click through menus. It needs its own 'Use Setup with Agentforce' permission, and it's a navigation aid, not a replacement for actually reviewing what you've configured.
- Every action (record update, email, Flow) must be explicitly added to an agent's configuration before it can run.
- Outbound calls go through Named Credentials and External Services, gated by external credential principal access.
- Setup with Agentforce helps you navigate configuration by description; it doesn't replace reviewing the configuration itself.
Local coding agents are a different problem entirely
Everything above governs agents that run inside Salesforce. It has no bearing on the coding agents your developers run locally to write Apex, build Lightning Web Components, or script data migrations with the Salesforce CLI (sf). Those agents need their own credentials, and Agentforce permission sets don't touch them.
A local coding agent that reads your project to understand it will also read a `.env` file or a hardcoded client secret sitting in that project, because reading broadly is how it does its job. If that session's transcript is ever shared or synced, your org's deployment credentials go with it.
The fix is the same one that applies to any local secret: get it out of the project directory. Authenticate the Salesforce CLI with `sf org login web`, which runs an OAuth flow in your browser and stores the resulting token in your OS credential store rather than a file, or use a vault tool that injects the secret only for the command that needs it.
- Agentforce permissions govern agents inside Salesforce; they do nothing for local coding agents writing Salesforce code.
- A local agent will read a `.env` file or a hardcoded client secret the same way it reads any other project file.
- `sf org login web` stores your session in the OS credential store instead of a plain-text token in the project.
Where Forkbench fits, and where it doesn't
Forkbench is a desktop app for macOS that runs local coding agents in a terminal. It has no connection to Salesforce and does not manage Agentforce permissions; that part of the job is entirely Salesforce's. What Forkbench solves is the second problem above: how a local agent authenticates to your org without ever reading the credential itself.
Forkbench's Vault stores a Salesforce connected-app secret or CLI token in your macOS Keychain. The agent references it by name when it runs an `sf` deploy command, and the value is applied at the moment the command executes rather than sitting in a file the agent can open. One real limit: an unpinned Vault key can still be read by the program the command actually runs, so the protection covers the agent's own context, not the deployed code itself.
Forkbench also offers an opt-in folder lock that keeps an agent confined to the directories you choose. It restricts the file system only. It does not restrict the network, so a locked-down agent can still reach Salesforce's API over the internet if the command you're running needs to.
- Forkbench runs local coding agents; Salesforce's own permission sets govern anything inside Agentforce.
- The Vault keeps Salesforce deployment secrets out of the project folder and the agent's transcript.
- An unpinned Vault key is still readable by the program that runs; the folder lock bounds files, not the network.
Related: Give an agent deploy access without the credential, Stop coding agents reading your .env file, How Forkbench handles your local secrets, Download Forkbench for Mac
Frequently asked
What permission do I need to build an agent in Agentforce Builder?
'Manage AI Agents.' If you're managing the Agentforce (Default) agent specifically, the one that replaced Einstein Copilot, you also need 'Manage Agentforce Default Agent.'
How do I give a specific user access to an agent?
Create a permission set, open Agent Access under the Apps section, move the agent from 'Available Agents' to 'Enabled Agents,' and assign the set to that user.
Does an agent use its own permissions or the calling user's?
Both. The agent's dedicated user record has its own profile, sharing rules, and field-level security, and the human invoking it still needs access to use the agent at all.
Is there a Salesforce feature for testing an agent's permissions before go-live?
Yes, the Agentforce Testing Center. It needs 'Manage AI Agents' plus the permission for that agent's type, or 'Customize Application,' and lets you run defined test scenarios against the agent.
Can Forkbench manage my Salesforce Agentforce permissions?
No. Forkbench runs local coding agents on your Mac and has no connection to Salesforce. It can store a Salesforce deployment token in its Vault so a local agent uses it without reading the value.