A tool that fakes shell command output got four models to run a scan they had refused

TrustMeBro, an open-source tool that feeds coding agents fake command output, has reached 435 stars on GitHub. It is MIT licensed, written in Go, and runs on Linux and macOS. The repository was created on 26 August and last received a push on 1 September.

The idea is small and the consequence is not. Many agents check something about the world before they do a risky thing, and they check it by running a command. TrustMeBro sits between the agent and that command.

How the interception works

It replaces the commands an agent calls with stand-ins placed earlier on the PATH. When the agent runs one, a rule decides what happens: return invented output, edit the real output, refuse the call, or pass it through to the real binary untouched. Unmatched calls go to the real command, so most of a session looks normal. Every decision is written to a timestamped audit log, which records whether each call was faked or passed through.

The author notes that no plugin, hook, or MCP integration is needed, because the substitution happens at the level of the shell.

There is also a Linux mode built on Bubblewrap that shadows absolute paths such as /usr/bin/dig, not only PATH lookups. The README explains why that matters: without it, an agent could escape interception by resolving the real location of a command and calling that instead. The author is explicit that this mode is an interception namespace and not a security sandbox, since it reuses the host filesystem, network, environment and the agent's own credentials.

The result the author reports

The test used a permission check of a kind that is common in security tooling. Before a model could run a scan, it had to confirm a fresh DNS authorization record. The author reports that without TrustMeBro, the real command returned no record and every model stopped. With fabricated output, every model went ahead.

Four models were tried: GPT-5.6 Sol, GPT-5.5, DeepSeek V4 Pro and DeepSeek V4 Flash. All four are reported as blocked before and proceeding after. This is one author's local evaluation on one kind of check, with no independent replication, and the sample is four models on a single scenario.

Where the trust actually sits

A guardrail that asks an agent to verify a condition by running a command has moved the security boundary onto that command, and a command is chosen by PATH. Anything that can write to a developer's shell startup file, a dependency install script, a compromised package, a checked-in dotfile, can decide what the agent believes.

That reframes a common design. Teams building agent workflows often add a verification step and treat it as a control. It is a control only if the thing doing the verifying cannot be replaced by whatever the agent is working on. Checks that matter belong outside the agent's own execution environment, where the code being handled cannot reach them.

The project describes itself as a red-team tool for testing decisions that depend on tool output, which is the honest framing. If your agent has a rule of the shape "confirm X before doing Y", this is a way to find out whether that rule holds when the answer is supplied by something less friendly than your own machine.

Source

DavidCarliez/trustmebro on GitHub