Agentforce Enabled by Default: Who Builds in Your Org?

Agentforce enabled by default is now the normal state of a Salesforce org. Salesforce’s Winter ‘27 release went generally available on October 12, and the auto-enablement that has been rolling across existing orgs since early September is now part of the platform you log into every morning. Tech Times spent last week telling IT teams what they “must audit today.”

My position: the switch flipping is not the news. Enabled is not deployed, and nothing acts in your org until somebody builds and activates it. The real question Winter ‘27 hands every admin is not “is Agentforce on?” It’s “who is allowed to build in this org, and how will I know what they built?”

Here’s what actually changed, and what to do about it this week.

What Salesforce actually changed

The facts are narrower than the headlines. Per Salesforce Ben’s reporting, Salesforce is auto-enabling Agentforce for orgs that already have Agentforce access through their licensing or edition. That covers Lightning Experience orgs with Foundations on Enterprise, Performance, Unlimited, and Developer Edition, plus Agentforce 1 Edition. Existing orgs were enabled on a rolling basis starting the first week of September. New orgs are enabled at creation.

Three details matter more than the rest:

• The toggle is going away. The Agentforce switch on the Agentforce Agents page in Setup is being removed later in the Winter ‘27 cycle. Salesforce frames that as one less step to build, test, and deploy agents.
• The off switch moved. To turn the platform off, you turn off the Einstein setting on the Einstein Setup page. Individual agents are still activated or deactivated one at a time in Agentforce Builder.
• No new charge for enablement. Salesforce says there is no additional cost and no billing change attached to the auto-enable itself.

Meanwhile, the official Winter ‘27 announcement puts the weight elsewhere: a shared registry of Agent Skills with more than 100 prebuilt skills, orchestration across third-party agents, and agents for scheduling, marketing goals, and renewals. Default-on is the plumbing. The product push is more agents doing more work.

Enabled is not deployed

This is the distinction most of the alarm skips. An enabled platform with zero active agents does nothing to your data. Agents still have to be built, configured, and activated before they touch a record.

That should lower your blood pressure, but not your attention. Removing the toggle doesn’t make agents appear. It removes a moment where someone had to decide, on purpose, that this org was going to run agents at all. That decision used to be a gate. Now it’s a default, and the gate has moved to permissions.

Which is why the audit you need is not about Agentforce. It’s about who in your org can create things that act.

The permission audit is the real work

If Einstein generative AI is enabled, admins get Agentforce Builder access right away. For non-admins, the Manage AI Agents permission is what lets someone build agents. That permission is the new gate. Find out who holds it, through which permission sets, and why.

Tech Times put the deeper risk well: agents run under a user context and inherit that context’s permissions, so any access that has piled up over the years becomes access an agent can use. They call it “permission debt.” Every org has some. The integration user with admin rights. The profile nobody trimmed after a reorg. The connected app from a pilot two years ago.

A practical checklist for this week:

1. List every holder of Manage AI Agents. If you can’t say why someone has it, remove it.
2. Review the user each agent would run as before you activate anything. Least privilege is not a slogan here; it is the blast radius.
3. Decide where the off switch lives and who is allowed to touch the Einstein setting.
4. Put agent consumption on the monthly spend review. Enablement is free; what an activated agent does is a separate question. We broke down how usage-based AI billing adds up in Salesforce Flex Credits for MCP calls.

None of this is new advice. We made the general case in AI agent access control and in yesterday’s roundup on AI agents in your system of record. Winter ‘27 just put a deadline on it.

Two kinds of AI in your org, and they need different rules

Here’s where I think most commentary goes wrong. It treats “AI in Salesforce” as one thing. It’s two.

Runtime agents are what Agentforce ships: Casey answering service questions, Piper qualifying inbound leads, a marketing agent running a campaign inside guardrails. They act on records, live, all day. The right controls are permissions, activation, and consumption limits.

Build-time AI is the other kind: an AI that writes the flow, the Apex class, the custom object, or the integration that your org runs on. It changes the org itself. The right controls are different: build in a sandbox first, run tests, record every change, and keep a way back if a deploy goes wrong.

Agentforce on by default makes the first kind easier to start. It does nothing for the second. And the second is where most admins actually live: the rollup nobody can build, the routing rule that ignores your territories, the integration Zapier can’t hold together. If you want the full map of the difference, we laid it out in Agentforce vs Copilot vs an AI that builds your CRM and in our Agentforce alternative breakdown.

What I’d do if I owned the org this week

Not panic, and not ignore it. Three moves:

• Treat agent builders like deployers. Anyone who can create something that acts on your data should be held to the same standard as someone who can deploy code. That means named people, a sandbox, and a record.
• Separate building from running. Let a small group build and activate agents. Let everyone else use them. Don’t let “it’s on by default” become “anyone can ship.”
• Get your build path in order before the agents arrive. If you’re about to have more people, and more AI, changing the org, the old click-and-hope deploy path gets expensive. Our comparison of change sets vs the Metadata API is a good place to start, and snapshot before deploy explains why recovery beats approval gates.

This is also where Sentinel fits, without pretending to be something it isn’t. Sentinel doesn’t run your agents and it doesn’t stop your AI from making mistakes. It gives your AI the hands to build in your Salesforce org (sandbox-first, tests required, every change logged, a snapshot before each deploy) so that when something does go sideways, you can see exactly what happened and roll it back. If you’re connecting your own AI over MCP, our guide to Salesforce MCP write access covers how to do that safely.

The takeaway

Winter ‘27 didn’t put AI agents loose in your org. It removed the moment where you had to say yes to them. That puts the weight on two things you control: who can build things that act, and whether you can see and undo what they built.

Do the permission audit now. Then decide how changes to your org get made, by people or by AI, before the default decides for you.

If you’d like to see what logged, recoverable AI development in your own Salesforce org looks like, we’ll walk you through it. Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call