The dependency that does not exist
An engineer asks a coding agent to add a background job queue to a Python service. The agent proposes a plan, edits the manifest, and runs:
pip install fastqueue-proThe name fits the ecosystem. The import statements look idiomatic. The package does not exist. (fastqueue-pro is an illustrative name, unregistered on PyPI at the time of writing.)
This is a package hallucination: a model recommending a dependency that was never published. The security concern built on it is slopsquatting. If models invent the same plausible names repeatedly, an attacker can register those names on a public registry and wait for the next developer, or the next agent, to install them.
How common it is
The phenomenon is well measured. "We Have a Package for You!" by Spracklen et al., a Distinguished Paper at USENIX Security 2025, tested 16 code-generating models across 576,000 samples in two languages. It found hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models, and 205,474 unique invented package names.
Newer models are better but not clean. A May 2026 replication on five frontier models, including Claude Sonnet 4.6, GPT-5.4-mini, and Gemini 2.5 Pro, measured rates between 4.62% and 6.10% across 199,845 responses. It found 127 names that all five models invented, 53 of which were still available to register. The paper is from an independent researcher and has not been peer reviewed, but the direction is consistent: the range has narrowed, and the attack surface has not closed.
The exploitation evidence is thinner, and it is worth being precise about that. A July 2026 study by Orygn checked hallucinated names that had circulated publicly and found 22 had been registered, none of them malicious; 19 were placeholders registered by one person. Its authors note that zero malicious is not zero risk, because a benign placeholder can be updated later. The defensible claim is that package hallucination creates a predictable supply-chain attack surface, not that agents are routinely installing malware today.
Hallucination is becoming an action problem
Language models have always been wrong some of the time. What has changed is the distance between a model's claim and its consequences.
Before: model suggests a dependency -> human reads it -> human decides
Now: agent chooses a dependency
-> edits the manifest
-> installs it
-> writes code against it
-> runs the testsIn the first flow, a hallucinated package costs a failed search. In the second, the agent acts on its own wrong answer, and the first human to look at the result may be a reviewer three steps later. Agents can now act on their own mistakes before anyone sees them, which moves the question from model accuracy to control points.
Verification helps, and answers one question
The obvious control is to check the registry before installing. It works well. Trend Micro's June 2025 research tested Claude Code CLI, OpenAI Codex CLI, and Cursor with MCP-backed validation across 100 web development tasks. Reasoning-enhanced agents with live web search cut the hallucination rate roughly in half compared with base models, and MCP-backed real-time validation filtered out most of the hallucinations the other agents produced. In edge cases, a small number of hallucinated names still got through.
Registry lookups, vulnerability databases, and dependency scanners answer factual questions. Does this package exist? Does it have known vulnerabilities? Who publishes it? Those are necessary checks. They are not the whole decision, because a package can be real and still be wrong for this system:
- the organization has standardized on a different library for the same job;
- its licence is not approved for this product;
- it comes from a registry or publisher the security team does not allow;
- a specific major version is prohibited;
- the service already has an equivalent dependency;
- an architectural decision says this layer may not take on that kind of dependency at all.
Checking that a package exists answers a factual question. It does not answer the organizational one: should this package be introduced into this system?
Retrieval is not a decision
An MCP server connected to a package registry can tell an agent that a library exists, what version is current, and what licence it carries. It cannot tell the agent that, eighteen months ago, the team decided every outbound HTTP call in the payments service must go through the internal client that handles retries, auth, and audit logging. That fact is not in the registry. It is in an ADR, or a platform standard, or someone's memory.
There are three different kinds of knowledge in play:
| Kind | Question | Where it lives |
|---|---|---|
| World knowledge | Does this thing exist? | Registries, advisories, documentation |
| Project knowledge | How does this codebase work today? | The repository itself |
| Organizational decisions | What have we decided is allowed here? | ADRs, standards, policies, people |
Package hallucination is a failure of the first kind, and tools for the first kind are catching up. The third kind is the one agents are least equipped to find on their own, and the one that matters more as they gain autonomy. MCP is useful infrastructure for reaching all three. Connecting an agent to a source of decisions is still not the same as binding the agent to them.
The control belongs before the action
If a dependency violates a security or architectural decision, the cheapest time to find out is before the agent installs it, not during code review three pull requests later. A governed dependency change looks roughly like this:
Agent proposes a dependency
-> Does it exist? (registry)
-> Is it known-bad? (security evidence)
-> Which decisions apply to this path? (decision record)
-> Evaluate the change against them (deterministic check)
-> Allow, warn, or block (verdict)
-> Record what happened (evidence)Walk the payments example through it. The agent wants to add a popular third-party HTTP client to payments/. The package exists and has no known advisories, so the first two checks pass. The decision record says outbound HTTP in payments/** must use the internal client. The check fails, the agent is told why and what the approved alternative is, and the event is recorded against the decision that produced it.
The governance system did not make the architectural decision. People made it, once, for reasons that are written down. The system's job is to make sure an autonomous agent respects it without anyone having to repeat it in every prompt.
Dependencies are the most visible example, not the only one. The same pattern applies when an agent picks a database, a cloud service, an authentication method, a framework, or an external API. Package hallucination is just the case where the failure is obvious enough to measure.
What engineering leaders should do
- Put registry validation in front of any agent that can install packages. It is cheap and the evidence says it removes most hallucinated names.
- Keep dependency security in dedicated tools: registries, advisory databases, SBOMs, and package scanners already do this well.
- Write down the dependency decisions that are really organizational policy, such as approved libraries, prohibited layers, and required wrappers, and scope them to the code they govern.
- Make those decisions reachable by agents at the moment they change code, and check the changes against them before merge at the latest.
Where Mneme fits
Mneme is not a package-security tool. It does not check registries, licences, or vulnerability data, and it does not prevent slopsquatting. Those belong to the tools above.
What Mneme handles is the organizational layer for architectural decisions in a repository. Today that means compiling an accepted decision into a typed rule that forbids a specific literal, such as a direct import of a disallowed client, scoped to the paths the decision governs, and returning a deterministic FAIL when a proposed change contains it. Agents can also ask Mneme's local Decision MCP server, shipped in 0.9.0, which decisions apply to the files they are about to touch. Consuming registry and security evidence as inputs to the same verdict is a direction, not a shipped capability.
The warning, not the real problem
Package hallucinations are easy to understand because the failure is obvious: the model invented something that does not exist. The harder problem starts when the thing does exist. A real package, API, database, or pattern can still be the wrong choice for a particular organization. As coding agents move from suggesting changes to executing them, organizations need a way to represent their decisions, determine when those decisions apply, and apply them before the action, not after.