Your Salesforce permission model just became your AI policy
Dreamforce 26 was full of big announcements. AIforce, Slackforce, Claudeforce, Agentforce: our product naming matrix had a busy week. But one line in Salesforce's AIforce announcement deserves more attention than it got.
Salesforce explained that with AIforce, every request runs on existing permissions and business rules, so every agent sees only what the person asking can see, and every action routes back through Salesforce.
That is excellent design. It means the security model you already have carries straight through to AI, wherever people and agents are working. It also means something practical for every Salesforce team: your permission model is now doing a second job. It is deciding what your AI can see and do.
Why this is good news
A lot of organisations worry that AI will need a whole new security layer. For Salesforce customers, the answer is largely the opposite. The profiles, permission sets, sharing rules and field-level security you have spent years building are the controls that matter.
That is a real advantage. You do not have to invent AI governance from scratch. You have to make sure the governance you already have is doing what you think it is doing.
The catch: most permission models have drifted
Permission models rarely stay tidy. Over a few years, most orgs pick up:
users with more access than their role needs, granted to fix an urgent problem and never removed
permission sets that overlap, with nobody quite sure which one grants what
sharing rules added for a project that ended long ago
integration users with broad access "just to make it work"
sensitive fields visible to far more people than necessary
When only people were using that access, the impact was limited by how much any one person clicked through. When an agent can search, summarise and act across everything a user can see, loose permissions matter a lot more. The agent is not doing anything wrong. It is faithfully respecting a permission model that no longer reflects your intent.
A practical review checklist
Here is the order we work through when reviewing a permission model with AI in mind.
1. Start with least privilege
For each role, ask what access people genuinely need to do their job, then compare it to what they have. Salesforce's direction of travel is permission sets and permission set groups rather than heavily customised profiles, and moving that way makes least privilege much easier to manage.
2. Untangle overlapping permission sets
List your permission sets and permission set groups, what each grants, and who holds them. Retire duplicates and give each one a clear owner and purpose. If you cannot explain why a permission set exists, that is a sign it needs a look.
3. Review your sharing model
Check organisation-wide defaults, role hierarchy, sharing rules and manual shares. Old sharing rules from finished projects are one of the most common sources of unintended access.
4. Tighten field-level security on sensitive data
Identify the fields that hold sensitive personal information and confirm who can see and edit them. This also supports your work on the new automated decision-making rules that start on 10 December 2026, where knowing what personal information your programs use is part of what your privacy policy has to describe.
5. Check Data 360 access
If you use Data 360, review data spaces and who can access which unified profiles and segments. Data 360 is where customer data comes together, which makes it one of the most valuable places to get access right.
6. Look hard at integration and system users
Integration users often have wide access because it was the quickest way to get something working. Scope them to what each integration needs, and document the reason for anything broad.
7. Decide what agents are allowed to do
If you are using Agentforce, be explicit about which actions each agent can take and which users it acts for. Agentforce is powerful, and it works best when the rules underneath it are clear.
Who should own it
A permission review works best as a shared job between your Salesforce platform owner, your security team and the business owners of each area. The platform owner knows how access is built. The business owners know what access people actually need. Security makes sure it lines up with policy.
Once the review is done, keep it alive. Set a review rhythm, make access requests go through a simple approval, and record why exceptions exist. The goal is a permission model your own team understands and can maintain, without calling in help every time something changes.
The upside of getting it right
A clean permission model does more than reduce risk. It makes every new Salesforce capability easier to adopt, because you can switch things on with confidence. It makes audits faster. And it means that when your people start working with AI in Slack, in Claude or anywhere else AIforce reaches, what they see is exactly what they should see.
If you would like a hand reviewing your permission model, talk to us. We will work through it with your team and leave you with a model you can run yourselves.
#sustainablestacks
