Salesforce AIforce Security: Are Your Permissions Ready for AI Agents?

Salesforce permissions were built around a simple assumption: a human logs in, and whatever they can see and touch depends on their profile, their role, and the sharing rules underneath. AI agents break that assumption in a quiet but significant way. Software can now retrieve information, reason over it, and take action on its own. Often nobody’s watching that specific request happen. Salesforce AI is expanding fast enough that most orgs haven’t stopped to ask a basic question: is the permission structure we already have actually built for this?

That’s the real conversation this article is having. Not what AIforce is. What it means for the access controls you already have in place.

What Changes When AI Agents Start Accessing Salesforce?

A human user and an AI agent look similar from the outside – both authenticate, both operate under a permission structure, both touch records. The difference is behavior. A person clicks through a handful of records in a session and stops. An agent can query, reason, and act continuously, at a pace no human matches. It never pauses to second-guess whether a request makes sense.

That shift changes the operational context even when the underlying permission model stays identical. Identity still matters – who or what is making the request. Authentication still matters – proving that identity is real. Authorization still decides what that identity can see and do. What’s different is the frequency and autonomy of the requests hitting that same structure.

Take a straightforward example: a service agent handling customer inquiries. A human rep might pull up ten cases in an hour, each one prompting a judgment call about what to check next. An agent handling the same queue might process hundreds of requests in that same hour. Each one executes instantly against whatever access it’s been granted. If that access is broader than it needs to be, the exposure doesn’t wait for a mistake – it’s just running constantly in the background.

How Salesforce AIforce Connects AI With Salesforce Security

AIforce, announced at Dreamforce 2026, is Salesforce’s new interface layer for reaching Salesforce data, workflows, and business logic from other tools – Slack, Claude, or a custom interface. Nobody has to log into Lightning directly. The stated design intent is that every request routes through the permissions and business rules a company already has configured. Salesforce isn’t building a separate access model just for AI-driven requests.

That’s a meaningful distinction. It means AIforce isn’t creating a parallel security system – it’s extending how your existing security model gets exercised. Agentforce agents, similarly, operate through dedicated agent user records that carry their own permission set groups and profiles, created with minimal access by default and expanded deliberately as needed, according to Salesforce’s own documentation on agent access.

Salesforce has also introduced MCP Risk Scores as part of this year’s security updates, scanning connected servers during agent registration for known risk patterns before authorizing a connection, based on Salesforce’s official Dreamforce 2026 announcement coverage. None of this replaces the fundamentals of Salesforce security architecture. It sits on top of whatever foundation your org already has – which means a weak foundation gets extended just as faithfully as a strong one.

Are Your Salesforce Permissions Ready for AI Agents?

This is the question worth actually sitting with before expanding any AI-agent workflow.

Permission Sets & User Access

Every agent operates through a user record, and that record’s permission sets determine its ceiling. Review what’s currently assigned to any agent user in your org, not just what was granted at setup – permissions have a way of accumulating over time as use cases expand.

Object-Level Access

An agent handling support cases probably needs Case and Contact access. It almost certainly doesn’t need visibility into every object in your org just because a shared profile happened to include it. Object-level access should map to the actual job, not inherit broadly from convenience.

Field-Level Security

Object access and field access aren’t the same conversation. An agent might legitimately need to see an Opportunity record without needing every field on it – compensation data, internal margin notes, or anything sensitive that happened to live on the same object.

Record-Level Access

Seeing an object doesn’t mean seeing every record inside it. Sharing rules, role hierarchies, and record ownership all still apply. An agent scoped correctly at the object and field level can still over-reach if record-level sharing is looser than it should be.

Identity & Authentication

Knowing which agent made a request, and confirming that identity is legitimate, matters as much for software as it does for people. This is also where the distinction between an “identified” user and an “authenticated” one gets genuinely important – verifying who someone claims to be doesn’t automatically change what an agent is authorized to access on their behalf, a nuance Salesforce Ben’s breakdown of Agentforce permissions covers in detail.

Agent Actions & Least Privilege

An agent that can only read data is one kind of risk. An agent that can update records, trigger flows, or take action deserves the same scrutiny you’d apply to any powerful piece of automation – arguably more, since it’s reasoning about what to do rather than following a fixed rule.

7 Salesforce Security Checks to Complete Before Enabling AI Agents

1. Review sensitive object access.

Start with the objects that actually matter if they leaked – financials, HR, legal. Go through them one by one and ask a blunt question: does any agent user have access here, and if so, why? If nobody can give a real answer, that’s the access to pull first. 

2. Review field-level security.

 Go beyond the object level. A field holding compensation, health, or contractual detail deserves its own access decision, separate from the object it sits on.

3. Validate record-level sharing.

Object access is one layer. Sharing rules and role hierarchies are the next – and it’s worth actually checking whether they hold up, rather than assuming a profile’s default visibility is fine because nobody’s questioned it. 

4. Audit excessive permissions.

This is where agent users end up just like human ones – someone grants access for a one-off project, the project ends, and nobody circles back to remove it. Go check what each agent is actually using versus what it’s technically allowed to touch. The gap between those two numbers is usually bigger than expected. 

5. Review integrations and connected-app access. 

Agents often work through connected apps and integrations. Each one is its own access point, and each deserves the same scrutiny as a direct user permission.

6. Define exactly what actions an AI agent can perform.

Reading a record and changing one aren’t the same risk category, not even close. Write down, explicitly, which actions each agent is cleared to take — don’t leave it as something everyone just assumes. 

7. Establish monitoring and governance. 

Know how you’ll detect unusual agent behavior after launch – not just at setup. Ongoing monitoring catches drift that a one-time review can’t.

Why Least Privilege Matters More With AI Agents

Least privilege isn’t a new idea – it’s the same principle that’s always applied to any user or integration account. What changes with AI agents is scale. A sales agent might genuinely need opportunity and account data to do its job well. It doesn’t need access to employee compensation records or internal financial fields just because those happen to sit somewhere accessible in the org. The more data and actions an agent can reach, the more precisely that access needs to be defined. Not because the agent is inherently untrustworthy – broad access sitting unused is just exposure with no offsetting benefit.

Salesforce AI Security Isn’t Just a Permissions Problem

Permissions are the most visible piece, but they’re not the whole picture. Data quality matters – an agent reasoning over duplicate or inconsistent records produces confident, wrong answers regardless of how tightly scoped its access is. Identity and authentication need to be genuinely reliable, not just configured once and forgotten. Monitoring and auditability determine whether you’d actually notice unusual agent behavior before it caused a problem. Integration security matters just as much as internal permissions, since agents often reach beyond Salesforce itself. And change management deserves attention too – a permission structure reviewed once at launch drifts the same way any unmanaged part of an org does, quietly, over time.

This is closer to an architecture question than a settings checklist, and treating it as the latter is usually where things start going wrong.

Salesforce AI Security Checklist

 ☐ Permissions reviewed
☐ Sensitive fields identified
☐ Record access validated
☐ Agent actions defined
☐ Least-privilege access applied
☐ Integration access reviewed
☐ Monitoring established
☐ Governance process documented
☐ AI use cases tested
☐ Security reviewed before production

Final Thoughts

The question worth asking isn’t “what can this AI agent do?” It’s “what should this agent be allowed to access and do?” That’s a small shift in framing, but it changes where the conversation starts – from capability first, to authorization first.

Salesforce AI is only as safe as the permission structure it inherits. A well-designed agent built on top of an unreviewed, sprawling access model doesn’t fix that model – it just runs on top of it faster and more consistently than a person would. That’s exactly the kind of gap we look for during a Salesforce security model review. It usually connects to broader questions worth covering in a full Salesforce health check – data quality, org architecture, and whether your Data Cloud foundation can actually support what you’re building on top of it. If you’re comparing which AI tools actually fit your setup, our breakdown of Einstein Copilot versus Agentforce is a useful next read.

If you’re expanding AI-agent workflows and haven’t reviewed the permission structure underneath them, that’s worth doing before production, not after. Book a free 30-minute call with our team and we’ll walk through what your org actually looks like from a security and access standpoint.