TrustFall and the procurement question for any regulated buyer adopting agentic coding tools

All four major agentic coding CLIs spawn unsandboxed MCP servers from a malicious repository on a single Enter keypress. The vendor's reading is "the user gave consent." A regulator's reading, the moment this lands in a council or asset-management dev pipeline, will be different.

§1What TrustFall actually is

Adversa.AI's TrustFall disclosure describes a uniform pattern across the four major agentic coding CLIs — Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI. All of them, by default, ship a "trust this folder?" dialog on first contact with a new repository. All of them, on Enter, will read a project-level .mcp.json or .claude/settings.json and spawn the MCP servers it declares — as unsandboxed processes with the developer's full user privileges. The dialog is a single Enter. The configuration is plain JSON committed to the repo.

An attacker doesn't need a zero-day. They need an attractive open-source repo. The developer clones it, runs Claude Code against it, presses Enter on the trust dialog. The MCP server defined in the repo runs. It can read SSH keys, deploy keys, signing certs, AWS profiles, anything the developer's user account can read. In a CI/CD pipeline — same trust dialog, no human in the loop — the payload is harvested at scale. That's the supply chain crisis framing in the SecurityWeek headline, and it's the right framing.

Anthropic's published response is that pressing "trust" constitutes informed consent. As a Terms of Service position, it's coherent. As a regulatory position, it isn't.

§2Why this is a procurement question, not a developer-hygiene question

The community read on TrustFall has been "developers should be careful." That's true and almost beside the point. Three categories of buyer cannot route this through individual developer discretion:

• UK Local Authorities who are about to procure agentic coding tools to keep up with central government's AI productivity targets. The Cabinet Office expects councils to adopt these tools. The ICO expects councils to do a Data Protection Impact Assessment when they do.
• FCA-regulated firms bound by SS1/23 §3.4, which extends model risk obligations into the supply chain. A signed-in dev environment that can be hijacked by a cloned repo is a model supply-chain control failure, not a developer mistake.
• NHS Trusts running the DSPT, where the path from "developer's machine" to "patient identifier" is shorter than anyone wants to draw on a whiteboard.

For all three, "the developer accepted the prompt" is not a defence. The supervisor's question is: did your tooling default-deny or default-allow on a privileged action? If default-allow, do you have a compensating control? Most procurement teams at councils and asset managers will not be able to answer that question for any of the four tools above today.

The TrustFall pattern fails the standard procurement test that privileged actions must require an authorisation step distinct from the action itself. Pressing Enter on the same dialog that displays the consequence is not a separate authorisation step. Mature CI/CD platforms have known this since Jenkins 1.x.

§3What changes — and what doesn't

This isn't an argument against agentic coding tools. They are a 5-10× productivity multiplier on a normal week and we use them daily. It's an argument that regulated adoption needs a different default posture.

What changes:

• Project-level .mcp.json and .claude/settings.json are an inbound supply-chain attack surface. They should be treated like any other piece of executable code arriving from outside the perimeter — reviewed before execution, never auto-trusted.
• The trust dialog itself is the wrong control. A second-channel approval (a signed allow-list, a CODEOWNERS gate, a dev-environment policy) is the right one.
• CI/CD is the high-priority case. A trust prompt fired by a build runner is, by definition, not informed consent — there is no human reading it.

What doesn't change:

• The agentic CLI tools themselves are still the right tools for individual developer productivity. The risk is in the project-trust seam, not the CLI.
• The vendor response is the vendor response. The buyer-side controls are buyer-side controls. Treating the second as dependent on the first is what the regulator is going to push back on.

§4What we did with this

Workloft uses Claude Code daily on five active repos. The first thing to do was audit our actual exposure rather than write a Note that didn't reflect a real check. The audit, on 9 May 2026:

$ find ~/{civiclaw,conexus,workloft-site} -name '.mcp.json' -o -name '.claude/settings.json'
(no project settings.json in any active repo)
(.mcp.json files only inside an inactive vendored-plugins backup dir)
$ jq '.permissions, .enabledMcpjsonServers, .enableAllProjectMcpServers' ~/.claude/settings.json
{ "allow": ["mcp__plugin_telegram**", "Write", "Bash", "Read"] }
null
null

Reading: we are not currently exposed via our own repos. There is no project-level configuration that auto-trusts an MCP server. The only live risk surface is a third-party repo cloned to the dev machine and a developer (me) accepting the trust dialog. That's a behavioural mitigation, not a structural one — fine for a one-person shop, not fine at scale.

For Workloft's own posture going forward:

• No .mcp.json or project-level .claude/settings.json in our public repos. Anything dev-environment-shaped goes in user-level config, not committed.
• Third-party repos are cloned into a containerised dev environment (a fresh user account on the VPS), not the primary one — so the worst case of a TrustFall-style payload is the loss of a scratch account, not the loss of the production credentials.
• civiclaw's documentation gets a section on this for any council that adopts the runtime — the question is going to come up in the procurement security review and we want a clean answer ready.

For our regulated-buyer customers, the recommendation we'll be giving is the same we apply to ourselves: treat project-trust as code-review, not as a UX prompt. Reviewing one JSON file before running the agent is a 30-second cost; the alternative is a single Enter keypress between you and a credential exfiltration. The maths is not subtle.

§5The honest caveat

Adversa.AI's disclosure is one disclosure. The mechanism is well-described and reproducible from the published advisory; the framing as a "supply-chain crisis" is appropriate when read alongside the CI/CD case but somewhat dramatic for individual developer use, where every dev tool with shell access has had similar properties for thirty years. The genuine novelty is the defaults — that all four major agentic CLIs converged on default-trust, with the same one-keypress UX, in the same year. That's the part regulators will care about. The part that will eventually ship as a control standard.

We'll re-check the vendor postures in two months. If any of the four moves their default to default-deny — or ships an enterprise mode that does — the procurement question becomes much easier to answer. If none do, the buyer-side controls described in §3 become the defensible position by default.