Your AI agent in Salesforce has exactly the permissions of the account it runs on

How it works

Every Agentforce agent runs as a designated Salesforce user. That user has a profile, permission sets, a role, and sees records according to the sharing rules, just like any person in the system. The agent gets nothing more than that and nothing less. The same goes for assistants connected through an MCP server: calls execute as the logged-in user, respecting object, field and record permissions.

That is good news. The Salesforce security model you have built over the years still applies. AI has no back door.

Where the problem is

The problem appears at the moment you choose the user. In a small company the agent most often gets an account that is “already there” and “will definitely work”: the administrator account, or an integration account with Modify All Data. It will work. It will also be able to delete any record, change any field and send an email to every contact.

A person with those permissions usually hesitates. An agent does not. If it is told to “tidy up the duplicate contacts” and it has a delete action, it will do it. If someone in a conversation with the agent writes something the model reads as an instruction, it will do that too. Faster than a person, with no coffee break.

What to check before switching on

1. Which account the agent runs on. The agent settings show the user. If it is the administrator account or an account with Modify All Data, stop here.
2. Which actions the agent has. Read only? Create? Update? Delete? Send email? Every action that writes data should have a reason and, at the start, a person confirming it.
3. Which fields it sees. Field-level security applies to the agent too. If the account sees national ID numbers and bank accounts, the agent sees them as well and can say them out loud in a conversation.
4. Which records it sees. Org-wide defaults, roles, sharing rules. An account that “sees everything” means the agent will answer customer A with customer B’s data if the question is put badly.
5. Whether there is a log. What the agent received, what it did, who approved it. Without it you will not learn about a mistake until a customer calls.

How to set it up properly

A separate user for each agent, with its own permission set built from scratch for one task. An agent that summarises cases needs read access to cases and write access to one field. Nothing more. An agent for customers on the website needs read access to the knowledge base and the ability to create cases. It does not need to see opportunities.

Such a permission set takes an hour to build. It only requires an answer to the question of what the agent is supposed to do, and that is a question you have to ask yourselves anyway.

AI and MCP do not add permissions. They use the ones already there. If those are too broad, AI does damage faster than a person.

If you do not know which accounts your integrations and agents run on, it is the first thing I check in the free audit. It takes a 30-minute call and needs no access to your system.