Agentforce Auto-Enabled in Winter '27: The Admin Checklist

Starting with Winter '27, Salesforce auto-enables Agentforce for you. For eligible orgs, the platform is enabled by default, and the setting that used to let you turn it off is being removed from Setup. Your org didn't buy anything new, and no agent has started talking to customers. But the gate you used to control has moved, and most admins haven't moved with it. Five controls now do the job the toggle used to do.

What Agentforce Auto-Enablement Changed in Winter '27

According to Salesforce's announcement, as reported by Salesforce Ben:

• Who: Lightning Experience orgs with Foundations on Enterprise, Performance, Unlimited, and Developer Edition, and orgs on Agentforce 1 Edition.
• When: New orgs are enabled at creation. Existing orgs are enabled on a rolling basis starting the first week of September 2026.
• The toggle: The Agentforce setting on the Agentforce Agents page in Setup is being removed later in the Winter '27 cycle.
• Cost: Salesforce says there's no added cost and no billing change from enablement itself.

What Didn't Change

This is where a lot of the panicked commentary goes wrong. Enablement is not deployment.

• No agent is activated. Every agent still has to be built and explicitly activated.
• No consumption starts. Credits are consumed when agents run actions, not when the platform is enabled.
• Permissions still apply. Users without the right permissions can't build or use agents.

So the risk isn't that an AI starts acting on its own overnight. It's that the people who can build agents now face one fewer checkpoint, and in many orgs those people were never deliberately chosen.

Three Different Things Got Turned On

Admins keep conflating three separate changes. They have different scopes, dates, and off-switches:

The first is a platform capability. The second is a user-facing feature with its own opt-out, which we cover in our Agentforce Coworker setup guide. The third is still entirely in your hands. If a stakeholder asks "did Salesforce turn on AI in our org?", the accurate answer is "the platform and possibly Coworker, but no agents."

Check 1: Confirm What's Actually On

You can see the relevant settings as metadata. In our Developer Edition org on API 68.0, retrieving the settings showed:

<!-- AgentPlatform.settings-meta.xml -->
<AgentPlatformSettings>
    <enableAgentPlatform>true</enableAgentPlatform>
</AgentPlatformSettings>

<!-- EinsteinGpt.settings-meta.xml (excerpt) -->
<EinsteinGptSettings>
    <enableEinsteinGptPlatform>true</enableEinsteinGptPlatform>
    <disableAIProvOpenAI>false</disableAIProvOpenAI>
    <disableAIProvAzureOpenAI>false</disableAIProvAzureOpenAI>
    <disableAIProvVertexGemini>false</disableAIProvVertexGemini>
    <disableAIProvAWSBedrock>false</disableAIProvAWSBedrock>
</EinsteinGptSettings>

enableAgentPlatform is the Metadata API field that indicates whether Agentforce is turned on, and it depends on enableEinsteinGptPlatform (Einstein generative AI) being on first. To check your own org, run this from inside a Salesforce DX project:

sf project retrieve start --target-org your-org-alias --api-version 68.0 \
  --metadata "Settings:AgentPlatform" "Settings:EinsteinGpt"

Check 2: Audit the Manage AI Agents Permission

With the platform toggle gone, Manage AI Agents is the permission that decides who can create, configure, and activate agents. Its API name on permission sets is PermissionsEinsteinAgentPlatformBuilder (the label and API name don't match, which is why searching for "AI Agents" in a query won't find it).

This query lists every active user who has it, and through which permission set:

SELECT Assignee.Name, Assignee.Profile.Name, PermissionSet.Label,
       PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsEinsteinAgentPlatformBuilder = true
  AND Assignee.IsActive = true
ORDER BY Assignee.Name

When we ran it in our test org, one of the results was the Platform Integration User, which had Manage AI Agents through a Salesforce-managed permission set. You may well find the same. Integration users with agent-building rights aren't automatically a problem, but you should know they're there.

Related permissions worth reviewing at the same time:

Check 3: Review Agent User Context and Sharing

Agents act through a user context, and that context's permissions decide what an agent can read and change. Before anyone activates an agent:

• Confirm each agent runs under a user with least-privilege access, not a cloned System Administrator.
• Review org-wide defaults on sensitive objects. Agents and Agentforce Coworker both inherit whatever your sharing model allows.
• Look for "permission debt": permission sets granted for a project that ended, or sharing rules for teams that no longer exist.

Check 4: Decide Which Model Providers You Allow

The EinsteinGptSettings metadata in our org included four fields that, by their names, disable individual model providers: disableAIProvOpenAI, disableAIProvAzureOpenAI, disableAIProvVertexGemini, and disableAIProvAWSBedrock. All four were false.

We couldn't find official documentation of exactly what each one does, so don't treat them as a control until Salesforce confirms their behavior for your org. The question they raise is the right one, though: if your legal or security team has approved only certain providers, find out where that decision is enforced. Our comparison of OpenAI, Claude, and Gemini for Salesforce covers the trade-offs.

Check 5: Map Your Prompt-Injection Surface

Agents read records, and some records are written by people outside your company. Web-to-Lead descriptions, Web-to-Case fields, email-to-case bodies, case comments from portal users, and chat transcripts can all contain text an attacker wrote.

Make a short list of externally writable text fields on objects any agent can read. For each one, decide whether agents should see it at all, and if so, whether its content is treated as data rather than instructions. This matters more now that building an agent takes one fewer step.

Your Winter '27 Agentforce Checklist

• Retrieve AgentPlatform and EinsteinGpt settings and record their current values
• Run the Manage AI Agents query and remove access nobody can justify
• Review the three related Agentforce permissions in the table above
• Confirm agent user contexts follow least privilege
• Fix public org-wide defaults on sensitive objects
• Set model-provider switches to match what your security team approved
• List externally writable fields agents can read
• Assign an owner and a monthly budget review for agent consumption

A Two-Week Response Plan

If you're reading this after the auto-enable reached your org, here's a realistic order of operations for a small admin team.

Days 1-2: Get the facts. Retrieve the settings, run the Manage AI Agents query, and check whether Coworker is on. Write down what you found. This becomes your baseline and the first page of your AI governance record.

Days 3-5: Remove what nobody can justify. Take Manage AI Agents away from users who don't build agents. For integration users and Salesforce-managed permission sets, don't just strip permissions; find out what depends on them first, because removing access from a managed integration can break it.

Week 2: Write it down. Agree with your security lead on who may build agents, who approves activation, which model providers are acceptable, and who owns the monthly consumption review. One page is enough. The point is that the next time someone asks to activate an agent, there's a process instead of a debate.

None of this requires buying anything or slowing down a team that's already building responsibly. It replaces the toggle you used to have with decisions you've actually made.

If you're further along and already running pilots, our breakdown of why Agentforce pilots fail covers the governance gaps that tend to show up next.

Frequently Asked Questions

Does Agentforce auto-enablement activate any agents? No. Enablement makes the Agentforce platform available in your org. Agents still have to be built and individually activated before they do anything, and Salesforce says enablement alone adds no cost or consumption.

Which orgs get Agentforce turned on by default? Lightning Experience orgs with Foundations on Enterprise, Performance, Unlimited, and Developer Edition, plus Agentforce 1 Edition orgs. New orgs get it at creation; existing orgs are enabled on a rolling basis from September 2026.

Can I still turn Agentforce off after Winter '27? The Agentforce toggle on the Agentforce Agents Setup page is being removed later in Winter '27. You still control access through the Manage AI Agents permission, per-agent activation, and the Einstein generative AI setting.

Who can build Agentforce agents once it's enabled? Any user with the Manage AI Agents permission, through a profile or permission set. Audit that permission first, including integration users, because it's what turns an enabled platform into agents running in your org.

---

Keep reading:

• Salesforce Winter '27 Release: What Admins Need to Know
• Agentforce Coworker Setup Guide for Admins: Access, Billing, and Opt-Out (2026)
• How to Test and Monitor Agentforce Agents in Production