If You Can Do It in Salesforce, Your AI Agent Can Do It Too

Every enterprise platform that puts an AI agent behind an existing employee's login eventually has to answer the same question, and Salesforce is not the first vendor this desk has watched answer it. Your Bourse answered it for a broker's own dealers and risk managers, connecting an assistant to Trade Server through whatever a trading employee's own credentials already carried. Salesforce answers it at a different scale entirely: not one backend product, but the platform millions of admins, dealers, service agents and developers already use to run CRM, service, commerce and data operations for their employer.

What actually shipped, and when

Three separate dates matter here, and this record keeps them separate on purpose. The Headless 360 MCP Server itself has been a Beta Service since July 2026, documented on Salesforce's developer site as an open beta and introduced in a developer blog post dated 14 July 2026, built on top of Salesforce Hosted MCP Servers, which reached general availability in April 2026 at Salesforce's TDX developer conference alongside the original, broader Headless 360 product. Neither of those is new news, and this record does not treat it as such.

What is new is a 19 August 2026 expansion. Salesforce's own newsroom post, corroborated consistently across independent coverage the same day, describes Headless 360 broadening across the platform: new Model Context Protocol servers, expanded Data 360 capability, a generally available Slackbot MCP client connecting to more than 20 partner applications, developer tooling and more than 100 reusable Agent Skills, framed as turning Salesforce's clouds into what Salesforce calls a governed capability fabric for agents. Salesforce's own newsroom republished substantially the same story to its Asia Pacific edition on 25 August 2026, the date this radar treats as today. This record does not count that as a second, independent development. It is the same announcement, syndicated regionally, and citing it twice would manufacture a second market vote for one underlying event, exactly the kind of duplication this desk's evidence ledger is built to prevent.

None of this is Headless 360 launching today. The Headless 360 MCP Server has been running in open beta for a month and a half before this radar date, and the platform it sits inside is older still. What is dated to this week is an expansion of what surrounds it, and this record is careful not to describe a beta service running since July as something that just arrived.

One announcement, nine components, several different maturities

The 19 August material is explicit that the components it bundles are not at the same stage, and this record preserves that rather than rounding everything up to generally available or down to beta. The Headless 360 MCP Server itself remains an open beta. The Data 360 MCP Server, exposing close to 200 APIs for building semantic models, transforming data and activating campaigns through natural language, reached general availability. Prebuilt Agent Skills for Data 360 are documented with general availability targeted for August 2026. Expanded Data 360 API coverage is documented as generally available. Salesforce's multi framework support for agent frameworks beyond Agentforce is documented as generally available. The Headless Experience Layer, covering web, mobile and conversational surfaces, remains in open beta, on the same footing as the MCP server itself. The Agent Skills repository is documented as generally available. Headless Commerce, letting an AI driven storefront and developer agents reach commerce functions directly, is documented as generally available and deployable. Slackbot's MCP client, connecting Slack to more than 20 partner applications including Atlassian, Box, Canva, Docusign, Notion and Zoom, reached general availability alongside the rest.

Two things follow from that spread that matter for authority specifically. First, the component actually carrying the consequential Setup and administration capability this record is most concerned with, the Headless 360 MCP Server itself, is the one still in open beta, not the ones that reached general availability around it. Second, Salesforce's own customer example for the launch, Engine standing up its EVA support agent in twelve days and resolving half of its chat interactions, is a Data 360 and Agentforce story about customer facing conversation volume. This record found no evidence tying that customer's production deployment specifically to the beta MCP server's Setup and user administration skills, and does not borrow one component's adoption evidence to vouch for another's.

The four tools, and what Dispatch actually checks

Salesforce's own reference documentation for Headless 360 describes a server built around four tools rather than one API surface exposed as thousands of individual functions. Discover takes an agent's interpretation of a request and runs a semantic search across a vector index of Salesforce APIs and skills, returning ranked candidates. Describe pulls the technical contract for a chosen skill, its parameters, dependencies and the ordered steps required to use it, letting an agent verify what Discover surfaced before acting on it. Dispatch invokes the selected operation, routes the request to the correct endpoint, and, in Salesforce's own documented language, enforces the access guard before anything runs. Dispatch Read Only performs the same invocation in a mode that never writes data or configuration.

What matters most for Agent Authority is what that access guard actually evaluates, and Salesforce's documentation is specific rather than vague on this point. Every Hosted MCP transaction runs as the authenticated user, not a shared integration account, scoped through an External Client App carrying the mcp_api OAuth scope. That scope was deliberately introduced narrower than Salesforce's general purpose api scope, which grants broad platform API access across REST, Tooling and Metadata; mcp_api exists specifically so a connected AI client does not have to be granted that wider surface just to use Hosted MCP. Once a call reaches Dispatch, ordinary Salesforce authorization applies exactly as it would to a request from the browser: object level CRUD permissions, field level security, sharing rules, profile permissions and permission sets. Salesforce's own summary of the consequence is direct: if a user cannot perform an action in Salesforce, their agent cannot perform it through the MCP server.

Read closely, that is a real and verifiable claim about where the check happens, and this record credits it as one. It is also a narrower claim than it can sound. The access guard answers whether the authenticated principal has technical permission to perform an operation. It does not, on any documentation this record could verify, evaluate whether this specific operation, proposed by this specific agent, for this specific purpose, is one the person actually meant to authorize when they connected an AI client to their org.

What inherited trust actually composes to

Salesforce's own marketing language for this architecture is confident. Its product material describes inherited trust and security, and states that every experience inherits identity, permissions, compliance, observability and secure data access. Its 19 August material, corroborated independently, describes agents inheriting existing permissions, workflows, validation rules and governance controls. This record treats that language as a claim to verify against the documented mechanism, not as the mechanism itself, the same discipline already applied in this desk's coverage of Your Bourse and of Claude Code's own subagent fork inheritance.

The documented mechanism does not hand an agent the user's permissions as a single object. It composes a ceiling out of four independent constraints, each of which can narrow what actually executes, and this record represents that composition explicitly rather than collapsing it into one word. The first constraint is the authenticated user's own Salesforce permission set: object CRUD, field level security, sharing rules, profile permissions and any permission set assigned to that person. The second is the External Client App itself, an administrator configured OAuth application scoped to mcp_api, which by default any user in the org can authenticate through, but which an administrator can restrict to specific users by requiring a custom permission set before the ECA will authenticate them at all. The third is which operations the Headless 360 MCP Server currently exposes at all: roughly 100 skills at the time of this record, most of them Setup focused, against Salesforce's own stated plan to grow that library over the course of the beta. The fourth is whatever tool level restriction the specific MCP client a person connects happens to enforce, which is not a Salesforce control at all, and which this record addresses on its own below.

Effective authority, on the documentation this record could verify, is the narrowest point across those four constraints, not the user's permission set alone. A dealer level Salesforce user with full CRUD on the Account object still cannot reach an operation Dispatch has not yet exposed in beta, still cannot connect at all if an administrator gated the ECA behind a permission set that person lacks, and, if their MCP client is configured to require approval before consequential writes, still has that action held for confirmation regardless of what their Salesforce profile alone would permit. This record does not describe that composition as a formally monotonic guarantee, because the fourth constraint is optional, client dependent, and, on Salesforce's own documented position below, not something the platform can compel a client to enforce. What is accurate is narrower: on every path Salesforce documents, none of the four constraints can widen what a user's own Salesforce permissions already allow. Nothing this record found describes an alternate credential, a shared integration user, or a machine to machine flow that would let an agent reach further than the connecting human's own login, and Salesforce's own security guidance states plainly that there is no plan to allow machine to machine authentication for Hosted MCP at all. A human stays in the loop to connect to the org and grant access, on every path this record could verify.

Consequential capability: what is documented in beta, and what is direction

Salesforce's own beta announcement is specific about what ships today rather than what the architecture is eventually meant to reach, and this record keeps that same line. At launch, the majority of the roughly 100 skills behind the Headless 360 MCP Server are Setup operations for administrators, extending the kind of capability already present in Agentforce for Setup to any MCP aware client. Salesforce's own material names concrete examples: an agent can query, create and update Salesforce records; manage users, including creating, deactivating and freezing a user, and assigning permission sets and permission set licenses; read, write and deploy Apex triggers; build event driven integrations spanning platform events, Change Data Capture and event relays; and create named credentials, including authentication mechanisms, endpoints and certificate handling. Salesforce's own worked example for the last of those is instructive on how these skills chain: an agent asked to send Account change events to an external destination uses Describe to work out that a named credential must exist before the event relay can be configured, then uses Dispatch to create the credential, configure Change Data Capture and stand up the relay in sequence, each individual Dispatch call still checked against the same access guard described above.

Separately, and this record states it plainly rather than letting the architecture imply it, Salesforce describes an eventual goal of exposing the breadth of what a business user can do across every Salesforce cloud through this same mechanism, growing from around 100 skills toward what the company describes as thousands. That is a stated direction, not a documented current capability, and this record does not treat Salesforce's account of where the architecture is headed as evidence of what an agent connected to a production org can do today. The distinction matters specifically because the most consequential documented skills, user deactivation, freezing an account, and assigning a permission set or a permission set license, are already live in beta, not future roadmap. An agent operating on the credentials of a Salesforce administrator can, today, be asked to deactivate a colleague's account or grant a permission set that widens someone else's access, gated only by whether the connecting administrator's own profile already permits that action and by whatever the connecting MCP client chooses to confirm before running it.

Client side approval, and where Salesforce actually draws its own line

Salesforce's own best practice guidance for securing Hosted MCP Servers is explicit about where it places responsibility for a pre execution check on a consequential action, and it is worth being precise about which side of the boundary that guidance actually sits on. Its documented recommendation is that most MCP clients let an operator set tool level restrictions, and that a person should configure their client to require approval before it runs a tool that changes org configuration or alters or deletes data on their behalf, describing an unconfirmed default as a recommended starting point rather than a shipped guarantee. That is a real, specific, and useful piece of guidance. It is also, on the documentation this record could verify, a statement about client behavior, not about anything Dispatch itself withholds.

Nothing this record found describes a server side hold state inside Dispatch, a risk classification attached to a specific skill, an approval callback the MCP server issues before a consequential call proceeds, or any mechanism by which Salesforce itself pauses a Dispatch call pending human confirmation, independent of whether the connecting client happens to implement one. The access guard, as documented, checks whether the authenticated user is permitted to perform the action. It does not, on this record's reading of the available documentation, ask whether this specific proposed action, right now, should proceed. Those are the same two questions this desk has already found split apart at Google's Agent Gateway, where a documented Semantic Governance Policy runs as infrastructure the agent cannot argue with, and at Microsoft's Azure SRE Agent, where mutations require approval as an architectural default rather than a client convention. Salesforce's own documented architecture does not yet describe an equivalent server side gate for Headless 360 specifically. Moona Intelligence records that as an honest reading of what the current documentation supports, not as a claim that Salesforce considers the gap acceptable or has no further plans, since this record found no statement either way on Salesforce's own intentions here.

The practical consequence follows directly and should be stated carefully rather than dramatically. On the documentation this record could verify, a person connecting an MCP client that does not implement tool level approval, whether by misconfiguration or by using a client that does not support the pattern at all, and who holds broad Salesforce permissions such as an administrator profile, could have Dispatch execute a consequential operation, including deactivating a user or assigning a permission set, without any human confirmation beyond the original decision to connect that client to their org. Salesforce's own recommendation exists precisely because this is possible, not because it is prevented. Salesforce's own Slack Code, launched the following day on 20 August 2026, describes the identical shape of gap for a different product: an agent packages a production change for an expert to sign off on, right in the channel, but Slack states plainly that Slack Code is not a runtime and does not execute the deployment itself, so the sign off sits on a surface that cannot enforce what happens on the other side of it. Two Salesforce products, documented within one week of each other, describe the same pattern: a real, useful, human facing confirmation step, sitting beside a technical execution boundary that does not itself require it.

What the audit trail actually distinguishes

Salesforce documents that Hosted MCP activity is captured through ordinary Event Monitoring rather than a separate logging system built specifically for agents. An administrator filters the Event Log File Browser's API Total Usage event type for rows where the API_CLIENT_CATEGORY column reads SALESFORCE_HOSTED_MCP, which isolates MCP traffic from ordinary browser and API activity. Within those rows, Salesforce documents that the authenticated user who called the MCP tool and the Salesforce object or entity affected are both recorded, alongside a status code and the calling client's IP address. Separately, Salesforce's broader API monitoring model ties any logged API call to the specific connected application that carried it through a CONNECTED_APP_ID field, which for a Hosted MCP call resolves to the External Client App the person authenticated through.

Read against this record's central question, that is a genuinely useful, if partial, answer. A later reviewer can determine, from Event Monitoring alone, which authenticated human's credentials were used, which registered External Client App carried the call, which operation ran, against which record or entity, and whether it succeeded. What this record found no documentation for is any field distinguishing the AI agent or model that proposed the action from the External Client App that connected it, any record of the Discover or Describe calls that led an agent to the eventual Dispatch, preserved as a linked reasoning trail rather than as separate, unconnected log rows, or any distinct marker separating an action a human directly initiated at a keyboard from one an autonomous agent proposed and a human merely authorized by connecting their credentials to a client in the first place. A Setup Audit Trail entry for a permission set assignment made through Dispatch, on the evidence this record could verify, looks like any other Setup Audit Trail entry: a user, an action, a timestamp. It does not itself record that an AI agent, rather than the user directly, was the one that decided to make that specific change.

Revocation, and what happens to authority already granted

Salesforce documents real, specific mechanisms for withdrawing MCP access, and this record credits them precisely rather than either overstating or dismissing them. An administrator can revoke an External Client App's tokens individually or in bulk through Setup's OAuth Usage page. Where Single Logout is enabled for the org, revoking a person's Salesforce session terminates the corresponding MCP client session at the same time, which Salesforce specifically frames as useful for immediate revocation when an employee leaves. Absent an explicit revoke or Single Logout, the access token issued when a person first authenticates through the ECA defaults to a one year lifetime, though Salesforce documents that an administrator can and, for production use, should reduce that duration.

What this leaves unaddressed, and what this record preserves as undocumented rather than assumed, is the state in between those explicit actions. Nothing this record found states whether deactivating or freezing the underlying Salesforce user immediately invalidates an access token already issued to their MCP session, independent of whether Single Logout happens to be configured, or whether that token instead continues to authenticate Dispatch calls, subject only to whatever the user's now deactivated permission set no longer allows, until it is separately revoked or expires on its own. Nothing this record found describes what happens to a Dispatch operation already in flight, mid execution across the sequence Describe laid out, at the moment the underlying authorization changes. Where Salesforce's own documentation does not state an answer, this record states none either.

The Authority Provenance ledger

Moona Intelligence separates what Headless 360's architecture technically permits from what it establishes about who was entitled to grant that permission, the same discipline this desk has already applied to Your Bourse, to Grantex and to Slack Code, rather than letting a documented, working access control stand in for a fully proven chain of authority.

Authority grantor. Documented at the level of the authenticated Salesforce user and the administrator who configured the External Client App they connect through. The immediate technical ceiling on any Dispatch call is the connecting user's own Salesforce permission set, whether that person is an administrator, a service agent or a developer. An administrator separately controls whether the ECA authenticates any org user by default or only users holding a specific permission set. This record does not collapse either of those into the Salesforce organization's own ultimate legitimate authority over its data and configuration; Salesforce's documentation identifies who is logged in and who configured the connecting application. It does not identify, beyond that, an organizational principal responsible for deciding that this class of action should be exposed to an agent at all.

Mandate or basis. Undocumented. A working Salesforce login, an mcp_api scoped External Client App, and a Salesforce permission set that technically allows an action together establish that the connecting user could perform that action themselves. Nothing this record found in Salesforce's Headless 360 documentation, its Hosted MCP security guidance, or its Setup Audit Trail material establishes a distinct approval, policy acknowledgment or organizational sign off an employee passes through before connecting an AI client to credentials that can deactivate colleagues, assign permission sets or deploy Apex, separate from simply holding a working login the administrator did not specifically restrict. This record preserves that as the central gap it is, rather than inferring an internal approval process an organization's own policy might or might not separately require.

Delegated scope. Documented as an intersection rather than a single grant, verified above: the connecting user's own Salesforce permissions, the mcp_api scoped External Client App and any permission set gating it, the roughly 100 skills currently exposed by the beta Headless 360 MCP Server, and, optionally and client dependently, whatever tool level restriction the connecting MCP client enforces. This record does not describe the last of those as a Salesforce enforced boundary, because Salesforce's own documentation frames it as a client configuration choice it recommends rather than one it can compel.

Explicit limits. Split cleanly between two layers this record keeps visible rather than merged. Server side and Salesforce enforced: object CRUD, field level security, sharing rules, profile permissions, permission sets, the narrower mcp_api scope in place of the general api scope, and optional ECA gating by permission set or IP range. Client side and not independently enforced by Salesforce: tool level approval gating, which Salesforce recommends and documents as a client feature rather than a platform guarantee.

Inherited permissions or assumptions. This is the strongest and most directly documented finding in this record. The connecting agent's effective ceiling mirrors the authenticated user's own Salesforce permissions rather than receiving a separately configured, narrower Agent specific grant beyond the mcp_api scope and beta skill availability layered on top of it. Salesforce's own language, that if a user cannot perform an action in Salesforce their agent cannot perform it either, is documented and this record credits it directly. This is human to agent permission inheritance, a single hop from an authenticated person to the agent acting through their session, and this record deliberately keeps it distinct from the agent to agent Authority Inheritance question this desk has already covered in Claude Code's subagent forking and in Grantex's delegation protocol, where one already created agent hands authority to a second. Nothing in Headless 360's documented architecture describes an agent created by another agent, or a delegation chain deeper than the one human principal and the session Dispatch checks against.

Revocation or modification. Partially documented, verified above. Explicit administrator action, individual or bulk token revocation through OAuth Usage, is real and immediate. Session linked revocation through Single Logout is real where an org has enabled it. Absent either, a token defaults to a one year lifetime an administrator can shorten. What happens to an already issued token at the exact moment the underlying user is deactivated or frozen, absent Single Logout, and what happens to a Dispatch operation already executing mid sequence when authorization changes beneath it, are both undocumented on the evidence this record could verify, and this record states that gap rather than assuming immediate effect.

Challenge authority. Documented only as a client side recommendation, verified above with precision rather than generosity. Salesforce recommends configuring the connecting MCP client to require approval before a tool changes org configuration or alters or deletes data, and describes that as a recommended starting point. This record found no server side hold state, risk classification, approval callback or other pre execution human challenge mechanism documented inside Dispatch itself, and does not invent one. On the documentation available, an authenticated high privilege user connected to a client that does not implement that recommendation could have Dispatch execute a consequential operation without it.

Recovery path. Undocumented as a distinct Agent Authority mechanism, and external where it exists at all. Salesforce's own material describes no Headless 360 specific process for reactivating a wrongly deactivated user, reversing a wrongly assigned permission set, or rolling back a deployed Apex trigger, distinct from whatever ordinary Salesforce administration, metadata deployment history or user reactivation already exists for any change made through the standard interface. This record does not treat ordinary Salesforce administrative remediation as a documented Agent Authority recovery model, because nothing reviewed here frames it that way.

Provenance evidence quality. Uneven, and stated in parts rather than as one figure. Strongly documented: the authenticated user access guard, the narrower mcp_api scope, the four tool architecture and Dispatch's role within it, the specific list of consequential beta skills, and Event Monitoring's ability to attribute a call to a user and a connected application. Weakly documented or absent: any organizational mandate behind a user's decision to connect an agent to consequential Setup permissions, any server side challenge mechanism distinct from a client's own optional behavior, the precise effect of revocation on an already issued token or an in flight Dispatch call, and any audit field distinguishing an agent's proposed action from the human credential that carried it. The strongest evidence in this launch is about what ceiling an agent's authority cannot exceed. The weakest is about who decided that ceiling should be reachable by software at all.

Why this is not the same record as Your Bourse, and not the same as a subagent fork

Your Bourse inherits an employee's Trade Server permissions into an assistant with no documented Agent specific scope layer at all, a single vendor's backend reached by a narrow set of institutional roles. Salesforce's architecture is not a smaller version of that pattern. It is the same underlying question, human to agent permission inheritance through an authenticated session, arriving from the platform that runs CRM, service, commerce and data operations for a very large share of enterprise software customers, with a documented, if beta stage, skill set that already reaches user administration, permission assignment and Apex deployment rather than trade execution alone. It is also not the agent to agent Authority Inheritance question this desk has tracked in Claude Code's subagent forking and in Grantex's bounded delegation protocol, where an already authorized agent hands a narrower or broader grant to a second one it creates. Headless 360 has exactly one hop: an authenticated human, and the session Dispatch checks against. The broader argument this desk has made since February, that technical permission and execution authority are not the same fact, holds here in its clearest enterprise form yet: Salesforce can determine, precisely and verifiably, whether the authenticated user is permitted to deactivate a colleague. It does not, on the documentation this record could verify, establish that the colleague's manager, a compliance function, or anyone else at the organization decided an AI agent should be the one making that call.

Claudeforce: the same architecture, shipped as a named product

On 26 August 2026, Salesforce and Anthropic announced Claudeforce, described in Salesforce's own material as an expanded strategic partnership bringing Claude's reasoning together with Salesforce's data, workflows, business logic, actions and governance. The structure is explicitly reciprocal: Claude moves into Salesforce as a reasoning model inside Salesforce's own products, and Salesforce moves into Claude as a plugin. The first shipped piece of that second half is Salesforce in Claude, a Plugin carrying 37 prebuilt sales skills, covering meeting preparation, deal health review and pipeline analysis, that Salesforce's own material and independently corroborated coverage describe as letting a seller query, update and act on live CRM data without opening Salesforce at all. Salesforce states plainly that this ships to select pilot customers today, with an open beta planned for September 2026 and additional skills for other business functions arriving later in the year. This record does not describe Salesforce in Claude as generally available on any evidence it could verify, and treats the pilot and open beta stages as the accurate current maturity, consistent with how it already treated the Headless 360 MCP Server itself as beta rather than shipped.

What matters most for this record is not that a new product shipped, but what it is built on. Salesforce's own language for Claudeforce states that Salesforce in Claude routes actions through Salesforce so that business rules are enforced when an action is taken, and independently corroborated detail describes the mechanism in terms this record already verified above: a seller's query inside Claude calls the Salesforce MCP server, which retrieves only the data that seller already has permission to see, checks business rules before a write commits, and returns results through the same permission layer. Read against the architecture this record has already verified in detail, that is not a new authority model. It is the authenticated user, mcp_api scoped, Dispatch mediated architecture this record documents above, now surfaced as a named, first party Plugin experience inside Claude's own product rather than a generic MCP client connection an administrator configures by hand. Nothing this record found in the Claudeforce material describes a distinct Claude or Salesforce service principal, a shared integration account, or a machine to machine credential; the general Hosted MCP documentation this record already cites states there is no option to specify a service account in place of the authenticated user, and this record found nothing in Claudeforce's own material that contradicts that. Moona Intelligence treats Claudeforce, Headless 360, Salesforce's product pages describing it and Anthropic's own Salesforce connection documentation as one underlying architecture cited from several related artifacts, not as separate, independently weighted developments, consistent with this record's evidence deduplication rule stated above.

What "governed action" verifies to, and what it does not yet answer

Salesforce's own examples of the 37 skills split unevenly between reasoning and writing, and this record represents that split rather than rounding it up. Meeting preparation and deal health review are described as Claude reasoning over existing account, opportunity and activity data, an analytical and read oriented function. Pipeline updates are described differently and explicitly as writing back: Salesforce's own framing states an agent can update records with governed permissions. This record found no enumerated, skill by skill breakdown of which of the 37 published skills read only, which analyze without writing, and which mutate a record, and does not imply that all 37 perform consequential writes. What it can state precisely is that at least one of the three named categories, pipeline updates, is documented as a write path, and that Salesforce's own account of what makes it governed is the same access guard mechanism this record already verified: object permissions, field level security, sharing rules, and the validation rules, approval processes and flows Salesforce's own language names as the layer a proposed action passes through before it commits.

That is a real answer to where enforcement happens, and this record credits it precisely rather than either inflating or dismissing it. It is not, on the evidence this record could verify, a new answer to whether a specific proposed action is one a human meant to authorize before it runs. This record found commentary, not confirmed Salesforce or Anthropic documentation, describing configurable autonomy on the write side and human confirmation for critical updates; that commentary describes the same client side, operator configured approval pattern this record already verified above as a documented recommendation rather than a server side hold Dispatch itself enforces, and this record does not treat secondary commentary as evidence of a new, Claudeforce specific challenge mechanism. On exact action binding, argument scope, expiry and replay behavior for any approval step Salesforce in Claude might present, this record found nothing in Salesforce's own material and preserves that as undocumented rather than assumed. The same is true of what happens to a pipeline update mid execution if the seller's permission set changes, whether an organization can exclude a specific seller from the Plugin once an administrator has connected it, and whether Event Monitoring can distinguish a Salesforce in Claude call from any other Hosted MCP transaction beyond the connected application identifier this record already documents above; none of these newly surfaced.

What Claudeforce adds cleanly to this record's central finding is the admin enablement language itself, which this record reads as Authority Provenance evidence rather than as a settled answer. Salesforce states that an administrator connects Salesforce in Claude a single time, that authentication and permissions are managed centrally, that every seller on the team receives access without per user setup, and, explicitly, that no new permissions model needs to be built. That last phrase is the most precise piece of evidence Claudeforce contributes to this record's thesis, and it strengthens rather than weakens it. Salesforce is not describing a narrower, separately audited Agent specific grant layered under administrator review seller by seller; it is describing the deliberate reuse of each seller's existing Salesforce permission set as the execution envelope for AI mediated action, at the scale of an entire sales organization, connected once. That architectural choice is coherent, and this record does not call it a flaw. What remains unproven, on everything this record could verify about Claudeforce specifically, is the same gap already open in Headless 360 itself: an administrator's authority to connect an integration is not, on its own, documented evidence that the organization decided every technical permission inside that integration's reach was meant to be delegable to an AI agent. Proof that a seller can update a pipeline in Salesforce is not proof that the seller, or the organization employing them, decided Claude should be the one updating it.

The question this launch actually raises

Every part of Headless 360's access guard that this record could verify works exactly as documented, and that is worth saying plainly rather than only as a preface to what is missing. Object permissions apply. Field level security applies. Sharing rules apply. An agent cannot reach further than the human whose session it is running inside. That is a real, working technical boundary, built directly into the platform rather than bolted on afterward, and it is more than several of the systems this desk has reviewed can currently claim.

What it leaves open is the question underneath it. A Salesforce administrator's permission set was granted for a reason, presumably tied to that person's job, their judgment, and an organization's trust in how they would exercise it. Nothing in Headless 360's documented architecture establishes that the same organization separately decided that judgment could be exercised by software connected to that person's login instead. Access answers whether the action is technically possible. It does not answer whether anyone meant to authorize a machine to take it.