TL;DR
- Salesforce Headless 360 turns the whole platform into APIs, MCP tools, and CLI commands. Agents now do the work that logins, screens, and clicks used to gate.
- An agent is only as constrained as the user it runs under. Salesforce binds each to a named user’s permissions, so a broad user means broad agent access.
- An agent reasons over data it never vetted. The ForcedLeak flaw (CVSS 9.4) showed a $5 expired domain turning a single sales lead into CRM data exfiltration through indirect prompt injection.
- Salesforce’s per-user identity and audit trail stop at the Salesforce boundary. Once an agent calls an external MCP server, another agent, or Snowflake or Databricks, the originating user is usually replaced by a service account.
- Trust3 AI Agent DOS covers the full journey. It discovers every agent and connected app, traces every action from user to data, and enforces purpose-based access at runtime, including past the Salesforce edge.
Dreamforce 2026 opens in San Francisco this week, and the agentic enterprise has moved from keynote promise to shipping product.
Five months ago, Salesforce co-founder Parker Harris posed the question that frames the whole shift: why should you ever log into Salesforce again?
Salesforce Headless 360 is the answer. It exposes the platform through APIs, MCP tools, and command-line commands. The first release shipped more than 60 MCP tools and 30 coding skills. An Agentforce agent can now pull customer context, update an opportunity, run a Flow, and coordinate work across systems with no screen in between.
For users, that removes friction. For security teams, it removes the interface that was quietly enforcing half of their controls.
We wrote about this shift when the interface melts, so do the controls. Headless 360 is that idea shipped. What follows is how the Salesforce agent stack works, where an outside agent can and cannot go, and what a security team has to add once the UI is gone.
The Salesforce Agent Stack in Plain Terms
Agentforce is Salesforce’s platform for building and running autonomous AI agents inside its clouds. A handful of terms carry the rest of this post:
- Agentforce agents are scoped by topics, the jobs an agent is allowed to handle, and actions, what it can actually do: run a Salesforce Flow, invoke Apex, call a prompt template, or hit an API.
- The Atlas Reasoning Engine is the planning core. It reads a request, retrieves context, picks a topic and an action, and executes.
- Data Cloud grounds the agent in your business data so its answers reflect real records.
- The Einstein Trust Layer wraps the model interaction with data masking, secure grounding, zero data retention, and a prompt audit trail.
- Headless 360 is the newest layer. It turns those same capabilities into APIs, MCP tools, and CLI commands that agents call directly. MCP, the Model Context Protocol, is the emerging standard for connecting agents to tools and data at runtime.
Put it together and an Agentforce agent is an authenticated actor that reasons over your data and takes real actions. It is reachable from Slack, a customer portal, a CLI, or another agent, with no Salesforce screen in the loop.
Where Salesforce’s Native Controls Stop
First of all, outside agents do not connect anonymously. A CLI, a desktop app, or an AI assistant like Claude or ChatGPT has to be registered as an External Client App and authenticated with OAuth before it can reach the hosted MCP server. Inside the org, every agent runs under an authenticated user’s identity and inherits that user’s permission sets, field-level security, and sharing rules. Every API call lands in Event Monitoring. On paper, that is a clean model.
Two structural limits sit underneath it.
The first is inheritance. An agent is only as constrained as the identity it runs under. Bind it to an over-provisioned user and it inherits every entitlement that user holds, on every request, whether or not the task needs it. Salesforce’s access model was built for people who open one record at a time. An agent reads at machine speed and uses the full grant. Salesforce’s own guidance is to build a permission set from scratch against the agent’s documented actions. In practice, agents get wired to broad, convenient identities because that ships faster, and one prompt can then reach everything that identity can see.
The second is reach. Salesforce’s controls govern what happens inside Salesforce. The moment an agent calls an external MCP server, hands work to another agent, or queries Snowflake or Databricks, the per-user identity and the Event Monitoring trail stop at the edge. Downstream systems see only a service account. They lose the person who started the request, and the audit trail can no longer say who caused what.
Neither limit is a flaw in Salesforce. Both are the seams where platform-native security ends and agent-and-data security has to begin.
Why Headless AI Moves the Security Boundary
An agent that authenticates correctly can still be turned against you, because it reasons over data it never vetted. ForcedLeak is the proof.
In 2025, security researchers disclosed a flaw in Agentforce, rated CVSS 9.4, that turned an ordinary sales lead into a data-exfiltration channel. The attack planted hidden instructions in the Description field of a Web-to-Lead form. When an employee later asked Agentforce to help work the lead, the Atlas Reasoning Engine read the attacker’s text as trusted context and followed it. It queried the CRM for sensitive records and sent them to an attacker-controlled domain, embedded in an image request. The researchers finished the exfiltration through an expired Salesforce-related domain they bought for about five dollars. It was still sitting in the platform’s trusted-URL allowlist. Salesforce patched it by enforcing the Trusted URL allowlist and re-securing the domain.
The lesson for a headless world is not that Agentforce is uniquely unsafe. It is that an agent cannot reliably separate instructions from data, and the interface used to be where a human caught the difference. A person reading that lead would have ignored the strange text in the Description field. The agent executed it. Multiply that across agents running with no screen, at machine speed, and the implicit review the UI provided is gone.
Catching that now falls to controls that watch the agent’s behavior directly. Runtime guardrails inspect each action for injection and sensitive-data egress. Purpose-based access asks whether a lead-processing agent has any business bulk-reading CRM records and sending them to an outside domain. That is the layer Trust3 AI adds on top of Salesforce’s native controls.
This is the security boundary Headless 360 moves. The controls that matter live at the agent and the data, not at the login. Headless AI needs a control plane built for that, and that is Agent DOS: discover every agent, observe every decision, secure every action.
Discover Every Agentforce Agent
Agentforce makes it easy for business and technology teams to stand up agents. That is good for adoption. It also means agents and the External Client Apps behind them multiply faster than a security team can track them.
Some agents are approved and documented. Others get built for a departmental experiment, wired to sensitive data, and quietly moved into daily use with no ticket and no owner. Static inventories and quarterly reviews cannot keep pace.
Trust3 AI continuously discovers Agentforce agents and the connected apps reaching your org, and builds a live system of record that captures:
- Agent name, owner, and the External Client App it authenticates through
- Agent identity and the user or service account it runs under
- Approved business purpose
- Configured topics and actions
- Connected APIs and MCP tools
- Reachable Salesforce objects and external data
- Risk signals and configuration gaps
Trust3 AI assigns each agent a Trust Score so security teams can prioritize. An agent with a clear owner, a narrow purpose, approved actions, and scoped data access is not the same risk as an unknown agent on a broadly privileged identity. You cannot secure an agent you do not know exists.
Observe Every Decision and Action
Knowing an agent exists is not enough. Security teams also need to see what it does.
A single Agentforce request can fan out into a prompt, a retrieval step, an Atlas reasoning step, a Salesforce action, an MCP tool call, an agent-to-agent handoff, and a query against an external platform. Salesforce Event Monitoring records the Salesforce API calls. It does not see the MCP server the agent called next, or the Snowflake query three hops later.
Trust3 AI connects these events into a complete runtime trace: who started the request, which agent handled it, what purpose it declared, which topic and action fired, which tools and agents it called, and what data moved. Every policy decision is recorded next to the action it governed.
That builds a chain of accountability from the original user to the final action. It matters because agent workflows lean on service accounts. When the originating user’s identity drops off after the first hop, downstream systems see only a broadly privileged service account. The action gets allowed even when the person who started it should not have had that access. Trust3 AI carries the identity and declared purpose across the workflow, so you can see what happened, who caused it, and why it was permitted.
Secure Every Action, All the Way to the Data
Observation tells you what happened. Security decides what happens next.
Trust3 AI evaluates each Agentforce action at runtime. It weighs the identity, the agent, the declared purpose, the requested action, the tool, and the data classification. That is purpose-based access control (PBAC), evaluated per request rather than per job title.
Consider an Agentforce sales agent allowed to read customer data. That access is appropriate when the agent is preparing an account brief for an authorized rep. It should not follow that the same agent can export thousands of records or push sensitive fields to an unapproved tool. The identity is the same. The purpose and the risk are different. Trust3 AI scopes access to the task:
- Limited to the current purpose
- Granted just in time, and expired when the task ends
- Restricted to approved tools and data
- Denied before execution when a request exceeds scope
Runtime guardrails catch sensitive-data exposure, suspicious tool use, prompt injection like the ForcedLeak pattern, and scope drift. Depending on policy, Trust3 AI can allow the request, mask the data, deny the action, quarantine the agent, or trigger a kill switch.
This has to reach the data layer, because there is no AI without data and no agent security without data security. An Agentforce agent may start inside Salesforce and then reach Snowflake, Databricks, BigQuery, OneLake, or S3. Trust3 AI extends authorization to the data source. It enforces row-level access, column-level access, masking, and purpose-based policy using the identity of the person who started the request. The policy follows that identity and purpose through the full chain, so the agent receives only the data the approved task requires, even when the service account behind it could reach far more.
Salesforce Secures the Platform. Trust3 AI Secures the Journey.
Take a concrete case. A rep asks an Agentforce agent to prep for a customer meeting: recent opportunities, open support cases, product usage, renewal risk. The agent reasons over the request and coordinates actions across Salesforce and connected systems. Trust3 AI works the whole path. It confirms the agent is registered and maps what it can reach. It traces the request, the reasoning, every action, and every data call. It verifies the rep’s identity and sales purpose. It allows the assigned account, masks unnecessary personal data, and blocks the agent from pulling unrelated accounts or pushing data to an unapproved tool. The rep gets the brief in seconds. The security team keeps control and evidence across the whole workflow.
Agentforce and Headless 360 are turning Salesforce from a destination people visit into a platform agents drive from anywhere. Salesforce secures that platform: identities, permission sets, sharing rules, topics, actions, the Einstein Trust Layer, and Event Monitoring inside the org. Trust3 AI Agent DOS secures the journey the agent takes beyond it: external tools, MCP connections, agent-to-agent handoffs, and the data platforms behind them.
Gartner projects that by 2029, more than half of successful attacks on AI agents will exploit access-control weaknesses to reach enterprise data. Headless 360 widens that surface. The enterprises that stay ahead of it will be the ones that can name every agent, trace every action, and enforce policy at the moment of access.
When the interface disappears, security cannot disappear with it.
Let’s chat further here: https://trust3.ai/demo/
Frequently Asked Questions
What is Salesforce Headless 360, and why does it change the security model?
Headless 360 exposes Salesforce as APIs, MCP tools, and CLI commands, so AI agents do the work that people used to do through the UI. Without an interface to mediate and surface agent actions, much of the security model built around human-computer interaction no longer applies. Enforcement has to move to the agent and data layers, which is where Trust3 AI Agent DOS operates.
Can external agents like Claude or ChatGPT access Salesforce through Headless 360?
Only when explicitly authorized. Salesforce requires each external client to be registered as an External Client App and to authenticate with OAuth 2.0 Authorization Code with PKCE, requesting scopes such as mcp_api. Every connection runs under an authenticated user’s identity and inherits that user’s permission sets, field-level security, and sharing rules. There is no anonymous access. The risk sits in how broadly that identity is scoped, and in what happens after the agent leaves Salesforce for external tools and data.
What was ForcedLeak, and why does it matter for agent security?
ForcedLeak was a critical Agentforce vulnerability (CVSS 9.4) disclosed in 2025. Attackers hid instructions in a Web-to-Lead form. When an employee processed the lead with Agentforce, the agent ran those instructions and exfiltrated CRM data to an attacker-controlled domain. The researchers had acquired that domain for about five dollars, because it was still on the trusted-URL allowlist. Salesforce patched it. The durable lesson is that an agent cannot reliably tell trusted data from injected instructions, so runtime guardrails and least-privilege scoping matter more once no human is in the loop.
What is the difference between Agentforce’s native security and Trust3 AI’s Agent DOS?
Agentforce’s native protections, including permission sets, sharing rules, the Einstein Trust Layer, and Event Monitoring, govern agent behavior inside Salesforce. Agent DOS extends governance across the full headless lifecycle, including external MCP servers, agent-to-agent chains, and downstream data stores that native Salesforce controls do not reach. It also carries the originating user’s identity all the way to the data source.
Does Trust3 AI slow down Agentforce agent performance?
No. Agent DOS enforces policy natively at the data layer and evaluates authorization in real time. Authorized actions complete without added proxy latency, while risky or unauthorized behavior is intercepted as it occurs.
Can Trust3 AI detect agents that were never officially approved?
Yes. Trust3 AI continuously discovers every Agentforce agent and connected External Client App in the environment, including ones created outside formal review. This surfaces the shadow agents that headless deployments make especially hard to see, since there is no interface to reveal them.
What happens when an Agentforce agent attempts an unauthorized action?
Trust3 AI Agent DOS flags or blocks the action before it completes, based on the agent’s verified identity, access path, and declared purpose. In a headless environment where no human reviews the action in real time, that automated enforcement is the primary line of defense.
Related Articles
