Agentforce is on by default now. Here's the permission audit I'd run this week
Winter '27 turns Agentforce on in eligible orgs and is retiring the Setup off switch. Agents inherit whatever access their user already has, so permission debt is now an AI risk.
Salesforce's Winter '27 release went generally available on 12 October, and most of the coverage is about features. The change I care about most this week is a setting. According to Tech Times, Agentforce is now on by default in eligible Lightning Enterprise, Performance, Unlimited and Developer Edition orgs, at no extra cost, and the Setup toggle that let admins switch it off is being removed. The rollout to existing production orgs started in the first week of September. Winter '27 finishes it.
I've spent more than eleven years inside Salesforce orgs, and I can tell you what most of them look like under the hood. They aren't clean. So I want to skip the feature tour and talk about what this default means for the people who own those orgs.
Agents inherit your permission debt
An agent runs under a user context and gets that user's full permission profile. That includes object access, field-level security, sharing rules, org-wide defaults and connected app OAuth scopes. Tech Times calls the gap between what a user has and what they need "permission debt", and I think that's the right name for it.
I've seen how it builds up. A rep joins and gets Opportunity, Account, Contact and Lead. Her team is reorganised and she lands on a broader profile. A project ends and nobody removes the permission set that gave her View All on some object. Three years later the account carries access for a dozen jobs she no longer does. That has always been a problem. The difference now is speed. A person might touch that object twice a quarter. An agent running a renewal workflow can query it thousands of times a week.
The Manage AI Agents permission controls who can configure and activate agents. It doesn't shrink what an agent can reach once it's running. Auto-enablement doesn't audit your access model. It switches it on.
This has already gone wrong once
The Tech Times piece recalls ForcedLeak, a CVSS 9.4 vulnerability that Noma Labs disclosed in July 2025. An attacker could hide instructions in the Description field of a Web-to-Lead form. When a rep later asked Agentforce about that lead, the agent could follow those instructions and send email addresses from reachable records to an outside server. Salesforce closed that path on 8 September 2025 with Trusted URLs Enforcement.
The patch fixed one route out. It didn't change the fact that public forms write text into your org, and agents read that text. Any field a prospect or customer can fill in is a place someone could try to talk to your agent.
What Winter '27 actually lets agents do
This matters more because the agents are doing more. The David & Goliath briefing describes Winter '27 as the point where agents move from single-task helpers to running whole processes: qualifying pipeline, resolving service cases, booking appointments and handling commerce search. Autonomous Scheduling with Voice books appointments without a human dispatcher, and Salesforce says it cuts a 15-minute call to seconds. Tech Times also lists renewal assembly, self-service quoting and third-party agent orchestration over the A2A protocol, where Agentforce can direct agents on AWS, Azure and Google Cloud, or act as a subagent for someone else's orchestrator.
Every one of those steps writes to live records. Better agents make it more important to get permissions right, not less.
The audit I'd run this week
This is the order I'd work in if I were walking into a client's org on Monday. Most of it follows the checklist Tech Times laid out, with my own notes added.
- Find the off switch while it still exists. Tech Times says the Einstein Setup page still has a toggle in eligible orgs until removal is complete. If you're not ready, pause there and audit first. Don't wait for the toggle to vanish before you decide.
- Check who holds Manage AI Agents. In orgs where admins carry broad permission sets, this has probably spread further than you intended. Take it away from anyone who doesn't need to build or activate agents.
- Give every agent its own narrow user. Don't run an agent as a real person or as a shared integration user that has collected access for years. Build a dedicated user with only the objects and fields that one workflow needs. If a second workflow needs more, give it a second user.
- Revisit org-wide defaults and old sharing rules. Public Read/Write on sensitive objects was a common early setting. Sharing rules written for teams that no longer exist are still active. An agent will use all of it.
- List every field the outside world can write to. Web-to-Lead, Web-to-Case, case comments, portal notes. Then ask which of them an agent reads during normal work. Those are your prompt injection surfaces.
- Clean up connected apps. OAuth scopes granted to integrations you shut down years ago are still reachable. I find these on almost every org health check I do.
None of this is new advice. It's the hygiene we've always said we'd get to. The default just took away the option to keep putting it off.
The takeaway for CRM and RevOps teams
I'm not against Agentforce being on. Scheduling, case resolution and renewal assembly are exactly the slow, repetitive work agents should take off people's plates. But "on by default" moves the decision from "should we adopt agents?" to "is our access model good enough for software that never gets tired?" For most orgs, honestly, it isn't yet.
If you own RevOps or the CRM, treat this week's work as a permissions project, not an AI project. Put a short audit on the calendar, give agents their own least-privilege users, and write down which fields the public can write to. Do that before the first agent touches a renewal, and you get the speed without the risk.