AI coding agents are becoming part of everyday development work. Developers use them to find libraries, configure projects, troubleshoot installation problems, and set up new tools. An agent can search GitHub, read project documentation, and run commands without the developer having to work through every step manually.
That convenience is creating another security concern for DevOps teams. An agent can encounter software and instructions during a task, decide that they are relevant, and act on them. A repository, README file or configuration file can therefore become part of the execution path.
Recent attacks have shown how this can be abused. Malicious repositories have been created to attract AI coding agents, while researchers have demonstrated attacks that use project instructions to influence what an agent downloads or executes. Once an agent has access to a terminal, the filesystem, or the network, a routine development task can provide malicious code with a way into the environment.
That raises a difficult question: how much trust should an AI coding agent be given when deciding what software to run?
AI Coding Agents Have Changed How Developers Install Software
A developer who wants to add a new tool can now ask an AI coding agent to handle most of the work. The agent can find a repository, read the setup instructions, install the required packages, and configure the project. That works well when the repository is trusted. The risk increases when the agent has to decide which repository to use or which instructions to follow.
Consider a simple request to add an MCP server. The agent may search GitHub, look at several repositories, choose one that appears relevant, and follow the installation instructions in its README. It can then modify configuration and run the commands needed to get the server working.
The developer may approve the final command without seeing everything that happened before it. The agent may have already picked up instructions from a source the developer hasn’t fully evaluated and followed them as part of the task. By the time the developer sees the result, those instructions may already have influenced what the agent downloaded or executed.
The agent is doing exactly what it was asked to do. The problem is that the instructions it found along the way came from somewhere the developer never explicitly trusted. This is where AI-assisted development starts to create a different kind of software supply-chain problem. The attack can begin before the code reaches the repository, the build server or the production pipeline.
A README Can Now Be Part of the Attack Surface
README files have always been a normal part of setting up a project. They tell developers how to install dependencies, configure the environment, and get the code running.
A June 2026 proof of concept from Mozilla’s Zero Day Investigative Network showed how a repository could manipulate a coding agent into opening a reverse shell. The repository contained instructions for initializing a fictional Python tool. After an expected first-run error, the agent followed the suggested troubleshooting steps, eventually retrieving encoded instructions from a DNS TXT record and passing them to a shell. The demonstration shows how indirect prompt injection attacks can turn otherwise ordinary project content into instructions for an AI coding agent.
The malicious payload wasn’t sitting in the repository in an obvious form. It appeared later in the execution process, after the agent had already started following the project’s instructions. That makes a command approval less useful on its own. A developer may see a familiar setup command without knowing everything that command will eventually execute.
README files aren’t the only place where agents can pick up instructions. AGENTS.md, contribution guides, issue descriptions, code comments, and tool-specific configuration files can also influence an agent’s actions. GitHub’s research into prompt injection in VS Code has shown how untrusted content brought into an AI-assisted development workflow can influence an agent and potentially expose files, tokens, or command execution. Once an agent can read project content and act on what it finds, documentation becomes part of the execution path.
Malicious Repositories Don’t Need to Look Malicious
AI coding agents are increasingly being used to find software and tools for developers. That makes the search process itself an interesting target for attackers.
The FakeGit campaign is a good example. Researchers identified thousands of malicious GitHub repositories posing as legitimate AI tools, skills, and MCP servers. Some used familiar project names, copied repository layouts, and other details that made them look credible. The repositories ultimately delivered malware, but the important part of the attack happened earlier: the attackers first had to make the projects discoverable and convincing enough for an AI system to recommend them.
Some of these repositories were also surfaced by AI coding agents during ordinary software searches. An agent looking for a particular capability could encounter a malicious repository, treat it as a legitimate option, and pass its installation instructions to the developer. Researchers referred to this technique as AgentBaiting.
For developers relying on agents to find software, discoverability has become part of the security problem. A malicious project that reaches an AI agent at the right moment can get much closer to execution than one waiting for a developer to find it manually.
Why Traditional Security Controls Can Miss the Problem
Traditional security tools still have an important role in protecting developer environments, but they don’t always see the full chain of what happens after an agent starts working on a project.
A command can come from a legitimate shell, a trusted development tool can execute it, and the repository itself can pass a basic security check. The problem may only become visible when those actions are considered together. That makes the distinction between antivirus and malware defenses important. Antivirus tools can identify known malicious files, while broader malware protection can also look for suspicious behavior. Those controls remain useful, but they don’t explain how the software reached the machine or why it was executed.
An agent can find a repository, read its instructions, and run a command as part of a task the developer requested. From the operating system’s perspective, the command may still look like ordinary development activity.
The context behind that command can be harder to see. If the initial trigger came from a repository, project file or instruction that the agent treated as trustworthy, a security tool may only see the final action rather than the sequence that led to it.
Traditional endpoint protection can detect malicious files or suspicious behavior, but it may have limited visibility into the instructions and decisions that caused the code to run.
What DevOps Teams Should Change
The first step is to treat the agent’s access as part of the development environment’s security boundary. An agent that can install packages, modify files, and execute shell commands has considerably more reach than one that can only suggest code. That access should match the task. An agent reviewing a pull request doesn’t need the same permissions as one preparing a release or configuring a development environment. Keeping those boundaries separate limits what can happen when an agent follows an instruction it shouldn’t.
The same applies to software discovery. Repositories, packages and MCP servers found by an agent should go through the same trust checks as anything a developer would install manually. Popularity, repository activity or an agent’s recommendation shouldn’t be treated as proof that a project is safe.
Execution also deserves more attention. Running agents inside isolated environments can limit access to credentials, sensitive files and production systems. Network restrictions can provide another layer of protection when an agent needs to download dependencies or communicate with external services.
Teams also need better visibility into what agents actually do. Logs should capture repository sources, commands executed, packages installed and permission changes. That makes it easier to investigate an incident when the final malicious action looks like an ordinary development command. Clear permissions, trusted software sources, and isolated execution environments can limit how far an attacker can move when an agent follows a malicious instruction.
Conclusion
AI coding agents are becoming part of the software development process, and the way they discover and execute software deserves more scrutiny. Attackers are already experimenting with malicious repositories, project instructions, and other content that can influence what an agent does. As these tools gain more access to developer environments, the consequences of a bad decision become larger.
The development workflow is changing, and so is the attack surface around it. An agent can now make decisions about software, follow instructions from project content and execute commands with very little human involvement. That makes the trust placed in these systems an increasingly important part of software security.
