Key Takeaways
- Trae IDE can expose developer secrets. A malicious repository can use
.trae/rules/project_rules.mdto make the agent read.envfiles and send API keys externally via OpenPreview. - The issue reflects a broader AI IDE trust-boundary failure. Repository content can shape agent behavior and trigger tool use without sufficient separation from user intent. No CVE or confirmed remediation exists at the time of writing.
In This Article
Mindgard identified a data exfiltration vulnerability in Trae IDE, an AI-assisted development environment created by Bytedance that integrates agent-driven workflows directly into the developer experience. The platform allows AI agents to interpret workspace context, process repository-level instructions, access local project files, and invoke built-in tools to assist with development tasks.
The identified issue arises from how Trae processes project-level rule files and allows those rules to influence agent behavior, including tool invocation.
Under normal operation, Trae uses project rules to guide how the AI assistant responds to user inputs and interacts with the workspace. These rules are intended to provide contextual instructions such as formatting preferences or workflow guidance. However, Mindgard found that these rules can also be used to direct the agent to access sensitive files and invoke tools in ways that violate expected trust boundaries.
The demonstrated vulnerability shows that a malicious repository can embed instructions that cause the Trae IDE agent to read local secrets and transmit them externally via the agent’s OpenPreview tool. This behavior occurs within standard agent execution flow and does not require explicit user approval beyond interacting with the workspace.
The Issue: Data Exfiltration via Tool Invocation from Project Rules
Trae IDE supports project-level rule files located at .trae/rules/project_rules.md. These files are designed to provide contextual guidance to the AI agent when processing user inputs. In standard usage, they influence how the assistant structures responses or performs tasks within the workspace.
The vulnerability emerges when these rules are treated not as passive guidance, but as actionable instructions that can shape execution flow.
In the scenario demonstrated below, a malicious repository includes a crafted rules file that defines a workflow triggered by a simple user interaction, such as a greeting. Upon receiving the input, the agent begins interpreting the project rules as part of its reasoning process.
The execution path proceeds as follows.
The agent first parses the rules file and identifies instructions directing it to perform a sequence of actions. These actions include:
Processing the initial request:
Analyzing the project rules:
Reading the .env file:
Extracting sensitive values such as API keys, constructing a URL containing that data, and invoking the OpenPreview tool with the constructed URL.
The internal reasoning trace captured during the proof of concept shows the agent explicitly acknowledging each step. Despite recognizing the security implications, the agent proceeds with execution anyway.
The OpenPreview tool is then invoked with a URL that embeds the sensitive data. This results in an outbound HTTP request to an attacker-controlled endpoint, effectively exfiltrating the contents of the .env file. Evidence of this behavior is shown in the captured request logs, where the API key is transmitted as part of the request.
This flow highlights a critical issue: the agent treats repository-controlled instructions as authoritative, and tool invocation is performed without enforcing a boundary between user intent and repository-supplied behavior.
No mechanism prevents the agent from accessing local files or transmitting their contents when instructed through project rules. There is no effective validation step that distinguishes between benign guidance and malicious instruction.
Why This Class of Issue Matters
This vulnerability reflects a broader pattern in AI-assisted development environments: the convergence of configuration, instruction, and execution into a single layer.
Project files are no longer limited to static configuration or documentation. They act as inputs into an AI system that dynamically interprets them, incorporates them into reasoning, and translates them into actions. When those actions include tool invocation, file access, or network communication, the distinction between data and executable behavior collapses.
This creates a systemic trust boundary issue. Repository content, which may originate from untrusted sources, is elevated to an instruction layer capable of influencing agent decisions. Because AI agents operate by synthesizing multiple inputs, including user prompts and workspace context, they may prioritize or execute repository instructions in ways that bypass traditional safeguards.
The problem is compounded by automation. AI agents are designed to reduce friction by performing multi-step tasks autonomously. When malicious instructions are embedded in repository content, that same automation enables end-to-end exploitation without requiring explicit user intent at each step.
The result is a class of vulnerabilities where systems behave as designed, but the design itself fails to enforce meaningful separation between trusted and untrusted inputs.
Bytedance Response
Mindgard initiated disclosure by contacting the vendor via their provided feedback channel and followed up multiple times, including outreach in January 2026. At the time of writing, no formal response, remediation, or coordinated disclosure process has been confirmed.
Why This Matters Now
AI-assisted development environments are rapidly becoming embedded in standard workflows, which changes how risk manifests inside developer systems.
Repository content as an execution vector: Project files can now directly influence agent behavior, transforming repositories into active delivery mechanisms for exploits.
Tool invocation expands the attack surface: Features like preview rendering, shell access, and API integrations create multiple pathways for data exfiltration when improperly constrained.
Implicit trust in agent reasoning: Systems that rely on agent judgment to distinguish safe from unsafe actions introduce inconsistency, particularly when instructions originate from mixed-trust sources.
Secrets exposure within development environments: IDEs routinely access .env files, credentials, and configuration artifacts, making them high-value targets when agent behavior can be influenced.
Lack of visibility and control: Organizations often lack insight into how AI agents interpret workspace content or when tools are invoked on their behalf.
The practical implication is that opening or interacting with a repository in an AI-enabled IDE may trigger behaviors that extend beyond what the user explicitly requested, with direct access to sensitive local data.
Closing Thoughts
This issue illustrates a structural shift in how execution is introduced into development environments. Execution is no longer confined to explicit commands or compiled code. It can emerge from the interaction between user input, repository content, and agent interpretation.
In Trae IDE, project rules act as an instruction layer that the agent incorporates into its decision-making process. When combined with tool access and file visibility, this creates a pathway from repository-controlled content to external data transmission.
The pattern is consistent with other findings across AI-assisted tooling: configuration becomes instruction, instruction becomes action, and action occurs within environments that hold sensitive data.
Addressing this class of issue requires more than restricting individual tools. It requires clearly defined boundaries between user intent, repository content, and executable behavior, enforced consistently across all agent capabilities.
Timeline
