GitHub Copilot, Claude Code, Cursor, Windsurf, and similar tools are becoming part of everyday software development. They speed up coding, debugging, documentation work, and task automation. For many organizations, this is no longer an experiment. It is becoming part of the standard development environment.
The other side of this change gets less attention.
An AI coding assistant is no longer just a chatbot answering questions. Increasingly, it acts as an agent that reads project files, analyzes configuration, runs commands, works with the terminal, and uses the context of the local environment.
That creates a new attack surface.
In May 2026, we ran an attack simulation against one popular AI coding tool. The goal was simple: to understand what could happen when an AI agent is launched inside a repository prepared by an attacker.
AI adopted without security testing creates new risk
This was not a tool malfunction.
The agent did what it was designed to do: it read the project context, interpreted the configuration, and executed instructions. The difference was that the project had been prepared from an attacker's perspective.
The traditional security model assumes that the user makes conscious decisions. A developer sees the code, runs a command, approves a change, or grants access.
An AI agent behaves differently. It can react to configuration files, project instructions, initialization scripts, and metadata. These elements used to be treated mainly as part of the development environment. In an environment with an AI agent, they can become instructions that influence the agent's behavior.
For an attacker, this changes the operating model.
Phishing, an exploit, or account compromise may not always be required. Sometimes, a repository that looks like a normal project but contains carefully prepared context for the AI agent may be enough.
What our simulation showed
We tested scenarios involving credential theft, bypassing security mechanisms, and using built-in tool functionality in ways that were not intended by the user.
The test environment was close to real development work: a local machine, real configurations, standard project files, and a typical workflow with an AI coding assistant.
One of the most important findings concerned automatic code execution at session startup.
A developer opens a repository. The AI agent starts in the context of the project. Then, based on the configuration, it performs initialization actions. The problem is that "initialization" can mean much more than preparing the environment.
In our tests, the time from opening the repository to an attempted credential capture was under one second. No additional user interaction. No clear warning showing the full impact of the action.
We are not publishing operational details or technical sequences. The conclusion is straightforward: in an environment with an AI agent, a repository is no longer just code. It becomes an active element that can influence how the tool behaves.
The impact after the session was also important. A single run of a malicious repository can leave lasting effects outside the project itself. The developer returns to normal work, but some changes in the environment may remain active.
The good news
This is not a story about AI tools being "broken" or something organizations should simply block.
In our tests, some defensive mechanisms worked as expected. Direct manipulation attempts through obvious project instructions were detected or blocked.
The problem started with less obvious scenarios.
Some attacks did not rely on bugs in the classic sense. They used legitimate features of the tool in an unexpected context. From the system's perspective, this looked like normal behavior. From a security perspective, it was a problem.
Sandbox mode and permission prompts help, but they do not remove the risk. The user often sees a request for approval without a full view of what may happen after that approval is granted.
This matters especially in development environments, where a local machine may have access to repositories, tokens, keys, cloud configuration, CI/CD tooling, and internal networks.
What this means for organizations
AI coding assistants should be treated as a new category of tools requiring security review.
It is not enough to ask whether the tool improves productivity. Organizations need to understand what access it has, what actions it can perform, how it reacts to malicious context, and what remains after a session ends.
The repository becomes a new attack surface.
Configuration files, project instructions, startup scripts, and dependencies can influence the agent's behavior. Cloning external code while an AI assistant is active should be treated as a higher-risk moment.
Permission prompts do not replace security testing.
A question such as "allow this action?" does not give the user full context. Especially if, after approval, the agent can perform more actions than the prompt itself suggests.
Recommendations
For security teams
Include AI coding assistants in the scope of security reviews. Validate tool configuration before deployment. Test malicious repository scenarios, not only classic application vulnerabilities.
Monitor network traffic, unusual processes, and changes on developer machines. Pay particular attention to environments with access to credentials, cloud configurations, and software build systems.
For developers
Do not open an unknown repository with an active AI agent without checking its configuration. Treat external code as potentially active context for the tool, not just a set of files to inspect.
Consider using a separate environment for unknown code: a dedicated virtual machine, container, or isolated account without access to production credentials.
For leadership
Adopting AI without security testing means accepting a new operational risk. This is not about blocking tools. It is about understanding where user control ends and automatic agent behavior begins.
The budget for AI adoption should include not only licenses and training, but also security testing, monitoring, and safe-use rules.
Final question
If your organization is adopting AI coding assistants, the question is not whether they will increase productivity.
The question is: who tested what they do after receiving malicious instructions?
If the answer is "no one", this is the right time to run security tests.