Agentforce is on by default now: the Winter '27 lockdown checklist

For most of Agentforce’s life the platform sat behind a switch that was off until an admin turned it on. That switch is going away. During the Winter ‘27 rollout Salesforce is enabling Agentforce by default across eligible orgs, and later removing the Setup toggle that kept it off. The feature you were evaluating is now a feature you own.

Do one thing before your org’s upgrade weekend. Decide who is allowed to build an agent, and confirm what a running agent can see, before the platform sets the defaults for you. Everything below is that decision, broken into an afternoon of Setup work.

I’m not writing this to talk you out of Agentforce. The auto-enable is mostly good news, it drops the setup friction that stalled a lot of pilots. But “enabled” is not “governed,” and an org that gets the platform switched on without a permission review is an org where the wrong people can build agents against data those agents shouldn’t touch. That gap is the whole post.

What gets switched on

Auto-enable is two separate rollouts that people keep merging into one.

The first is Agentforce Coworker, the conversational layer that answers from your data and hands the next step to an agent. Salesforce began auto-enabling Coworker from August 10, 2026 for customers with the qualifying user-based AI seats. By default it searches Salesforce CRM only, with Slack as an opt-in source. We covered its switch-itself-on behavior and the permission-set trap in Agentforce Coworker.

The second is the Agentforce platform itself. It’s enabled for existing orgs on a rolling basis from the first week of September 2026, and the setting is slated to disappear from Setup later in Winter ‘27. Eligibility tracks your edition: Enterprise, Performance, Unlimited and Developer editions on Foundations, plus Agentforce 1 licenses. Confirm your instance’s date on Salesforce Trust, and read the Winter ‘27 changes for builders.

Enabled means the machinery is on. Your users can reach Agent Builder, the default agents Salesforce ships can be activated, and the running-user model that governs what an agent can do is live whether or not you’ve reviewed it. None of that is dangerous by itself. It’s dangerous unreviewed.

Lever one: decide who can build an agent

The permission that matters most on day one is Manage AI Agents. It’s what lets a non-admin user open Agent Builder and create or edit an agent. In a lot of orgs that permission is about to be sitting somewhere broad, on a profile, or on a permission set half the company already has, because nobody scoped it back when Agentforce was an experiment.

Find it before someone finds it for you:

Setup → Permission Sets → (each set) → System Permissions → filter "Manage AI Agents"
Setup → Profiles → (each profile) → System Permissions → "Manage AI Agents"

The target state is a single named permission set, say Agentforce_Builders, with an owner and a short assignment list you can defend in an audit. Everyone who can build an agent can wire that agent to Apex, to a Flow, to a prompt template, and to whatever those can reach. Treat the permission the way you’d treat “Author Apex,” because functionally it’s close.

This is the same discipline that keeps an agent fleet from turning into shadow IT: a small, owned build permission is the difference between ten governed agents and forty nobody remembers creating.

Lever two: confirm what a running agent can see

One fact turns a permission review into a security review. An Agentforce agent has no opinions of its own about data access. It runs as a user, and inherits that user’s object permissions, field-level security, record access and role hierarchy. We walked through the whole model in the Agentforce agent user. The rule before launch is short: the agent sees exactly what its running user sees.

The auto-enable makes that urgent. The platform is now live against your current field-level security, in whatever state it’s in. So the second lever is a targeted FLS pass on the fields you’d hate to see in a generated answer:

Compensation, bank and tax fields on employee or contact records.
Anything holding government identifiers, health data, or notes a support rep typed that were never meant to leave the case.
Custom fields storing risk scores, internal flags, or free-text that quotes a customer.

For each, check the field-level security on the profiles and permission sets your agent users run under. An agent grounded on a record will happily surface a field the running user can technically read, in a sentence, to whoever is chatting with it. FLS is your control surface, and it’s the same one your reports and API integrations already depend on. Get it right once and every channel benefits.

Then check the running user’s sharing. An agent running as a high-privilege service user, or as a manager high in the role hierarchy, sees far more than a front-line rep. Scope agent users to least privilege on purpose. Don’t inherit an admin’s reach by accident.

Lever three: find what’s already billing

The credit story around auto-enable is confusing, and the confusion costs money. Coworker’s CRM and Slack search is unmetered for users on Agentforce 1, on Agentforce for Sales, Service or Industries seats, or on unmetered user-based AI entitlements. Their usage shows as 0% in Digital Wallet. The trap is the qualifier: without the AI permissions set correctly, a user can burn metered credits while holding a license that should have been free.

So the third lever is a wallet pass, not a one-time glance:

Open Digital Wallet and read the 7- and 30-day consumption cards. A platform that just switched on should not be generating a consumption line you can’t name.
Confirm the users you expect to be unmetered are showing 0%. If a licensed user is consuming, the permission assignment is wrong, fix the assignment, don’t absorb the bill.
Treat any autonomous, customer-facing surface as a spend risk until proven otherwise. Guest, unauthenticated and portal users are billed on usage-based pricing, so an agent exposed to an anonymous web audience meters differently from an internal one. If you don’t intend to run an agent for guests, confirm none is reachable.

If the invoice is the thing keeping you up, the deeper version of this pass is the Flex Credit optimization playbook, which reads the same wallet with a design eye.

Lever four: govern it, restrict it, or turn it off

You have three honest postures, and picking one deliberately is the point of the afternoon.

Govern it. Leave the platform on, scope the build permission, run the FLS pass, and put Digital Wallet on a weekly calendar. This is the right answer for most orgs, and it’s where the Agentforce setup checklist and the Trust Layer guardrails do their work: toxicity and data-masking policies, topic scoping, and the testing gates that decide whether an agent is fit to meet a customer.

Restrict it. Leave the platform enabled so you keep evaluating, but hold Manage AI Agents to a tiny group and deactivate the default agents you’re not using. Individual agents can be activated or deactivated in Agent Builder at any time, so “on but idle” is a legitimate, cheap holding pattern.

Turn it off. If you aren’t ready, the master control is the Einstein setting on the Einstein Setup page, which turns the Agentforce platform off. Coworker has its own opt-out: the link in your enablement email, or Setup → Agentforce Coworker → Opt Out of Auto Activation. If a hard-off is what compliance requires, do it before the toggle is removed, and document why.

There’s no wrong posture here except the unchosen one. An org that drifts into “on and unmonitored” has made the riskiest choice available without ever deciding to.

The afternoon, in order

If you read nothing else, run these five in this sequence in a sandbox or a quiet production window:

Audit Manage AI Agents across profiles and permission sets; consolidate to one owned set.
Run an FLS pass on sensitive fields for every profile an agent user runs under.
Scope agent users and their sharing to least privilege.
Read Digital Wallet; confirm unmetered users show 0% and no anonymous surface is live by accident.
Choose your posture, govern, restrict, or off, and write it down.

The auto-enable didn’t create any of these risks. Over-broad permissions, loose FLS and unwatched consumption were already latent in the org. What the rollout did was remove the switch that was hiding them, and hand you a live platform that acts on whatever posture it finds. Spend the afternoon giving it a posture you chose.

Understanding the basics

Is Agentforce enabled automatically in Winter ‘27?

Yes. Salesforce is enabling the Agentforce platform by default across eligible orgs during the Winter ‘27 rollout, beginning for existing orgs on a rolling basis in early September 2026, and it plans to remove the Agentforce toggle from Setup later in the release. Agentforce Coworker began auto-enabling separately from August 10, 2026 for qualifying user-based AI seats. Eligibility covers Enterprise, Performance, Unlimited and Developer editions on Foundations, plus Agentforce 1 licenses. Confirm your instance’s exact upgrade date on Salesforce Trust.

How do I turn Agentforce off after it’s auto-enabled?

The platform master control is the Einstein setting on the Einstein Setup page, which turns Agentforce off. Individual agents can be deactivated in Agent Builder at any time. Coworker has its own opt-out through the link in your enablement email, or under Setup, Agentforce Coworker, Opt Out of Auto Activation. If a hard-off is required for compliance, do it before the Setup toggle is removed later in Winter ‘27.

What is the Manage AI Agents permission?

Manage AI Agents is the permission that lets a non-admin user open Agent Builder and create or edit agents. Because an agent can be wired to Apex, Flows and prompt templates, this permission is closer to a development capability than a convenience. It should live on a single named permission set with an owner, not on a broad profile. Auditing who holds it is the first move after auto-enable.

Can an auto-enabled agent see data it shouldn’t?

An agent inherits the object permissions, field-level security, record sharing and role hierarchy of the user it runs as, so it can surface any field that user can read. Auto-enable makes the platform live against your current field-level security in whatever state it’s in, which is why a targeted FLS pass on sensitive fields, and scoping agent users to least privilege, are the core of the lockdown. The agent adds no access of its own, but it removes the friction that used to keep loosely-secured fields out of sight.

If your org’s Agentforce switch flipped on before you had a governance plan, that’s a normal week for us. Talk to us about a lockdown pass, scoping the build permission, tightening field-level security, and putting the wallet on a calendar, so an enabled platform is also a governed one. Our Agentforce practice does exactly this against real orgs.