AI agents are increasingly searching for documentation, selecting libraries, and installing dependencies on their own. Attackers no longer need to deceive the developer: sometimes it’s enough to manipulate the information that the developer’s digital assistant reads.
You asked the AI to write some code. Who decides what it will install?
Let’s consider a common scenario. A developer instructs an AI agent to add authentication to a web application. The agent analyzes the project, performs a search, reviews the documentation for several libraries, and selects the appropriate solution.
Then it installs the necessary npm package, updates the dependencies, and continues working.
The task is complete. The developer is satisfied: instead of spending several hours studying the documentation, the whole process took just a few minutes.
But there’s a problem.
What if the documentation found by the agent belonged to a malicious actor? Or what if the official website recommended a package whose name had already been registered by an attacker?
In such a case, the AI agent is capable of independently downloading and executing malicious code, even if the user’s original query was completely harmless.
This threat lies at the intersection of several techniques: SEO poisoning, indirect prompt injection, and software supply chain attacks.
By 2026, researchers had already documented real-world examples of such scenarios.
How Search Results Are Poisoned for AI
Traditional SEO poisoning is a technique in which an attacker manipulates search results to ensure that a compromised website appears in the results for specific search queries.
In the past, the primary targets were people. A user would search for a popular program, click through to a fake website, and download an infected installer.
With the advent of AI assistants, another potential recipient of such results has emerged: the autonomous agent.
A hypothetical sequence looks like this:
- A user instructs an AI agent to solve a problem.
- The agent uses the search engine to find documentation.
- The results include a source controlled by the attacker.
- The source recommends installing a specific library.
- The AI agent installs the suggested package.
- Malicious code is executed during the installation or use of the package.
The attacker does not need to control the language model itself.
It is sufficient to gain influence over the information source that the model uses to make decisions.
For example, this could be an article with instructions on API integration, an SDK documentation page, a public repository’s README, or a search engine result.
The malicious content may look completely ordinary: a description of the library’s capabilities, code examples, setup instructions, and an installation command.
Technical details, references to well-known technologies, and relevance to the developer’s query add to its credibility.
To a human, such a page is simply documentation. To an agent with the privilege to execute commands, it can serve as a basis for initiating the installation.
A high ranking in search results confirms the page’s relevance to the query, but not its safety.
The same problem arises when an AI assistant receives a response from a search API and treats the content of the found page as a reliable guide for action.
Prompt injection: when an instruction is hidden in the data
Another mechanism is indirect prompt injection.
Unlike a typical user query, an attacker embeds an instruction in external content that the agent must read during operation.
Such content could be a web page, a search result, a Markdown file, a README, or a response from a third-party tool.
Suppose an AI is looking for a way to integrate a library for document processing. The page it finds states that an additional component must be installed for the integration to work correctly.
The instruction appears to be a mandatory configuration step, although it actually diverts the agent from its original task.
If the agent interprets external text as a command rather than as information for analysis, a breach of trust occurs.
It’s important to distinguish between two scenarios here.
In the first, an attacker intentionally adds instructions to the material that are tailored to the model. This is indirect prompt injection.
In the second, there is no specific injection: the agent simply trusts an incorrect or outdated instruction and installs a package that turns out to be under the control of a third party.
Both scenarios can lead to the same problem—the execution of untrusted code. But the mechanisms by which they occur differ.
Real-world case: Agents executed code from company documentation
On August 26, 2026, researcher Alon Hertz published the results of a study titled “Data Became Code.”
His team analyzed 6,214 active corporate domains and discovered thousands of files llms.txt and llms-full.txt.
These are machine-readable documents that some websites publish to facilitate AI systems’ access to documentation and descriptions of their products.
Such files may contain links to integration guides, SDKs, and instructions for installing dependencies.
The researchers discovered more than 237 mentions of unregistered software packages, domains, and other resources.
The problem was that the official documentation suggested using names that, in fact, belonged to no one.
The team registered a small portion of the available names and deployed secure test packages under them. Their sole purpose was to send a signal confirming execution.
The first confirmation that the test code had been executed from a Fortune 500 company’s infrastructure came in less than four minutes.
Subsequently, the researchers received additional confirmations from corporate environments.
The experiments involved agent-based tools based on Claude, Codex, and Hermes. They did not need to specify the address of the malicious resource directly: the agent could independently discover the documentation and follow the installation instructions.
Separately, the researchers discovered a vulnerability in the documentation for the Clerk authentication service.
In one scenario, the published command npx could have accessed the public npm registry to retrieve a package that the company had not released as a standalone product. A third party had already taken advantage of this name by uploading a malicious package.
Clerk fixed the issue after being notified. However, publicly available information does not confirm that this specific malicious package led to actual user infections.
It is particularly telling that the experimental attack did not require any changes to corporate websites. It was sufficient to register names that were already present in the official documentation.
How a Malicious Module Enters a Project
Once the agent has selected a package, the next stage begins: installing the dependency.
For JavaScript projects, this is usually npm; for Python, it’s pip. Other ecosystems use their own package managers.
At first glance, installing a library looks like a routine operation. However, a software package is not just a set of functions that the application will call later.
In npm, there are lifecycle scripts, including preinstall and postinstall. These can be run directly during the installation of a dependency.
The npx can also, under certain conditions, download and run the package’s executable file from a public registry.
In Python, the risk of code execution can arise during the stages of building a package from source code and when subsequently importing the installed module.
This means that a malicious component does not necessarily have to wait for the finished application to run.
If the installation takes place in a development or CI/CD environment, the secrets and resources located there become potentially accessible:
- API keys and access tokens for third-party services;
- software package publication tokens;
- cloud credentials;
- SSH keys and configuration files;
- environment variables;
- project source code;
- secrets accessible to the build process.
However, executing a command on behalf of an AI agent does not make it any safer. The agent uses the permissions granted to its process and the connected tools.
PromptMink: When an AI Coding Agent Selects a Malicious Dependency
Another illustrative case was published by ReversingLabs on April 29, 2026.
Researchers discovered that a malicious dependency appeared in a cryptocurrency trading agent project following changes made with the involvement of an AI coding agent.
A library was added to the project’s code @solana-launchpad/sdk, which, in turn, integrated a malicious package @validate-sdk/v2.
The latter masqueraded as a standard data-validation tool but contained functions for collecting sensitive information.
According to ReversingLabs, the attackers deliberately crafted the documentation and package descriptions to be convincing to language models. The goal was for the agent to perceive the library as a suitable solution for its task.
The researchers described this approach as an abuse of LLM Optimization (LLMO) and knowledge injection.
This is a key difference from a typical package name spoofing attack: the attacker attempts to influence not only where the code is loaded from, but also why the AI would choose that particular component in the first place.
The study itself does not prove that the choice of dependency was directly caused by a poisoned search result. However, it confirms a broader mechanism: a malicious library can end up in a legitimate project as a result of an AI agent’s decision.
Read more: ReversingLabs — Claude adds malware to crypto agent.
Slopsquatting: Even Search Results Aren’t Necessary
Sometimes an attacker doesn’t need to tamper with search results at all.
Language models can recommend libraries that do not actually exist. They generate plausible names based on familiar patterns and combinations of existing projects.
This feature is exploited in attacks known as “slopsquatting.”
An attacker identifies the names of nonexistent packages that regularly appear in AI responses and registers them in a public registry.
If an agent later suggests one of these names and attempts to install the corresponding dependency, the package will already exist—but it will be controlled by the attacker.
This differs fundamentally from classic typosquatting.
In typosquatting, the victim makes a mistake when typing the name of a popular library.
With slopsquatting, the name may be spelled perfectly correctly. It was simply invented by the model in the first place.
A study published in May 2026 examined modern code-generation models. The authors found that even newer models continue to suggest nonexistent dependencies, and some of these made-up names recur across different models.
Thus, a public package registry can become a place where a model’s error turns into a mechanism for delivering malicious code.
Why Traditional Defenses Might Fail to Detect an Attack
The main challenge with such scenarios is that individual actions may appear legitimate.
The AI agent uses a permitted search tool, accesses documentation available via HTTPS, and launches a standard package manager.
Next, npm or pip accesses a familiar public repository.
None of these steps, on its own, necessarily looks suspicious.
The problem arises when unverified external content begins to dictate the actions of a system with code-execution privileges.
The presence of HTTPS confirms that the connection to the site is secure, but it does not guarantee the security of all instructions published on it.
And the fact that a package is published on npm or PyPI does not guarantee that it belongs to the expected developer or that it does not contain malicious functionality.
Even a signature or verified origin of a build does not always solve this problem: they help establish the source of the artifact but do not prove its security.
How to Protect AI Agents and Development Infrastructure
It is not necessary to completely abandon automation. It is much more effective to limit the consequences of an agent’s erroneous decisions and establish rules for working with dependencies.
1. Prohibit the uncontrolled installation of new dependencies
An AI agent can select and suggest libraries, but adding a new package to a project must undergo a separate review or approval process.
It is especially important to monitor packages that were not previously in the project and that are not on the list of allowed components.
2. Verify the origin of packages
Before installation, it is important to determine who maintains the project, how long ago the package was published, whether it corresponds to the official repository, and whether it is actually listed in the developer’s documentation.
However, the age of the package and the number of downloads are merely additional indicators, not proof of security.
3. Use controlled registries and dependency analysis
Internal repositories, allowlist policies, Software Composition Analysis (SCA), and analysis of malicious components help reduce the likelihood of unknown packages entering a project.
Verification should cover not only direct dependencies but also transitive dependencies.
4. Isolate the agent’s runtime environment
Third-party code should be installed, whenever possible, in a disposable environment without access to production secrets, working SSH keys, or privileged cloud credentials.
Containerization is useful, but it does not guarantee isolation on its own: you must restrict mounts, permissions, and network access.
5. Separate external information and instructions
Search results, website content, and responses from MCP tools should be treated as untrusted data.
An installation instruction found online should not automatically be treated as permission to execute a command.
Scenarios in which an AI agent can independently search for information, install software components, and execute them without additional oversight are particularly dangerous.
6. Monitor terminal activities
For operations such as installations, running scripts, and modifying the infrastructure, it is advisable to implement permission policies, logging, and confirmation of high-risk actions.
Commands that download executable code from the internet or run previously unknown packages deserve special attention.
7. Review your own AI documentation
If a company publishes llms.txt, AGENTS.mdSDK installation instructions or other materials for agents, these should be included in the scope of integrity monitoring.
It is essential to verify that the specified package names, domains, and commands actually belong to the company or trusted vendors.
What to do if an agent has already installed a suspicious library
Simply removing the dependency does not guarantee that the consequences will be eliminated.
If the installation script has already run, it may have accessed secrets, created additional files, or launched third-party processes.
In this case, we recommend taking the following steps:
- Isolate the affected environment from other corporate systems.
- Save command execution logs and the AI agent’s activity history.
- Record the versions and checksums of the installed packages.
- Check running processes, created files, and network connections.
- Determine which secrets and resources the installation process had access to.
- If there is a risk of compromise, revoke and reissue the relevant tokens and keys.
- Restore the affected environment to a trusted state and eliminate the cause of the suspicious component’s installation.
Credentials accessible to the process during installation should be considered potentially compromised.
For CI/CD and high-trust production environments, it is safer to restore the environment from a verified state than to rely solely on removing the suspicious package.
Conclusion: Search results are no longer just a source of information
In the past, an attacker who poisoned search results expected a user to click the link, download the file, and run it.
Now, in some scenarios, an AI agent is capable of carrying out this sequence.
The attacker manipulates the information the agent uses to solve a task and then relies on the permissions granted to the agent.
In this case, compromise is possible even without a classic prompt injection: all it takes is an erroneous instruction, an unregistered package name, or a convincingly crafted malicious library.
The key issue is not that AI can search for information. The problem arises when the text it finds becomes the basis for executing code without independent verification.
As autonomous assistants become more widespread, supply chain security must cover not only the source code and installed dependencies but also the entire decision-making process: from the search query to the execution of the command.
This is because the next malicious dependency might end up in a project not as a result of a developer’s error, but after its AI assistant has successfully completed a task.