Salesforce just told the world that a CRM doesn’t need a browser anymore. With Headless 360, announced at TDX 2026, the company is exposing Agentforce, Data 360, and Slack as APIs, CLI commands, and Model Context Protocol (MCP) tools — more than 100 of them at launch. An AI agent can now read a Salesforce org’s data model, trigger a workflow, or ship a fix without a human clicking through a single screen. For engineering teams that build and integrate enterprise software, this isn’t a Salesforce story. It’s a preview of how every large platform is about to expose itself.
What Headless 360 actually ships
Strip away the keynote framing and the release is concrete: VentureBeat’s coverage counts more than 60 new MCP tools and 30-plus preconfigured coding skills, wired directly into Claude Code, Cursor, Codex, and Windsurf. Point one of those tools at a customer’s org and it has live access to real data, workflows, and business logic — the same access a Salesforce admin has, minus the browser.
That matters because it removes the translation layer that used to sit between “what the business needs” and “what the API supports.” A coding agent asked to “deploy a workflow for out-of-policy refund escalations” can execute that instruction against the live org, because it can discover the right operation instead of requiring a developer to already know the endpoint.
Four tools, not thousands
The part worth studying isn’t the tool count — it’s the restraint. According to the Salesforce Developers Blog, the new Headless 360 MCP Server, in beta since mid-July 2026, presents an agent with just four tools: Discover, Describe, Dispatch, and Dispatch Read Only. Discover runs semantic search across roughly 100 skills (with thousands planned). Describe returns the parameters and dependencies for a chosen skill. Dispatch executes it, with access control enforced at that exact point.
This is a deliberate answer to a real problem: an agent context window that has to hold thousands of raw tool definitions gets slower and less reliable at picking the right one. Keeping the agent-facing surface small and stable, while the underlying skill library grows independently, is the pattern most enterprise MCP servers will need to copy as their own tool counts climb past a handful.
The access-control bill nobody skips
Salesforce built its Dispatch layer to run every transaction as the authenticated user, under an mcp_api OAuth scope, enforcing the same CRUD, field-level security, sharing rules, and permission sets that already govern the platform. Admins can require human approval before specific agent actions fire, and every action lands in the audit trail attached to a real user.
That level of enforcement exists because the alternative is already a documented problem. Qualys reported in March 2026 that most organizations have zero visibility into which MCP servers run inside their own environment or what they expose, and that 53% of MCP servers still rely on static, long-lived secrets instead of scoped, rotated credentials. Stacklok’s 2026 guidance is blunt about the fix: OAuth 2.1 with PKCE as the baseline for any remote MCP server, tool-level role-based access control on a deny-by-default model, and each server isolated in its own container so a compromise doesn’t spread.
The scale of adoption makes this urgent rather than theoretical. MCP’s SDKs went from roughly 2 million monthly downloads at launch in late 2024 to about 97 million by March 2026, and the public server ecosystem has passed 9,400 entries, per a July 2026 adoption survey. Stacklok separately found 41% of software organizations already running MCP servers in limited or broad production. Whatever access model a team ships gets tested at that scale almost immediately.
What this changes for nearshore and outsourced engineering teams
For teams that build, integrate, and maintain enterprise software on behalf of clients, Headless 360 is a preview of the skillset that’s about to become table stakes. Fluency in a platform’s UI or REST endpoints stops being enough. The new baseline looks like this:
- Reading a Discover/Describe/Dispatch-style architecture and knowing how to scope a skill request instead of hardcoding an endpoint.
- Setting up OAuth 2.1 with PKCE for any MCP server a project touches, rather than reaching for a static API key because it’s faster to wire up.
- Writing tool-level RBAC policies with a deny-by-default default, then documenting the exceptions instead of leaving access open “for now.”
- Running each MCP server in its own isolated container, so a bug or a bad prompt in one integration can’t reach the rest of the client’s stack.
- Treating agent audit trails as a delivery requirement, not an afterthought — the client’s security team will ask for it.
None of this is exotic. It’s the same discipline outsourced and nearshore teams already apply to production API access and CI/CD pipelines, pointed at a new kind of integration surface. Teams that build this into their delivery process now — rather than after a client asks why an agent had write access to production data — will be the ones enterprises trust with the next wave of agent-operable systems.
The real signal
Salesforce didn’t build Headless 360 because browsers are obsolete. It built it because the largest platforms in enterprise software are competing on how completely they can be operated by an agent, and access control is the feature that decides whether that’s an advantage or a liability. Any team shipping enterprise integrations in 2026 should assume their next client conversation includes a question about MCP — and should already have an answer ready.