Your AI coding agent's "trust this folder" prompt is a security boundary that lies

2026-06-02 · ~8 min read · Conor Dobbs

We have spent a year teaching AI coding agents to ask before they do anything dangerous. The "trust this workspace?" prompt, the "allow this command?" confirmation, the little Yes or No gate before a tool runs. It feels like a seatbelt. The uncomfortable thing security researchers established this spring is that for a whole class of attacks, the seatbelt is painted on.

Two pieces of research from Adversa AI, named TrustFall and SymJack, showed that the approval prompts in Claude Code, Cursor, Gemini CLI, GitHub Copilot CLI and several others can be made to say one thing while the agent does another. Open the wrong repository, press Enter once on a prompt you have pressed Enter on a hundred times, and an attacker is running code on your machine. Microsoft's security team wrote up the same family of problem under the blunt title "when prompts become shells." This is worth understanding even if you never get hit, because the lesson generalizes well past coding agents.

What TrustFall actually does

TrustFall, disclosed by Adversa AI and corroborated by Help Net Security, targets the moment you open a project. Claude Code, Gemini CLI, Cursor CLI and GitHub Copilot CLI all execute project-defined MCP servers as soon as you accept the folder trust prompt. The catch is that a cloned repository can ship its own MCP configuration pointing at an attacker-controlled executable, and all four tools default that trust prompt to Yes. So the entire attack is: clone a repo, open it, press Enter. One keypress.

Help Net Security's headline was not hyperbole. The "do you trust the authors of this folder?" gesture, which most of us answer reflexively because we just cloned the thing on purpose, is the same gesture that authorizes arbitrary local code execution. The agent is not doing anything it was not designed to do. It was designed to run the project's configured tools, and the project gets to define its tools. The trust prompt was the only thing standing between "helpful automation" and "runs whatever the repo author wrote," and it turns out to be a single default-Yes keypress.

What SymJack adds

SymJack is the nastier cousin, because it attacks the honesty of the prompt itself. Adversa titled the writeup "the approval prompt is lying to you," and the mechanism is a symlink hijack. The agent shows you a file operation it is about to perform. You read it, it looks benign, you approve it. But between what the prompt displays and what the kernel actually writes, a symlink redirects the operation somewhere else, typically the agent's own configuration file. The agent overwrites its own config with attacker content, and on the next restart it loads and runs that content.

Adversa confirmed the technique against Claude Code, Gemini CLI, Antigravity CLI, Cursor Agent CLI, GitHub Copilot CLI, Grok Build and OpenAI Codex CLI. That is not one vendor's bug. It is a shared assumption that turned out to be wrong: that the string in the approval dialog is the thing that will happen. SymJack is a textbook time-of-check-to-time-of-use problem, the same class that has bitten setuid binaries and installers for decades, now wearing a friendly AI confirmation dialog.

Why this keeps happening

It is tempting to read this as carelessness, and it is not. The agents are racing to feel frictionless, and every extra confirmation is a place users abandon the tool. The whole product promise is that the thing just does the work, so the trust prompts got tuned toward "yes, get out of my way." That is a reasonable product instinct and a dangerous security default at the same time, which is exactly the tension that produces bugs like these.

There is also a supply-chain shape to it that should worry you more than the individual exploits. SecurityWeek framed these as fuel for the next supply chain crisis, and the framing is right. A coding agent that auto-runs project configuration is a near-perfect delivery vehicle: developers clone untrusted repositories all day, from issue reproductions to dependency forks to that one Stack Overflow answer with a linked gist. Every one of those is now a potential payload, and the victim is a machine with SSH keys, cloud credentials and push access to production.

The mental model: a prompt is not a sandbox

Here is the takeaway I keep coming back to. A confirmation dialog tells you what a program intends to do. It does not constrain what the program is able to do. Those are completely different guarantees, and we routinely confuse them because the dialog sits right where a real boundary would.

A real security boundary is enforced by something that cannot be argued with: the operating system's permission model, a container, a separate user account, a VM. Those say no even when the program, or the repo author, or a clever symlink, very much wants a yes. An approval prompt is a UI affordance layered on top of full access. When the access underneath is unrestricted, the prompt is the only control, and a control that defaults to Yes and can be lied to is not much of a control. Microsoft's writeup lands in the same place: once an agent can be steered into executing, the prompt was never the shell's gatekeeper, it was its on-ramp.

What I actually do about it now

None of this means abandon the tools. I use a coding agent every day and I am not going back. It means treating the agent as what it is, a program with my full local privileges, and putting a real boundary underneath it instead of trusting the dialog. The checklist I run now:

Read "trust this folder" as "run this folder's code." Because that is what it means. If you would not run a stranger's install script with your credentials loaded, do not blind-accept the trust prompt on their repo.
Open unfamiliar repositories in a throwaway container or VM. A devcontainer, a fresh cloud sandbox, anything that is not your primary machine with its keys and tokens. This single habit defuses both TrustFall and SymJack, because the attacker lands in a box you can delete.
Inspect the agent config before the first open. Look at .mcp.json, the editor workspace settings, any project-level agent configuration, before you let the tool initialize. A pointer to a weird local binary is the tell.
Update the agents, then assume the patch is partial. The vendors have been shipping fixes since the disclosures, so update. But these are architectural problems wearing CVE clothing, and the underlying tension between frictionless and safe has not gone away.
Watch the restart. SymJack pays off on the next launch, not the moment you approve. If an agent behaves oddly right after you opened a sketchy project, do not just restart it and move on. Restarting is the exploit.
Do not run your agent as a privileged user. No root, no admin, least privilege for the credentials in the environment. If the prompt fails you, the blast radius is whatever that process could reach.

The unglamorous takeaway

The AI coding agent is the most powerful thing on most developers' machines right now, and we have been securing it with a dialog box. TrustFall and SymJack are useful precisely because they are not exotic. They are old vulnerability classes, default-permit and time-of-check-to-time-of-use, that snuck back in through a shiny new interface where everyone forgot to look.

So look. Assume the approval prompt describes an intention, not a limit, and put something underneath your agent that can actually say no. The developers who come through this fine will not be the ones who stopped using agents. They will be the ones who stopped mistaking a confirmation dialog for a security boundary.