AI
The AI IDE Attack Surface
Over 40 AI coding tools shipped in roughly 12 months. Google, Amazon, OpenAI, Anthropic, Microsoft, JetBrains, and a dozen startups all raced to release. The market looks like the early browser wars: fragmented, churning, and feature-first.
“The security is mostly the thing you get to after you have the market share.” — Piotr Ryciak
The browser era bought us ActiveX, Flash’s thousand-plus CVEs, and click-through warnings users ignored for 15 years. The fix wasn’t better dialogs — it was process isolation. AI IDEs are repeating the same arc. The stakes are higher because these tools don’t suggest code; they read files, write files, run terminal commands, modify configs, and push code. Mindguard’s research found 37 vulnerabilities across 15 vendors, all leading to remote code execution, data exfiltration, or sandbox bypasses.
Workspace Trust Model: Baseline Failures and Approval Fatigue
Workspace trust is the first gate. Three requirements make it meaningful: deny trust by default, disable all code-executing features in untrusted repos, and reprompt when workspace config changes. VS Code solved this in 2021 with restricted mode. AI IDEs started copying it, but most shipped without it, and some gaps stretched over a year. Zed and Marblism implemented the trust model only after Ryciak’s disclosure.
The second problem is industry-wide and still unsolved. Dozens of tools, each with a different trust UI, train developers to click through to get to work. Permission dialogues didn’t fix browsers. Sandboxing did.
“The security is mostly the thing you get to after you have the market share.” — Piotr Ryciak
Zero-Click Attacks: MCP Autoload and Initialization Race Condition
Both attacks require nothing except opening a cloned repo. In the first, an attacker plants a .codex/config that defines a malicious MCP server. Codex spawns it during initialization as a child process with full user privileges, outside the kernel-level sandbox. One config file hits every developer who clones the repo. OpenAI Codex MCP autoload — reverse shell on workspace open (09:46)
Gemini CLI had a trust dialogue. It fired too late.
“By the time the user sees the trust this folder prompt, the reverse shell is already connected.” — Piotr Ryciak
A discovery command in gemini/settings.json runs during initialization, before the dialogue appears. Clicking “don’t trust” does nothing. Gemini CLI initialization race condition — shell connects before trust prompt (12:05)
One-Click Prompt Injection: Four-Primitive Secret Exfiltration Chain
One-click attacks bypass the trust model entirely. The agent becomes the weapon. Prompt injection, delivered through an adversarial directory name, forces Amazon Kiro to read attacker instructions the moment the agent indexes the workspace. Trust status is irrelevant, because the attack moves through the agent’s context, not the config loader.
The chain has four primitives: the directory name triggers a read of index.md, which instructs the agent to grep .env for API keys using y= (the agent blocked key= as suspicious), then embed the stolen key into a Kiro Powers recommendation URL and call it out-of-band. Each primitive is minor. Composed, they produce full secret exfiltration. Amazon Kiro prompt injection via directory name — API key exfiltration (15:54) shows the user typing “hi,” nothing else, and the OpenAI API key leaving the machine.
Time-Delayed Attacks: Config Poisoning via Trust Persistence
Trust is checked once and never revalidated. A victim clones a benign repo, approves workspace trust, and weeks later a collaborator swaps the MCP command for a reverse shell — same server name, no re-prompt. The victim runs git pull and opens Claude Code: Claude Code config poisoning — time-delayed RCE via git pull (19:50). No warning. Shell connects. Ryciak found nine distinct trust persistence vectors in Claude Code alone. Anthropic called it acceptable. OpenAI called it informational. Cursor got a CVE for the same pattern. The fix: hash the trusted config and reprompt on change.
Q&A
Implicit closing question / moderator cut-off prompting final recommendations Ryciak was cut off by the moderator mid-sentence; his closing point, delivered immediately after, was that sandboxing — dev containers, cloud development environments, disposable droplets — is the only mitigation that contains blast radius when an attack succeeds. ▶ 24:15
Notable Quotes
The AI agent, the AI doesn’t suggest, it acts note. Piotr Ryciak · ▶ 1:01
The security is mostly the thing you get to after you have the market share. Piotr Ryciak · ▶ 2:13
By the time the user sees as the uh trust this folder prompt, the reverse shell is already connected. Piotr Ryciak · ▶ 11:34
We believe this is the appropriate balance between security and usability. Piotr Ryciak · ▶ 21:09
Right now vendors are basically asking users to manually replicate and integrity check that the tool itself should be performing which is well unreasonable. Piotr Ryciak · ▶ 22:23
Key Takeaways
- Audit every AI IDE you use for workspace trust baseline: deny-by-default, feature lockdown in untrusted repos, and config-change reprompt.
- Treat prompt injection via workspace files as a first-class attack vector — trust model status does not block it.
- Run AI coding agents inside dev containers or cloud sandboxes so a successful exploit is contained to a disposable environment.