A Salesforce change audit that stops at "the token did it" has not finished. When an AI assistant edits metadata, the useful question is whose credential carried the call, what that credential was allowed to do, and whether a person approved the result before it moved. One record that can answer all three is a pull request history joined to a log of executed tool calls, kept somewhere the team owns. Where the trail ends at a shared credential, the cause stays unknown, and the honest report says so.
What the record shows, and over what window
Every AI change leaves two marks: the metadata diff and the authentication event that let the assistant reach the org or the tool. The diff is easy to keep; the authentication event goes missing. A team reviewing a month of changes can say what changed; whether it can also say which assistant, under which identity, made each one depends on how each assistant authenticated.
A commit is not an attribution. A Salesforce change audit has to separate the two, the same way a delivery report separates "the message left" from "the receiver accepted it."
The instrument behind a Salesforce change audit, and its blind spots
The instrument is whatever log records the call. Its blind spots come from how the assistant authenticated. Vendor documentation, read on 1 October 2026, describes several distinct models:
- Hutte's MCP server accepts OAuth 2.1 or a personal access token, and the Hutte MCP documentation states that "A token carries the full access of the user who created it, so store it as a secret."
- The Salesforce DX MCP server runs locally and uses credentials already authorized through Salesforce CLI, according to its README.
- Salto states that "Agents don't touch the business apps themselves, but only the Salto workspace," according to the vendor's page, read 1 Oct 2026.
- For Claudeforce, the Salesforce press release of 26 Aug 2026 says an admin connects Salesforce in Claude once, "with authentication and permissions managed centrally," according to the release, read 1 Oct 2026.
These are facts about where identity sits, not verdicts. The inference, labelled as one: a personal token shared across three assistants produces a log in which all three look like one person.
Authentication state as fact, not verdict
Documented and inferred need separate columns. Documented: Hutte's token inherits its creator's full access. Documented: the DX MCP server runs on credentials already authorized through Salesforce CLI, per its README. Documented: Gearset's Cam page states "a full audit trail for compliance," according to the vendor's page, read 1 Oct 2026. Inferred: the DX MCP server can do what that CLI login can do, and in each case the audit trail is only as specific as the identity that authenticated, because a log can only record the identity it was handed.
Where competitors win deserves a line, according to each vendor's page, read 1 Oct 2026. Hutte and Gearset both list 30-day trials with no card, longer than FlowSprite AI's 14 days. Scratch-org pooling is Hutte's core pitch. The DX MCP server is free and open source under Apache 2.0. Salto lists Salesforce plus NetSuite, Zendesk, Jira and Okta.
A constructed trace, with the arithmetic
This example is constructed, not measured. A team of six admins runs three AI assistants against one org. Over 30 days, the assistants produce 40 metadata changes. Each change should join three records: the pull request, the approval, and the executed tool call.
That is 40 x 3 = 120 records to reconcile. Now suppose all three assistants share one personal token. Each change has three possible assistants and the log names one human, so no change can be pinned to an assistant from the log alone. The token resolves all 40 to the same person: attribution is 0 of 40.
Split the credentials per assistant and each of the 40 changes resolves to one of 3 named assistant identities: 40 of 40 attributable. Only the authentication record changed.
Where FlowSprite AI fits in a Salesforce change audit
The customer brings any AI to FlowSprite AI, and the assistant drafts a Salesforce metadata change. The change lands as a pull request in the customer's private GitHub repo. It is tested in a sandbox first, and a human approves it before deploy. Production is never auto-touched. Its MCP surface is role-scoped and tier-gated. Every tool call the customer's AI executes is audited, and that wording is precise: it covers executed calls, so read it as a record of what ran, not of every attempt. For a team that needs a Salesforce change audit it can carry out of the vendor, FlowSprite AI puts approval workflows with separation of duties and audit log export in CSV or JSON on its Enterprise plan, EUR 199 a month for up to 25 users. Professional is EUR 99 a month for 10 users, and there is a 14-day free trial with no card.
Fit conditions, per vendor pages read 1 Oct 2026: if pooled scratch orgs are the main need, that is Hutte's core pitch; if a suite is, AutoRABIT lists ARM, Vault, CodeScan and Guard, and Flosum's FAQ names regulated industries; the DX MCP server is free with local CLI credentials.
What is still unknown, and what would settle it
No vendor page read for this piece publishes how often audit records fail to arrive, so delivery completeness for any Salesforce change audit is unmeasured here.
What would settle it is a single test: pick five recent AI changes and, for each, name the assistant, the identity it authenticated as, and the approver, using only records the team owns. If any of the five ends at a shared token, the trail stops there.
The standing advice this beat keeps arriving at is the same as in mail: authenticate each sender separately, keep the record where you can read it, and treat an unattributed Salesforce change audit as unresolved, not clean.