Your AI Agent Can Install a Backdoor

The supply-chain problem in AI is easy to miss because the output looks ordinary. An agent writes a small script, adds an import, resolves a dependency, and continues its task. From a distance, it looks like helpful automation. Up close, that workflow may be the first time unreviewed code has been invited into an environment that holds campaign systems, customer data, API keys, and production access.

Marketing teams are not expected to become package-registry experts. They are expected to know where an autonomous system can take action and where it must stop. When an agent can install a new dependency because a model named it confidently, the business has created a software procurement path without a buyer, an approver, or a receipt.

That is why this is an operating problem, not just a developer problem. A marketing agent may begin with a harmless request to clean a data export, localize a message, query analytics, or connect a tool. Each step can pull in an unfamiliar library. If the system is allowed to resolve that library on its own, the human checkpoint has disappeared exactly where supply-chain risk enters.

The accountable person is still outside the model. A vendor cannot make an unverified package acceptable by saying its agent selected it. A fluent recommendation is not evidence that the package exists, is maintained, or is safe. It is merely the beginning of a claim that must be verified before anything runs.

The failure is often organizational before it is technical. Security may own a software policy, marketing may own an agent with access to marketing data, and a vendor may own the runtime in between. Each party can assume the other checked the dependency path. A real control assigns that question to one operating owner and makes the answer visible in the launch record.

A generic instruction to use trusted packages is not enough. Trust needs a concrete meaning: an approved registry, a named package, a known version, a retained integrity check, and an escalation path if the agent wants something new. Without those conditions, a policy is advice that disappears the moment automation encounters an unfamiliar task.

The important design choice is whether verification is an optional reminder or a condition of execution. An agent may still research a new package and prepare a change. It should not turn that research into an install until the registry and approved inventory agree. That separation preserves the agent's usefulness while keeping a novel dependency from becoming a silent production decision.

Slopsquatting is the AI-era cousin of typosquatting. A language model recommends a package that does not exist. An attacker notices the predictable false name, publishes a package under it, and waits for a developer or agent to install it. The attack does not require breaking a trusted package. It uses the confidence of a generated answer as the delivery mechanism.

The USENIX Security 2025 study behind the warning examined 2.23 million code samples across 16 models. It found that 19.7% referenced a nonexistent package, producing 205,474 unique fabricated names. Open-source models averaged 21.7% package hallucinations, compared with 5.2% for commercial models. The exact figures are less important than the behavior: a made-up package name can sound credible enough to be acted on.

Attackers need repeatability, not perfection. The researchers found that 43% of hallucinated package names reappeared in every run of the same prompt, and 58% appeared more than once. That recurrence makes a fake name useful to register. It turns an individual model mistake into a target that can be anticipated, published, and found by the next person or agent who receives the same suggestion.

The Cloud Security Alliance research note documents the pattern and the practical defense. It is important not to overstate it. Slopsquatting is one supply-chain vector. A compromise caused by stolen publisher credentials is a different vector. Both deserve attention, but an accurate operating model identifies the path rather than collapsing every incident into one scary story.

The naming matters because it directs the response. A typosquatting control that only looks for misspellings will not necessarily catch a package invented by a model. The attacker does not need a name that resembles a famous package to a human reviewer. They need a name that the same model is likely to repeat. That is why registry verification must happen at install time.

The research taxonomy is useful here. Some names are conflations of real packages, some are typographic variants, and many are pure fabrications. The response cannot depend on a person recognizing the category by eye. A controlled tool should ask whether the exact package exists, whether its version is approved, and whether its integrity matches the lockfile the organization has already reviewed.

The statistic is not a prediction that one in five installs will be malicious. It measures how often a model can name something that is not real. Attackers exploit the gap between that plausible name and a missing verification step. The practical conclusion is narrower and more useful: never let model confidence substitute for package provenance.

A developer who sees an unfamiliar package can pause, search the registry, read its repository, and ask a colleague. An agent can remove every one of those pauses. It can propose the code, resolve the name, run an install, and invoke post-install behavior within a single delegated task. The benefit is speed. The cost is that the person who notices uncertainty may be absent.

This is especially consequential in a credential-rich environment. A package does not need to announce itself with a dramatic failure to be dangerous. It may read a token from an environment variable, alter a build step, collect an API key, or wait for a later trigger. The smallness of the action makes a retrospective dashboard a weak defense. By the time a team sees an anomaly, the install decision has already been made.

Real incidents show why the distinction matters. The CSA note describes a fake npm helper, unused-imports, positioned against the real eslint-plugin-unused-imports; it drew roughly hundreds of weekly downloads while a security team held the name. It also describes the huggingface-cli incident, where an AI-generated install command was copied into public documentation and the package accumulated more than 30,000 downloads in three months. A react-codeshift conflation then spread into 237 repositories through AI-agent skills.

Those examples are not an argument to ban code generation. They are an argument to stop treating generated dependency names as facts. A model can be excellent at producing a plausible string and still be wrong about whether anyone maintains it. The more autonomous the system becomes, the more the verification step must be engineered into the workflow instead of left to individual caution.

There is a second lesson in the TeamPCP campaign documented by Datadog Security Labs. Its compromise of packages including litellm andtelnyx involved credential theft, not a hallucinated package name. It belongs beside slopsquatting because an agent cannot distinguish the two at install time. It needs a boundary that detects and contains either path.

The business impact is not limited to a developer workstation. If an agent connects analytics, advertising, CRM, or customer support tools, it may have authorization that a normal package install would never receive. That makes least privilege part of the answer. An untrusted dependency should not inherit access to every token a marketing workflow happens to hold.

Separate credentials by task, environment, and action. An agent that drafts a campaign should not have the same ability to modify audiences or deploy code as an agent that operates a trusted production workflow. When a package is new or an agent is testing a connection, use a sandbox and deliberately limited credentials. A compromised dependency is less useful when the surrounding system refuses to hand it the keys.

The useful response is supply-chain discipline. Do not ask a model to be less persuasive. Design the environment so that a persuasive but incorrect suggestion cannot become executable code without passing through an approval path. That gives an agent room to be productive while keeping the install decision observable and reversible.

Start with a small boundary. Identify every agent that can create or modify code, install a dependency, run a shell command, or connect a new integration. For each, decide whether it may resolve a package at all. If the answer is yes, restrict it to an allowlist, require a locked version, and preserve the record of why that package entered the project. If the answer is no, make the failure explicit rather than letting the agent search for a workaround.

The same questions belong in vendor reviews. What dependencies can the provider add at runtime? Can its agent install a package on a customer environment? Does it maintain a software bill of materials? How does it verify package provenance and handle a compromised dependency? A vendor that cannot answer has not given the business a security guarantee. It has given it an unknown boundary.

For a CMO or marketing operations leader, the practical test is simple: could you explain the path from an agent's request to a new dependency running beside customer data? If not, the risk is not hidden in open source. It is hidden in the operating model. The goal is not to slow every task. It is to ensure that autonomy does not quietly become an unapproved route into the stack.

Use the first review to test the process, not to produce a compliance deck. Choose one agent task and follow it from request through dependency resolution, execution, and logging. Ask which packages were already approved, which would have been blocked, and who could stop the task. If the answers require several teams to reconstruct after the fact, the boundary is still too loose.

Keep the verified package list, exception record, and the evidence needed to explain an install. That gives an agent program a memory of what the business has already approved without turning every low-risk task into a meeting. Speed is still available. It is simply earned through an operating model that can tell a good dependency from a convincing fake.

That is the broader operating principle for agentic marketing: autonomy should be proportional to evidence. Give a stable, known workflow more room to act. Give a new dependency, new integration, or new customer-data path more friction until it has earned trust. This applies the supply-chain discipline a responsible team would use for any code that wants to run in a valuable environment.