Agents Don't Use UI Anymore: What does Salesforce Headless 360 Mean?
Updated on:
May 13, 2026
.png)
For more than 20 years, "using Salesforce" meant logging into a browser.
You opened Lightning (or before that, the classic UI), navigated to an account, ran a report, updated a stage, and sent an email. Every workflow assumed a human, a screen, and a click.
A few months ago, Salesforce co-founder Parker Harris asked, "Why should you ever log into Salesforce again?" It read like a provocation at the time.
At TrailblazerDX 2026, Salesforce shipped the answer by launching Salesforce headless 360, which means:

- Every Salesforce capability is now an API: CRM, Data Cloud, Flow, and platform operations all expose programmable endpoints
- 60+ native MCP tools: Salesforce ships first-class MCP tools across the platform, callable by any MCP-aware agent without custom integration work.
- 30+ preconfigured coding skills: Reusable building blocks that agents compose into multi-step workflows
- Full CLI coverage: Every platform operation is scriptable, which means CI/CD pipelines and automation can drive Salesforce end-to-end
- Native Claude Code and Cursor integration: Developers operate Salesforce directly from Anthropic's Claude Code and Anysphere's Cursor, the two IDEs most agent-building teams already live in.
- Agentforce Vibes 2.0.: A companion release that extends Salesforce's agent runtime and developer experience, so agent behavior is portable and inspectable.

Now that agents are the primary callers of Salesforce, how do you govern them?
That gap is what we are closing with our MCP Gateway.

What is an Enterprise MCP Gateway?
The Enterprise MCP Gateway is a governed runtime and control layer that sits between MCP clients (hosted agents, IDE agents, SDK agents, internal apps, human MCP clients) and enterprise tools (Salesforce's MCP endpoints, your private MCP servers, and your approved internal REST/OpenAPI sources).
It does five things:
- Registers approved MCP servers and OpenAPI sources, with owner team, environment, risk tier, credential mode, and approval state.
- Exposes them through MCP-compatible endpoints that all approved client surfaces call into.
- Enforces user, agent, and tool policy on every call, using deterministic Cedar policy that distinguishes humans, service identities, agents, and agent instances.
- Brokers credentials from your existing secret manager, so MCP server owners and platform teams never write auth code or hold long-lived secrets.
- Audits every call, every policy decision, every session lifecycle event, and every admin change, exported to your existing SIEM.

Two architectural choices matter most. The gateway runs in hybrid mode (managed control plane with a customer-side data plane) or fully self-hosted (the entire product inside your infrastructure, no required outbound vendor dependency at runtime).
And it converts approved OpenAPI 3.x operations into governed MCP tools without each team writing an MCP server, so your existing internal API estate becomes agent-ready in a workflow instead of a project.
Why do Salesforce customers need this now?
Three forces converged the moment Headless 360 shipped. Together, they have turned "we will figure out MCP governance later" into a procurement blocker.
- Salesforce is now an MCP surface. 60+ MCP tools across CRM, Data Cloud, Flow, and platform operations. 30+ coding skills. Native Claude Code and Cursor integration. Your approved Salesforce instance just inherited an entire new agent-traffic surface, with no extra opt-in required. Every agent calling those tools is a new identity, credential, and policy boundary.
- Agents are not service accounts. The default playbook of "issue an API key, log it in a spreadsheet, hope for the best" was already fragile for service-to-service traffic. It is structurally broken for agents, which can act with delegated user authority, switch contexts inside a session, and chain tool calls in ways that are hard to attribute. Audit on agent traffic without per-agent identity is theatre.
- The IDE is the new distribution channel. Salesforce shipped Claude Code and Cursor integrations on day one. Your developers are connecting their IDEs to Salesforce (and to your internal tools) whether or not you have approved it. The choice is not "block this" or "let it happen." It is "give them an approved governed path, or watch shadow MCP show up in your next pen test."
The teams that are ahead on this are not the ones with the most ML talent. They are the ones who have a single governed path for MCP traffic before agent volume scales. That is what the gateway is.
The common pitfalls when teams try to build this in-house
Most enterprises start by treating MCP as "just another API." Within a quarter they run into the same set of problems.
- Hand-rolling the MCP gateway. Auth, rate limits, tracing, cost controls, agent identity, session routing, and credential injection are each their own subsystem. Building all of them well in-house is six to nine months for a senior platform team. Most teams ship a thin version, then spend the next year hardening it under load.
- Treating agents as service accounts. A shared bearer token across every agent makes per-agent attribution impossible. Security blocks production rollout. The platform team rebuilds the identity model six months in, this time with agents as first-class subjects.
- Exposing entire APIs as MCP tools. Importing an OpenAPI spec and publishing every operation is fast, demo-friendly, and exactly how data exfiltration happens. Tool exposure should be selective, schema-validated, and approval-gated, not bulk conversion.
- Stateless thinking on stateful traffic. MCP sessions are long-lived. Treating them like REST calls breaks reconnects, drain on deploy, and revocation. You need a session router with affinity and externalized session metadata, not a stateless load balancer.
- Audit as an afterthought. Without per-call audit that captures actor chain, policy decision, credential mode, session ID, and connector path, you cannot answer the questions security will ask after an incident. Adding audit late means rewriting the gateway.
- Forgetting private connectivity. Many enterprise MCP servers and internal APIs are private and stay private. The gateway has to support outbound-only connector mode and mTLS-style connector authentication, so backends never need to be exposed publicly.
Each of these is a six-month detour. Together they are why most enterprise MCP rollouts that started in 2025 are still in pilot in 2026.
What's inside DigitalAPI's Enterprise MCP Gateway?
The product is structured as a control plane plus a gateway data plane, with deliberately practical V1 dependencies: PostgreSQL, Valkey, OpenTelemetry, Helm. No required ClickHouse, no required Kafka, no required Kubernetes operator. It runs on what your platform team already operates.
1. Registry and catalog-lite
Approved MCP servers (including Salesforce's) and approved OpenAPI sources are registered with owner team, environment, risk tier, credential mode, endpoint metadata, and approval state (draft, pending, approved, disabled, deprecated). Catalog-lite gives authorized developers a searchable view with configuration snippets and access instructions. Unauthorized capabilities are filtered out at discovery, not just denied at execution.
2. Agent identity and policy
Every non-human agent is registered with owner, purpose, allowed surfaces (hosted agents, IDE agents, SDKs, internal apps), allowed environments, optional human delegator, optional instance ID, and revocation status. Cedar policy evaluates every call against user, agent, surface, environment, server, tool, risk tier, credential mode, and session state. Discovery is policy-filtered, so agents only see the tools they are allowed to call. Policy simulation lets admins preview "can this agent call this Salesforce tool in production?" before any change ships.
3. Credential broker
Credentials are resolved from your existing secret manager (Vault-first, with adapters for cloud and customer secret stores). V1 supports service-account credentials, user-delegated OAuth, agent-scoped credentials, and workload-identity-mapped credentials. Secrets are never written to logs, traces, metrics, or audit events. Rotation does not require touching MCP server code, just the central credential binding.
4. OpenAPI-to-MCP conversion
Import an OpenAPI 3.x spec, select specific operations to expose, map parameters and auth, attach risk and policy, approve, publish. The gateway validates schemas at runtime, enforces upstream host allowlists, and applies per-operation timeouts, size limits, and retry policy. Selected internal REST operations become governed MCP tools without each team writing an MCP server. Spec drift is detected before generated tools update.
5. Private connectivity
Outbound-only connector mode lets private MCP servers and internal APIs stay private. The gateway and connectors authenticate with mTLS. Per-backend allowlists ensure a connector can only reach the backends it is configured for. Disabling a connector immediately blocks new calls and terminates affected sessions.
6. Stateful sessions
MCP sessions are first-class. The gateway issues client session IDs, tracks backend session IDs where needed, supports session affinity, externalizes session metadata, supports graceful drain, basic reconnect, termination, and revocation. Revoking an agent, a credential, or a policy terminates affected sessions, not just blocks new ones. Per-session duration and idle limits prevent stuck sessions from holding resources indefinitely.
7. Audit and observability
Every tool call, policy decision, credential mode, session lifecycle event, and admin change is auditable. Audit exports to your SIEM (Splunk, Elastic, whatever you use). Metrics and traces export through OpenTelemetry. The admin console supports audit search by actor, server, tool, session, and request ID, plus emergency disable for any server, tool, agent, credential, connector, or client surface.
8. Hybrid or fully self-hosted
Hybrid mode keeps the admin console, registry metadata, and policy management on the managed control plane, while runtime traffic stays inside your environment. Fully self-hosted runs the entire product, control plane and data plane, inside your infrastructure with no required outbound runtime dependency for normal operation. Both modes ship with signed container images, SBOMs, and Helm charts. Hybrid additionally enforces cached policy for a bounded period during control-plane outage.
How does this map onto your existing stack?
The gateway is opinionated about what it owns and what it does not.
It owns: the MCP request path, agent identity, the policy decision point, the credential broker call-out, session routing, OpenAPI-to-MCP adaptation, and the audit emission.
It does not own: your identity provider, your secret manager, your SIEM, your observability platform, your data warehouse, your existing API gateways, or your MCP servers themselves (including Salesforce's). Those keep doing what they do. The gateway integrates with them through OIDC, SAML, Vault-compatible secret stores, OpenTelemetry, and webhook/SIEM export.
That separation matters. You are not replacing your stack. You are adding the one missing layer that turns your stack (Salesforce included) into a governed surface for agents.
The bottom line
Salesforce going headless was the visible part of the shift. The Lightning UI did not stop existing, but it stopped being the primary way Salesforce gets used. Agents are. The click is becoming a legacy interaction model for the largest CRM on the planet.
The invisible part, the part that decides which enterprises actually capture the productivity gains, is whether your security and platform teams have a governed path for agent traffic before that traffic hits production.
The Enterprise MCP Gateway is that path. One registry, one policy engine, one credential broker, one audit log, one revocation surface, for Salesforce and for everything else you connect alongside it. Everything else you have today keeps working.
See how DigitalAPI's Enterprise MCP Gateway gives you one governed path for all approved MCP traffic, including Salesforce, in weeks. Request a demo.




.avif)
