A developer asks the agent to add an MCP server. In the walkthrough devops.com gives, the agent searches GitHub, reads several candidate repositories, picks one that looks relevant, follows the install steps in its README, edits configuration, and runs what is needed to bring the server up, and the developer approves the final command without having seen the steps that produced it [9].
That approval is the control most teams have written down, and it covers only one command line. In the June 2026 proof of concept from Mozilla's Zero Day Investigative Network, as described by devops.com, the shell sits at the end of a sequence: instructions for initializing a fictional Python tool, an expected first-run error, the troubleshooting steps the agent then follows, encoded instructions retrieved from a DNS TXT record, and a shell [3]. Count the stages and the execution lands four hops past the moment repository content first entered the agent's context [12]. The payload was never sitting in the repo in an obvious form, which is why devops.com treats command approval as weak on its own [4].
The selection step is the part that moved. Which repository to install from is now decided mid-task, on relevance, inside the agent's loop [9], and repositories have already been built specifically to attract coding agents [7]. That makes search results a dependency decision nobody signed off on.
It also spreads past the README. Counting the content types devops.com names, six kinds of ordinary project text can steer an agent: README, AGENTS.md, contribution guides, issue descriptions, code comments, and tool-specific configuration files [5][11]. GitHub's prompt-injection research in VS Code found that untrusted content brought into an assisted workflow can influence an agent and lead to exposed files, tokens, or command execution [6]. All six are text written to be read by a person, being read by something with a terminal [2][8].
The useful cut here runs on two axes rather than a maturity ladder. First axis: who picked the source, you or the agent. Second axis: what the agent can reach, a read-only workspace or the terminal, filesystem, and network [8]. Pinned source plus no execute is a research assistant. Pinned source plus execute is ordinary build automation, and it is auditable because the source list is a file someone maintains. Agent-picked source plus read-only is survivable. Agent-picked source plus terminal, filesystem, and network is the Mozilla scenario [3], and the honest recommendation is to run that cell in a container you would throw away, or not at all. The tradeoff is immediate and lands on the same developer: pinning sources removes the single-prompt setup that made the agent worth reaching for, and somebody now owns the allowlist and the requests to add to it.
Which means the metric worth tracking is how often developers go outside the pinned list to finish a task, and how long the pinned path takes to a working tool, not the count of approval prompts clicked. A slow pinned path gets bypassed quietly, and the cell you designed for stops being the cell you are in. That is readable today from the agent's permissions and the allowlist's change history, without waiting for an incident to tell you.
