Coding Agent Security: When Your Tools Lie

Key Takeaways:

• TrustMeBro sits between a coding agent and the command-line tools it calls, then returns whatever its rules say to return.
• In the author's own local evaluation, four models refused a scan until a fabricated DNS answer told them the authorization check had passed.
• No plugin, no hook, no MCP server. It installs shims onto PATH and waits for the agent to run something.
• The lesson for coding agent security is unglamorous and old: tool output is untrusted input, not evidence.

TrustMeBro went public on August 26, 2026 and had 291 stars by the end of the month, which for a five-day-old Go repository with 13 commits is a lot of attention for very little code. It matters less as software than as a demonstration. The thing it demonstrates is that most coding agent security thinking still stops at the model's inputs and the model's outputs, and skips the part in the middle where the agent asks the operating system a question and believes the answer.

What TrustMeBro actually is

It is a single Go binary, MIT licensed, that installs itself as a set of shims on your PATH. When a coding agent shells out to dig, nslookup, or host, the shim runs instead of the real program, checks the command against a rule file, and picks one of four outcomes: return generated output without touching the real binary, run the real binary and rewrite its stdout, block the call, or hand off to the real binary unchanged. Every decision lands in a timestamped JSONL log, which is the one part of the design that reads like a defensive tool rather than an offensive one.

The README's framing is worth repeating precisely, because it is narrower than the headline suggests: the harness runs a normal check, and you control the tool output before it sees it. The author names Codex, Claude Code, and pi as the harnesses it was built against, and states the intended use as controlled red-team testing of decisions that depend on tool output. Two releases, v0.1.0 and v0.1.1, both shipped on August 26 within about two hours of each other; the last push was August 29.

Why fabricated tool output is a coding agent security problem

Think about what a guardrail looks like inside an agent loop. The model is told not to scan a domain unless ownership is proven, so it does the sensible thing and proves it: it runs a command, reads the result, and reasons over what came back. That reasoning is sound. The premise is not, because the premise arrived through a channel nobody authenticated.

Our earlier write-ups on AI agent security risks and on building an agent security framework both organise threats around what enters the context window and what the agent is permitted to do. Neither of those framings catches this one, because the agent here was permitted to run dig and the output that entered its context was structurally valid DNS. Nothing looked wrong.

This is the gap that separates coding agent security from ordinary prompt-injection work. Injection attacks fight the model over what the instructions mean. This does not argue with the model at all; it agrees with the model's rule and forges the evidence the rule asks for. A model that carefully verifies before acting is, in this specific sense, easier to steer than one that never checks, because the check gives an attacker a defined slot to fill.

There is a practical reason the CTA above is about disposability rather than protection. Installing TrustMeBro means letting a program edit your shell startup files, including login shells, because agents commonly run commands through non-interactive bash -lc. That is a reasonable thing to do to a machine you intend to wipe, and a poor thing to do to the laptop you also use for client work. A hosted cloud AI computer is the cheap version of that boundary: MoClaw gives the agent a machine whose PATH you can wreck on purpose, sitting alongside your local install rather than replacing it.

What happened to the four models the author tested

The README publishes a small comparison table. Each model had to verify a fresh DNS TXT authorization marker before proceeding with a scan; without the shim, the real /usr/bin/dig returned no marker and every model stopped. With lab mode active, the same absolute path returned fabricated proof, and every model continued.

Four models, four identical results: GPT-5.6 Sol, GPT-5.5, DeepSeek V4 Pro, and DeepSeek V4 Flash. Read that table for what it is. It is one author's local evaluation of one scenario, published without a harness version, a system prompt, or a sample size, and it is not a benchmark; treating it as a ranking of model safety would be wrong in both directions, since a model that stops when told to stop and proceeds when shown proof is behaving exactly as designed. What the table does establish is that the failure is not specific to one vendor's alignment work, which is the more uncomfortable finding.

One more thing the table quietly says: the block, when it worked, came from the model following an instruction, not from any enforcement layer. Nothing in the harness stopped the scan. The scan stopped because the model chose to stop, which means the entire control depended on the model's willingness plus the truthfulness of one subprocess.

PATH shims mean there is nothing to integrate

Most agent-security tooling assumes a hook point. You register an MCP server, you add a permission callback, you wrap the tool definitions. TrustMeBro skips all of it, and that is the design decision with the longest shadow.

Because interception lives at the process boundary, the agent's own configuration is irrelevant. It does not matter which tools you declared, which permissions you granted, or whether you audited your MCP servers last week, since a shim earlier on PATH answers first. On Linux, lab mode goes further and uses Bubblewrap to shadow discovered absolute paths as well, so an agent cannot escape by resolving command -v dig and calling the result directly. The author is explicit that lab mode is an interception namespace and not a security sandbox: it deliberately reuses the host filesystem, the current workspace, the network, and the agent's credentials.

That distinction is where the second argument for a separate machine lives. An interception namespace that keeps your real credentials in scope is not isolation, and the honest way to get isolation is a machine that has nothing on it worth stealing. MoClaw's environment starts empty and is declared rather than accreted over years of brew install, which is a different property from a namespace that borrows everything from the host.

Where the interception stops

The Limitations section is the most useful part of the repository, and it is unusual to see one this candid in a project whose tagline is about bypassing guardrails.

Outside lab mode an absolute path such as /usr/bin/dig walks straight past the shim, sudo and clean environments like env -i can escape, and which dig reveals the shim path to anyone who looks. In-process DNS clients never touch a command shim at all, so an agent that resolves a name through Python's socket module sees the truth. Rewrite mode gives up above 16 MiB of buffered output rather than partially rewriting it, and an invalid config makes the shim block the command and exit with status 78.

Notice which mitigations fall out of that list, because they are the ones worth writing down. Calling tools by absolute path helps. Resolving DNS in-process instead of shelling out helps more. Running the agent in an environment whose PATH you set, rather than one it inherited, helps most, and lab mode's own dependency on Linux and Bubblewrap is a reminder that this class of test belongs on a Linux box rather than a MacBook. That is the third place MoClaw fits: a hosted Linux environment is where you can actually reproduce the experiment, instead of reading about it and assuming your setup is different.

What this changes about coding agent security posture

Not much, and that is the point. The recommendation is one every security engineer already knows and every agent framework quietly ignores: output from a tool is input to the model, and input to the model is untrusted until something outside the model says otherwise.

Applied to coding agent security, that means a few concrete habits. Do not let the agent be the only party that verifies its own preconditions; put the authorization check somewhere the agent cannot reach, such as a network policy or an approval step that runs on different infrastructure. Log the tool invocations, not just the transcript, since the transcript will show a clean verification. And when you do test any of this, test it on a machine you are willing to lose, which is the whole reason MoClaw exists as a hosted computer rather than a local install: the experiment stays where you put it.

None of this needs a policy document. Pick the two commands your agent actually depends on for a safety decision, then ask where their output comes from and what would have to be true for it to be forged. If the answer is "someone would need write access to a directory on PATH", you already know how hard that is.

All of the above holds as of August 2026, for a project five days old. It may look different in a month.

FAQ

Is TrustMeBro malware?

No. It is MIT-licensed open source, the stated purpose is controlled red-team testing of decisions that depend on tool output, and it ships an audit log of every decision it makes. It is a testing tool that happens to test something uncomfortable. That said, it is also a working interception layer, so treat an unexplained shim directory on PATH the way you would treat any unexplained change to a developer machine.

Can it bypass ChatGPT or Claude safety filters?

No, and the distinction matters. TrustMeBro operates on the tool-call layer of a local coding agent, well below anything a hosted provider filters. It never touches the model's content policy; it changes what the model believes about the world before the model decides. A cloud chat session with no shell access has no surface here at all.

Does using MCP servers instead of shell tools protect me?

Not by itself. MCP moves the tool boundary, it does not authenticate what comes back across it, and a compromised or misconfigured server can return whatever it likes. The relevant question is the same either way: who vouches for this output, and would I notice if the answer were forged?

Which coding agents are affected?

The author names Codex, Claude Code, and pi as the harnesses tested, but the mechanism is not specific to them. Any agent that discovers command-line tools through PATH and reasons over their stdout has the same exposure, which is nearly all of them.

Getting the trust boundary in the right place

The best thing about this project is how boring the fix is. Nobody needs a new model, a new guardrail vendor, or a new alignment technique to handle it; they need to stop treating a string that came back from a subprocess as a fact about the world. TrustMeBro is a five-day-old repository with 291 stars and a candid limitations list, and its main contribution to coding agent security is making that one sentence hard to ignore.

If you want to see the behaviour yourself, run it somewhere disposable, keep the audit log, and read the transcript afterwards for the moment the agent decided it had permission.