Table of contents
Last week at TDX, Salesforce announced Headless 360 — the biggest strategic shift the company has made in a decade. Parker Harris framed it in one sentence: “Why should you ever log into Salesforce again?”
The answer Salesforce gave is that you shouldn’t. Every capability in the platform — Customer 360, Data 360, Agentforce, Slack — is now exposed through three programmable surfaces: a REST API, an MCP tool, and a CLI command. Sixty-plus new MCP tools shipped with the announcement. Coding agents like Claude Code, Cursor, Codex, and Windsurf can reach into a Salesforce org directly. So can agentic workspace products like Claude Cowork and Microsoft Copilot Cowork — used by sales reps, customer success managers, finance analysts, and marketers across every function. So can CI/CD pipelines through the new DevOps Center MCP. So can any autonomous agent that can make an HTTP call.
This is a big deal. It’s also, from a security posture perspective, a big problem arriving at enterprise scale faster than most teams are ready for. And it’s bigger than credential theft, which is where most of the current agent security conversation is stuck. Headless 360 creates a full set of governance problems that every Salesforce-connected AI agent now raises — and they don’t go away by rotating keys or enabling IP restrictions.
What Headless 360 actually changed for Salesforce agent security
Each surface looks different on the user’s side, which is exactly why Salesforce shipped all three — different agents consume access differently, and different user populations reach each surface.
API. Service-to-service traffic. OAuth flows using client credentials, JWT bearer tokens, or refresh tokens, usually stored as environment variables in an autonomous agent’s runtime or mounted as Kubernetes secrets. Small population, high privilege.
MCP tools. 60+ of them, called from developer laptops running Claude Code, Cursor, Codex, and Windsurf — and increasingly from agentic workspace products like Claude Cowork and Microsoft Copilot Cowork used by business users across every function. A sales rep using Claude Cowork to draft a follow-up email can now pull directly from Salesforce. A customer success manager using Copilot Cowork to prep for a renewal call can too. The MCP surface is not just a developer surface; it’s an everyone surface.
CLI commands. The Salesforce CLI, Agentforce Vibes, and the new DevOps Center MCP embed into developer terminal workflows, coding agent sessions, and CI/CD pipelines. Every developer who connects their Salesforce org to Claude Code, Cursor, or Agentforce Vibes has a credential cached locally. Every autonomous agent running against Salesforce in production has Connected App credentials — a client secret, a JWT signing key, or a refresh token — stored in its runtime.
Three surfaces, all connecting AI agents directly to production Salesforce data. The population connecting through them spans from a handful of backend services to potentially every knowledge worker in your organization. That’s the setup. The problem is what comes next.
It’s not a developer-tooling problem anymore
It’s tempting to think of AI agents accessing Salesforce as a developer-tooling question. It isn’t, not anymore. Headless 360 shipped alongside a generation of agentic workspace products — Claude Cowork, Microsoft Copilot Cowork, Google’s emerging workspace agents — that connect business users directly to Salesforce through MCP. A sales rep, a CSM, a finance analyst, a marketer: any of them can now have a personal AI assistant that reads and writes Salesforce records on their behalf.
Governance questions don’t scale linearly with this audience. They compound. Two hundred developers with coding agents is a governance problem. Two thousand knowledge workers with agentic assistants is a different category of problem — one that touches every employee identity, every sharing rule, every Connected App, and every audit log. The six dimensions we’re about to walk through all intensify when the agent population shifts from “developers” to “everyone.”
Six governance problems Headless 360 hands every security team
Most of the industry is still talking about agent security as a credential problem. It isn’t. It’s six problems, and credentials is only one of them. Every Salesforce-connected agent your organization deploys raises each of these questions. Your security posture is the sum of how well you answer them.
1. Identity. Which agent is this, and which human is behind it? An agent called “Sales Agent” can be a legitimate deployment by your revenue operations team or a Claude Cowork instance on a sales rep’s laptop. Salesforce sees the OAuth credential and the Connected App, but has no inherent concept of which agent instance, acting for which user, made the request. Multiple employees using the same workspace agent against the same Salesforce org are indistinguishable to Salesforce.
2. Credentials. What backend token does the request carry, and can it be extracted? Every credential sitting in an agent runtime — a refresh token cached locally by a Cowork-style agent, a Connected App client secret in a container, a JWT signing key in a CI/CD pipeline — is reachable by the agent process. And anything the agent can read, prompt injection can exfiltrate. With two thousand employees each running an agentic assistant, that’s two thousand credential surfaces, not one.
3. Tool and action authorization. What is this agent allowed to do in Salesforce? A sales rep’s Cowork agent should probably be able to read Opportunities and write Activity records, but not delete Accounts. A marketer’s agent has no business writing to Contact records. A code review agent has no business reading Contact PII at all. Today, if an agent has valid OAuth credentials and the user those credentials belong to has broad access, the agent inherits that breadth. Salesforce’s native permission model can create scoped integration users, but doing this per agent per scope combination doesn’t scale past a handful of agents — let alone across an entire workforce.
4. Data scope. Which records can this agent see? Salesforce is the hardest SaaS in the world to reason about at this layer — sharing rules, record types, field-level security, object-level permissions, and a sprawl of standard and custom objects. A sales director’s Cowork agent inherits that director’s full pipeline visibility. Whether the agent should be able to answer “summarize every Opportunity across every region” just because the underlying user technically has that access is a separate decision, and not one Salesforce’s native access model is positioned to make per-agent.
5. Rate and anomaly control. Is this agent behaving normally? A user’s Cowork agent that historically pulls 50 Contact records per day and suddenly queries 50,000 is doing something that deserves to be interrupted before the request completes. Salesforce has org-wide API limits, but those are org-wide, not per-agent, and they fire at quota exhaustion — not at anomalous-behavior thresholds that would catch an attack in progress. With a workforce-scale agent population, detecting the anomalous few among the normal many becomes essential.
6. Audit and attribution. Who did what, and can you prove it? Salesforce’s Event Monitoring logs API calls, and it’s good — but it attributes calls to the OAuth user and the Connected App, not to the specific agent instance or the specific interaction that triggered the underlying action. “User Jane, through her Cowork agent, queried 47 Contact records in response to a ‘help me prep for the quarterly review’ prompt at 14:32” is not a log line any native Salesforce feature produces today. When a business-user agent does something wrong — and at workforce scale, some will — you need to be able to answer what happened, on whose behalf, and in response to what.
These six are the full agent governance surface for Salesforce. Addressing one and ignoring the others is not a security posture — it’s a checkbox.
Three surfaces, one enforcement point
Headless 360’s three surfaces produce two kinds of traffic a gateway needs to understand: direct HTTPS to Salesforce’s REST API, and MCP protocol calls (which also travel over HTTPS but require protocol-aware handling). A CLI is a local binary that wraps HTTP calls to an API — when a developer runs sf data query , the CLI reads a stored credential, constructs an HTTPS request to your Salesforce org, and parses the JSON response. The wire traffic is indistinguishable from a Python script or an SDK making the same call. The CLI is not a separate integration; it’s the API wearing a different shell.
That means one enforcement point in the network path can see everything agents do against Salesforce, regardless of which surface initiated it — and regardless of whether the user behind the agent is a developer, a sales rep, or a backend service.
Datawiza Agent Gateway sits in that path. The gateway intercepts outbound traffic at the DNS layer — your enterprise DNS resolves your Salesforce org’s endpoints (and the MCP server endpoints) to the gateway instead of directly to Salesforce. Any agent, any client, any CLI that tries to reach Salesforce hits the gateway first. For agents running on employee laptops, this requires routing through the gateway via VPN, split DNS, or a local configuration — the same pattern enterprises already use for other internal services.
Because the gateway sits in the traffic path between every agent and Salesforce, it’s the only place in the stack where all six governance problems can be addressed coherently.
How a gateway addresses the six governance problems
Identity. Every request reaching the gateway carries a gateway-issued key tied to a specific agent identity, which is itself tied to a user identity in your enterprise IdP — whether that’s Microsoft Entra Agent ID, Okta, or any OIDC-compliant provider. Salesforce sees a properly authenticated OAuth request; the gateway sees “Cowork agent, acting for Jane in the Western Sales team, calling this endpoint at this time.” Identity at the gateway layer is richer than what Salesforce can know on its own, because it captures the agent-plus-user relationship that Salesforce doesn’t natively model.
Credentials. The agent doesn’t hold a Salesforce OAuth token, a client secret, or a JWT signing key. It holds a gateway-issued key — a drop-in replacement the agent uses the same way it would any backend credential. The real Salesforce credentials live in the gateway’s encrypted store inside your network. When the gateway forwards the request, it strips the agent’s key and injects the real Salesforce credential on the outbound side. Prompt injection of the agent reveals only the gateway key, which is useless outside your network.
Tool and action authorization. Because every request passes through the gateway, the gateway can enforce policy on what the agent is allowed to do — not just whether it can authenticate. Architecturally, this supports rules like “Sales team Cowork agents can call Opportunity read and Activity write, nothing else.” The gateway performs this enforcement itself; Salesforce still sees the OAuth user’s native permissions. The granularity scales from coarse tool allowlists to specific API verb allowlists based on how the customer configures it.
Data scope. Salesforce’s native access model is the baseline — sharing rules, FLS, and record-level security still apply to the underlying OAuth user. What the gateway adds is an agent-specific layer on top: the agent acting on behalf of a user can be constrained tighter than the user themselves, enforced at the gateway rather than by reshaping the user’s Salesforce profile. If Jane has access to every Opportunity in North America but her Cowork agent should only ever need Opportunities she directly owns, the gateway can filter or reject requests that exceed that narrower scope before they reach Salesforce.
Rate and anomaly control. The gateway sees every request before it reaches Salesforce, which makes it the natural place to enforce per-agent rate limits and to detect patterns that deviate from an agent’s normal behavior. An agent pulling 1,000x its historical query volume is a signal that something is wrong — prompt injection, misconfigured code, or a compromised credential — and the gateway is in position to rate-limit, alert, or block before the damage lands. How aggressive this enforcement should be is a policy decision per agent per customer, not a universal default.
Audit and attribution. Every request through the gateway is logged with full attribution: which agent, which user, which tool or API endpoint, which records were touched, at what time. This runs independent of Salesforce’s own Event Monitoring, and it captures the part Salesforce can’t see — the agent-and-user relationship upstream of the OAuth credential. When a security incident requires answering “what did Jane’s Cowork agent do on Tuesday and in response to what,” the answer is in one log, not reconstructed across three.
No native Salesforce feature addresses all six. Salesforce IP restrictions address parts of the credentials problem. Permission sets and sharing rules address parts of the data scope problem. Event Monitoring addresses parts of the audit problem. Each is a good control. None of them were designed to reason about agents as distinct actors or about agent-plus-user identity as the unit of governance, and none were designed for a workforce-scale agent population. A gateway in the traffic path is the layer where those concerns get a coherent home.
What architects should do this week
Headless 360 is already happening inside your organization, whether you’ve approved it or not — and it’s happening at both ends of the employee spectrum. A concrete checklist for the next seven days:
- Inventory which teams have requested or enabled Headless 360 access. Salesforce admins see the requests first. Talk to them this week, not next quarter.
- Identify which agents are already connecting to Salesforce through MCP. Coding agents (Claude Code, Cursor, Codex, Windsurf) and workspace agents (Claude Cowork, Microsoft Copilot Cowork). Ask your engineering leads and your Salesforce admins — the Cowork-style products may already be connected through end-user workflows that never touched IT.
- Block ad-hoc Connected App creation until the access pattern is defined. Client secrets, JWT signing keys, and service user credentials should require a ticket, not a click.
- Audit where Salesforce credentials currently live across your environment. Local credential stores on developer laptops (the Salesforce CLI’s keychain or .sfdx directory depending on version), workspace agent configurations on business-user laptops, Connected App client secrets in agent runtimes, JWT signing keys and refresh tokens in autonomous agent containers, MCP configuration files, CI/CD secret stores.
- Define the access pattern before the developers — and the business users — define it for you. If you wait, the default pattern becomes “whatever worked in the quickstart docs.” That pattern has led to credential exposure across every major AI agent ecosystem in the last six months.
- Make revocation a one-click operation, not a cross-team ticket. If you can’t kill an agent’s Salesforce access in under five minutes, you don’t have access control — you have a paperwork trail.
- Put an agent gateway in the traffic path. It is much easier to insert a gateway into a new integration than to retrofit one into an existing one that developers and business users are already depending on. And it is the single move that addresses all six governance problems at once, rather than solving them piecemeal.
The durable insight
Salesforce is not the last platform to go headless. Microsoft, Google Workspace, ServiceNow, Workday, and every major enterprise SaaS vendor is heading in the same direction. And the user population reaching those platforms through agents isn’t staying contained to developers — agentic workspace products are putting direct platform access in the hands of every knowledge worker in the organization. Within 18 months, “our platform is also an API, an MCP tool, and a CLI, accessible to every employee with an AI assistant” will be the default way enterprise software is delivered.
Credential exposure is one governance problem. Identity, authorization, data scope, anomaly control, and attribution are the other five. All six intensify when the agent population shifts from dozens of developers to thousands of employees. The six problems are a package — and so is the solution.
Governing AI agents is governing how they access APIs and MCP tools. Headless 360 just made that a Salesforce problem. It will be every vendor’s problem by the end of 2026.
For teams exposing Salesforce or other enterprise systems through MCP, an MCP gateway gives security teams an identity-aware enforcement point for tool access, rate limits, credential protection, and audit before agents reach the platform.
