AI coding agents are now an enterprise attack surface: what TrustFall and SymJack mean for the software supply chain

In the first four weeks of May 2026, the security research on AI coding agents stopped being about hypothetical prompt injection and started being about remote code execution that works. Adversa AI published two findings. The first, TrustFall, showed that opening a malicious repository in Claude Code, Gemini CLI, Cursor, or GitHub Copilot CLI and pressing Enter on the trust prompt was enough to run attacker code with the developer’s own permissions, reaching SSH keys, cloud credentials, and shell history (Help Net Security, 7 May 2026). The second, SymJack, showed a stealthier path to the same outcome and confirmed it against six agents, adding OpenAI Codex CLI and Grok to the list (Adversa AI). On the same 7 May, Microsoft disclosed two prompt-injection-to-RCE bugs in its own Semantic Kernel agent runtime (Microsoft Security, 7 May 2026).

Read separately, these are four vendor bugs. Read together, they are one finding: the assumption every major coding agent shares, that showing an approval prompt is the same as obtaining informed consent, does not hold. When a flaw is common to a whole category, the patch is not the story. The design assumption is.

What the two attacks do

TrustFall is the loud one. A repository carries a malicious configuration, and the moment a developer opens it in one of the affected tools and accepts the trust prompt, code runs. The trust dialog defaults toward yes, and execution happens before the model’s own reasoning can intervene. The attacker gets remote code execution at the developer’s privilege level, and from there reads the credentials sitting on a working developer machine.

SymJack is the quiet one, and the more instructive. A hostile repository plants symbolic links disguised as ordinary media files, pointing at the agent’s own configuration files. A project instruction file, the kind these agents read automatically, hides an instruction to copy those files. When the agent asks permission, it shows the literal command, something like copy a media file to a documents folder, not the real resolved destination the symlink points to. The developer approves what looks harmless. The operating system follows the symlink and overwrites the agent’s configuration, planting a malicious component that launches on the next restart and runs with full user privileges (Adversa AI). The secrets at risk are the ones a build identity holds: SSH keys, cloud tokens, browser sessions, deploy keys, signing material, registry tokens. In continuous integration, all of them can be exfiltrated before a human reviews anything.

Microsoft’s Semantic Kernel disclosures are the same mechanism inside a server-side runtime: a prompt-injection path that reaches code execution, tracked as CVE-2026-26030 and CVE-2026-25592 and fixed in named package versions (Microsoft Security). Three vendors, one shape.

Why the patch is not the point

Vendors have responded unevenly, and the unevenness is the governance signal. SymJack documents partial patches at specific versions, including Claude Code 2.1.128 with a partial fix in 2.1.129, alongside named affected versions of the other five agents. On TrustFall, the position is openly contested: Help Net Security reported that Anthropic declined the report on the grounds that its consent dialog is sufficient authorisation (Help Net Security).

That disagreement is not a detail to wait out. The researchers say the approval prompt does not constitute consent, because it can be made to misrepresent what is being approved. At least one vendor says it does. An enterprise security function cannot adjudicate that, and it does not need to. It needs to stop treating the prompt as the control, because both the attack and the vendor’s defence of the attack rest on the prompt carrying more weight than it can.

The category error in most governance programmes

The deeper problem is where the coding agent sits in the org chart of controls. In most enterprises it sits under developer productivity, alongside the IDE and the linter, outside the asset inventory and outside the endpoint-control regime. That placement made sense when the tool was an autocomplete. It does not survive the recognition that the tool executes instructions, supplied by whoever wrote the repository, with the developer’s full credentials and write access to the code that becomes production.

By the working definition the rest of the security programme already uses, that is a production attack surface. The same conclusion arrives from the standards side: the agentic risks catalogued in the OWASP agentic top-10 walkthrough and the controls in the NIST AI RMF agentic mapping both describe an entity that acts with delegated authority and therefore needs the governance an acting entity gets, not the governance a passive tool gets.

What goes on the coding agent

Five controls handle the shift, and none of them depend on the approval prompt being trustworthy.

The first is an inventory. Enumerate which coding agents are in use across the engineering organisation and at which versions. The shadow-AI reality is that adoption ran ahead of approval, so the inventory is also a discovery exercise, not a lookup.

The second is deliberate version management. Pin versions and patch on a tracked schedule against the named affected and fixed releases, rather than leaving each developer to self-update or not. The partial-patch reality means the version matters and a blanket latest is not a control.

The third is credential separation. A compromised agent should reach short-lived, narrowly scoped tokens, not the long-lived SSH and cloud keys that sit on a developer laptop by default. This is the single change that most reduces the blast radius of every attack in this class.

The fourth is behavioural monitoring for the specific signature these attacks leave: a write to an agent configuration file such as the MCP configuration, the agent settings file, or the project instruction file, followed by interpreter execution. Adversa lists this as a detectable pattern, and it is cheap to alert on.

The fifth is a rule about untrusted code: do not open repositories you do not trust in an agent running on a machine that holds production credentials. Use an isolated environment for that, or rotate the credentials on any host that ran an agent against untrusted code, which Adversa recommends directly.

The reading to leave with the CISO

This is not a reason to ban AI coding agents, and a ban would only push the usage back into the dark where the shadow-AI problem already lives. It is a reason to move the coding agent from the productivity column to the endpoint column in the control model. The agents have the reach of production infrastructure. For most of the past year they have been governed as if they had the reach of a text editor. May 2026 is the month that gap stopped being theoretical, and the cheapest time to close it is before the first incident report rather than after.

Related reading

For the standards-side view of agentic risk, see the OWASP agentic top-10 walkthrough and the NIST AI RMF agentic mapping. For the governance baseline these controls extend, see the enterprise agentic AI governance playbook.

The operators-section version, written for solo developers and small agencies who run these agents without a security team behind them, is at the AI coding CLI security check.