Salesforce Moves Enterprise Logic Behind a Governed Capability Plane

On August 25, Salesforce announced a material expansion of Headless 360: an initiative to turn Salesforce applications into reusable capabilities that authorized AI agents can discover and invoke through open standards. The release includes an open-beta Headless 360 MCP Server and Headless Experience Layer, alongside generally available Data 360 MCP Server, Salesforce Multi-framework and a repository of more than 100 agent skills. Availability varies by product and region.

The significant change is architectural. Salesforce is making organization-owned data, workflows and actions available beyond the application interfaces in which they were originally built. An agent, a developer tool or a headless application can use a common capability surface rather than needing to reproduce each business process through a separate integration.

What has not changed is equally important. MCP is not the source of Salesforce authorization or governance. An invocation remains subject to the Salesforce trust and application layers: identity, permissions, access rules, exposed-tool scope, validation rules, triggers, approval chains and platform limits. The agent has not been handed an unrestricted copy of the enterprise application.

The interface is moving; the control point should not

Enterprise systems have often coupled a business capability tightly to a user interface. A human opens a CRM record, follows a prescribed sequence, submits a form, and encounters the relevant checks along the way. APIs loosen that coupling, but they also create a recurring governance problem: every new integration can become another place where teams must reconstruct permissions, validation, audit logic and exception handling.

The Headless 360 direction treats the application differently. The business capability—retrieve approved customer context, update a record, launch a workflow, submit an action for approval—becomes the reusable unit. The controls remain attached to the underlying platform when that unit is invoked.

That distinction matters more than the protocol used to reach the capability. An MCP server may make a tool discoverable to a compatible agent. It does not, by itself, decide whether a particular caller may use that tool, on which records, for what operation, or through which approval path. Those decisions must be made where the business state and organizational rules are authoritative.

“An enterprise agent should consume a governed business capability, not imitate a user interface or receive a raw administrative API.

Salesforce’s developer guidance makes this explicit: the same trust layer applies across API calls, MCP tool invocations and CLI commands. It also distinguishes coding-agent tools from business-agent tools while placing both on the same open capability surface. This is a useful separation. Different callers can have different purposes and operating environments without requiring the organization to create a separate, weaker control model for each one.

Why this matters for autonomous organizations

An autonomous organization cannot safely make every agent a special integration project. If each new model, framework or agent team receives direct APIs, browser automations and bespoke credentials, the organization gradually distributes its business rules into opaque orchestration code. A later policy change then becomes a migration exercise across prompts, tools, connectors and scripts rather than a change at the point of execution.

A governed capability plane offers a more durable boundary. Agents may propose work, select an exposed capability and supply the parameters required to invoke it. The capability layer remains responsible for checking the caller, enforcing the applicable rules, running validations and routing work into an approval chain where one exists. This lets a company extend the number of surfaces that can initiate work without treating every surface as a new system of record for authority.

The operating consequence is practical: autonomous workflows should be designed around explicit business effects, not around screen navigation. “Create a case subject to the applicable entitlement and assignment rules” is a capability. “Click through the support console until a case appears” is an automation workaround. The first preserves the organization’s ability to change its process; the second embeds an accidental version of that process inside an agent.

Reuse is valuable only when the boundary is real

Salesforce says Headless 360 allows agents to reuse existing identity, permissions, metadata, workflows, governance and business logic. That can reduce duplicated integration work, but it should not be read as a guarantee that an agent can operate every function without setup. A capability must still be exposed; a caller must authenticate; permissions and scope still apply; and product availability differs across the announced components.

Nor does this expansion establish end-to-end governance for an autonomous organization. A governed application invocation is necessary, but it does not answer every question before and after the call: who delegated the task, what purpose constrains it, how multiple agents coordinate, how an external action is reconciled, or how a decision is reviewed across systems. A capability plane is an execution boundary, not a complete operating model.

Still, it is the right boundary to strengthen. Organizations should resist architectures in which an agent is trusted because its prompt says it is acting for a business purpose. Trust should be tested at invocation against the current identity, permissions, rules and workflow state. That keeps the business system—not the model’s interpretation of a process—responsible for deciding whether an action can happen.

The implementation test

The useful question for enterprise teams is not simply whether a platform offers MCP. It is whether the capability exposed through MCP, an API or another interface carries the same enforcement path as the native application. If a tool call bypasses validation, skips approvals, uses broader standing credentials or produces weaker observability than a normal business action, it is not a governed capability. It is a shortcut with a modern wrapper.

• Expose business-level actions with clear scopes rather than general-purpose database or administrative access.
• Evaluate identity, permissions, validation and approvals at invocation time for every supported interface.
• Keep tool discovery separate from authorization: a discoverable capability is not necessarily an invocable one.
• Record execution through the same observability and compliance mechanisms used by the underlying enterprise system.
• Treat beta availability as a reason to test boundaries and operational controls, not as proof that an agent architecture is production-ready.

Salesforce’s August expansion does not make enterprise autonomy automatic, and it does not make MCP an operating model. It does make a consequential design choice visible: enterprise applications can become reusable capability providers while retaining the rules that make their actions legitimate. For organizations introducing more agents, that is a better direction than teaching each agent to work around the systems that already govern the business.