An AI agent connected to a Salesforce toolchain can do whatever the credential in its config file can do, and no more careful prompt changes that. So Salesforce MCP security is first a question of token scope: whose access the token carries, how many copies exist, and which tool calls leave a record. On the documents read for this piece, a role-scoped and tier-gated tool surface with audited executed calls is the stronger default for teams where admins and developers share one agent setup. A personal token is a reasonable fit for a single developer working in scratch orgs.
What the vendor documents actually say about tokens
A scope question is not a breach question, and treating the two as one is how teams either panic or shrug. Nothing here describes an incident.
Hutte runs a hosted MCP server and accepts two authentication routes. According to the Hutte MCP documentation, read 1 Oct 2026, a client authenticates with "OAuth 2.1, or a personal access token sent as Authorization: Bearer <token>". The same page carries the caveat that matters here: "A token carries the full access of the user who created it, so store it as a secret..."
That sentence is honest documentation, and it is the whole Salesforce MCP security story for that route: the token is scoped to the person who minted it, not to the agent's task. If an admin mints it, the agent holds admin reach inside Hutte.
Hutte does publish a restriction worth noting: per the same docs, billing users and integration managers see no projects through MCP. And Hutte's tool surface is environment-centric (claiming a pooled scratch org, creating a sandbox feature, authenticating an org with the local sf CLI), with metadata work handed to the local CLI.
How the local route moves the question
That handoff matters for Salesforce MCP security because it moves the credential question to the developer's laptop. The open-source Salesforce DX MCP server, read 1 Oct 2026, runs locally via npx using orgs already authorized through the Salesforce CLI, under an Apache 2.0 licence, at no cost. That is a genuine win for a developer who already manages their own org logins.
Inferred, not documented here: the agent's reach is bounded by the orgs that machine has authorized. The README documents mechanism; what a given laptop has authorized, no vendor page can tell you.
A constructed token inventory
Here is a constructed example, not a measurement.
Take a hypothetical team of five: two admins, three developers. Each creates a personal access token, and each token sits in two places, a laptop MCP config and a CI secret. That is 5 x 2 = 10 live token copies. Two of the five people are admins, so 2 x 2 = 4 of those copies carry admin reach.
Now a quarterly rotation policy: 10 copies x 4 rotations a year = 40 rotation events, each one a chance to leave an old token in a dotfile. If one in ten rotations misses a copy (an illustrative rate, not observed), that is 40 x 0.1 = 4 stale tokens a year. With 4 of 10 copies admin-scoped, about 40% of stale copies would carry admin reach. Re-checked: 10, 4, 40, 4, 40%.
None of this says a vendor is unsafe. For Salesforce MCP security, it says per-person tokens scale with headcount and machines, and each copy's reach is set by its creator's role.
What a role-scoped surface changes for Salesforce MCP security
The alternative design scopes the agent's tools to the role and plan of the person using them, rather than handing over everything the token creator can do. That is the design FlowSprite AI describes: its MCP surface is role-scoped and tier-gated, and every tool call the customer's AI executes is audited. The agent is any AI the customer brings. It drafts a Salesforce metadata change. FlowSprite AI lands the change as a pull request in the customer's private GitHub repo, the change is tested in a sandbox before production, and a human approves before anything deploys. Production is never auto-touched, and the change history lives in a GitHub repo the customer owns.
The Enterprise plan, EUR 199 per month for 25 users and 20 Salesforce connections, adds approval workflows with separation of duties and audit log export as CSV or JSON. Professional is EUR 99 per month for 10 users and 6 connections, and both have a 14-day free trial with no card.
The limits deserve equal weight. Per Hutte's pricing page, read 1 Oct 2026, Hutte offers a 30-day trial and scratch org pooling is a core feature; a team whose daily work is pooled scratch orgs will find Hutte fits better. A solo developer who wants a free, local, open-source server should start with the Salesforce DX MCP server. FlowSprite AI's audit is described as covering executed calls only, and its production safeguard is a workflow behaviour, human approval before deploy, rather than a technical lock.
Documented versus inferred, and what is still unknown
Documented: Hutte's token carries its creator's full access, Hutte offers OAuth 2.1 as an alternative, the DX MCP server uses locally authorized orgs, and FlowSprite AI's surface is role-scoped with executed calls audited.
Unknown: whether most teams use personal tokens or OAuth, since no public source reports that split, and how any vendor handles a token whose creator changes role. What would settle it is a dated test, minting a token, downgrading the creator, and recording which calls still succeed.
The standing advice for Salesforce MCP security
This beat keeps arriving at the same advice. Fail secure: prefer OAuth or a role-scoped surface over a personal token when one exists, mint tokens from the least-privileged account that can do the job, keep one inventory of every copy, and revoke on role change rather than at the next rotation. Salesforce MCP security is a list of what each credential can reach, kept current. The token you cannot locate is the one that still works.