AIforce Respects Your Permissions.
Are Your Permissions Worth Respecting?
Salesforce is bringing CRM into more AI interfaces. That makes the business justification behind every permission harder to ignore.
The permission nobody removed
A sales operations employee helps another team for three months. They receive an additional Permission Set Group, finish the assignment and return to their normal role.
The extra access stays.
Later, the organisation connects an approved AI client to Salesforce. The employee asks it to summarise accounts through an enabled tool. If that tool can retrieve the relevant records and fields, the old assignment may allow information from the previous role into the answer.
No stolen credentials are needed for this example. No security bypass is assumed. The organisation has simply continued to authorise access it no longer intends.
If AI follows your access model correctly, does the result still match the person’s current job?
What AIforce changes
AIforce is Salesforce’s strategy for making its data and business processes available through AI interfaces. The Headless Toolkit supplies mechanisms such as MCP servers, APIs and developer tools. Salesforce in Claude, Slackforce and Agentforce Coworker are related experiences within that strategy. [1]
The architectural shift creates more ways to request work against an existing Salesforce configuration. Our analysis: permissions that were rarely exercised through a familiar screen can become relevant to a new conversational workflow.
That does not mean every AI client can access everything a user can access. Available tools, OAuth scope, server configuration, action logic and the actual execution context also constrain what can happen.
Salesforce Hosted MCP Servers are disabled by default. An administrator enables the servers needed for the use case. AIforce is not an automatic exposure of every org to every external AI tool. [2]
“It uses your permissions” needs context
Start by identifying which identity actually performs the work. Salesforce documents different execution models, including the following. [3]
| Access path | Identity to examine | Governance focus |
|---|---|---|
| Employee agent | Logged-in employee | Current role, assigned access and exposed actions |
| Service agent without credential-based user verification | Dedicated agent user | Agent-user access and verified-customer record scoping |
| Service agent with supported credential-based user verification | Logged-in site user | Supported channel, verification configuration and user access |
| Custom Flow or Apex action | Running identity plus implementation context | Authorisation checks, data scope and privileged operations |
For a Service agent running as its dedicated user, passing a contact ID as a context variable does not itself enforce customer-level data access. Salesforce explicitly calls for scoping actions and queries to the verified customer. [3]
For Salesforce Hosted MCP Servers, the current security guidance describes user-authorised connections and user attribution, with controls for read-only servers, Named Queries and client restrictions. Those are useful controls to evaluate alongside permission assignments. [4]
Review the action behind the answer
An agent’s entry identity does not tell you everything about the automation it invokes.
Salesforce Flow can run in user or system context. System context with sharing respects record-sharing controls but does not enforce the running user’s object permissions or field-level access. System context without sharing has broader access. Review the flow type, launch path and configured context. [5]
Apex requires the same care: with sharing concerns record-level access; it does not by itself enforce object and field permissions. API version and database access mode matter. Salesforce recommends explicit access modes to make behaviour easier to maintain across versions. [6]
Salesforce’s agent-action guidance also recommends verifying users for private actions and limiting public responses to necessary fields. Test the action with the identity that will really invoke it. [7]
Use an ordinary employee account. Ask for a permitted record, a restricted record and a restricted field. Then test an action with elevated backend logic. Confirm both successful work and expected refusals. A successful administrator demonstration does not establish these boundaries.
Separate today’s controls from Agentic Identity plans
The 12 November explainer describes Agentic Identity as forthcoming. Salesforce’s separate impact notice discusses planned registration, discrete agent identities and narrower permissions, with migration requirements tied to availability notices. A target month is not proof that a feature is generally available in every org. [1] [8]
Our view: separate agent credentials would add a valuable control boundary. They would still need an owner, an approved purpose, an access scope and a removal process. Creating an identity and governing its lifecycle are different tasks.
Salesforce in Claude is labelled Beta in the documentation reviewed. Salesforce says data handling after information reaches Anthropic through MCP is governed by the organisation’s Anthropic contract. Check the terms of the actual external service you enable. [9]
Make access review part of AI readiness
Before expanding an AI use case, attach an access review to the rollout:
- Identify the actor. Record the employee, agent or integration identity used by each action.
- Explain the access. Confirm the current persona, business need and owner of sensitive assignments.
- Revisit exceptions. Remove obsolete role access and reassess temporary or privileged access.
- Constrain capabilities. Expose only the tools and data needed for the task.
- Test and retain evidence. Capture authorisation decisions and verify restricted requests fail safely.
- Prepare to stop access. Document the relevant client, token, user and action controls.
Salesforce’s headless-governance guidance also stresses monitoring and incident response across the systems involved. Its monitoring boundary is Salesforce; a request can cross other tools before or after that boundary. Access-review evidence and runtime activity logs answer different questions. [10]
Where access governance fits
This is the connection to Sforce.ai’s UAG approach: persona-based access, approval-controlled changes, joiner/mover/leaver processes and recurring recertification address why a Salesforce user should retain access.
That user-access governance complements Salesforce’s native AI security controls. It does not establish that UAG currently registers Agentic Identities, inspects prompts or controls OAuth tokens.
A correctly enforced permission can still be the wrong permission.
AI readiness should include asking whether the access behind the interface remains justified today.
Before AI acts on someone’s access, make sure that access still belongs to them.