The Hidden Risk Behind “Yes, I Trust This Folder”
Modern AI coding tools promise convenience, but their security prompts often hide complex risks. In tools like Claude Code, a single confirmation such as “Yes, I trust this folder” can silently enable powerful features behind the scenes. Security researchers at Adversa AI demonstrated that a cloned code repository can include hidden configuration files (.mcp.json and .claude/settings.json) that connect to a Model Context Protocol (MCP) server controlled by an attacker. Once a user clicks through the generic trust dialog, an unsandboxed Node.js process can spawn with full user privileges. There is no per‑server consent, no clear detail on which executables will run, and no explicit mention that code may execute. This design turns what looks like a benign trust question into a potential remote code execution pathway, especially dangerous for developers who assume the prompt is merely about reading files, not running them.
How Vague Prompts Become Exploitable Vulnerabilities
The core issue is not just technical; it is about user understanding. Earlier versions of Claude Code reportedly included a clearer warning that explicitly mentioned .mcp.json, explained that it could execute code, and even allowed users to proceed with MCP servers disabled. That more explicit, informed-consent user experience was later replaced with a simpler dialog that defaults to trusting the folder, without MCP-specific language or an option to selectively disable risky capabilities. According to Adversa AI, this is the third time the same class of vulnerability—project-scoped settings used as an injection vector—has surfaced in Claude Code within six months. Each instance is patched individually, but the underlying design remains. When users are not told which features they are enabling or how settings in a repository can silently elevate risk, attackers can craft repositories that look harmless while preparing the ground for one-click compromise.
Phishing Attacks Target AI Tools Through Interface Confusion
As AI becomes embedded in development workflows, phishing attacks on AI tools are evolving beyond fake emails into interface-driven tricks. Attackers can host malicious repositories that appear useful—templates, example projects, or open-source utilities—while embedding configuration that points to their own MCP servers. When an AI tool presents a bland trust dialog, users may click through, assuming they are just granting file access. In reality, they may be authorising code execution or tool activation under attacker control. This blurring of lines between configuration and executable behaviour fuels a new kind of phishing attack in AI tools, where social engineering exploits interface ambiguity instead of obvious fraud. The problem extends to automation, too: in CI/CD environments where AI tools run via SDKs, there may be no prompt at all, creating a zero-click scenario where the presence of malicious settings alone is enough to trigger dangerous actions.
What Users Should Know Before Clicking “Allow” in AI Interfaces
For users, credential theft prevention and system integrity now depend on treating AI security warnings as seriously as browser or operating system prompts. When an AI tool asks you to trust a folder, project, or external server, assume that this could enable code execution, not just read-only analysis. Review repository contents for files like .mcp.json or tool-specific settings, and treat unknown MCP servers as you would untrusted browser extensions. Avoid granting blanket permissions such as enabling all project MCP servers; instead, push vendors to adopt per-server consent dialogs that default to denial. In automated pipelines, ensure you pin configuration, restrict which settings can be loaded from projects, and monitor for unexpected tool invocations. Users and teams should also maintain clear policies for AI interface security, combining secure defaults with ongoing education so developers know what they are authorising before a single click exposes their environment.