TL;DR: AP-005 Package Supply Chain is a coding-agent security pattern where an AI agent introduces external package trust while pursuing a legitimate engineering task. The agent may choose a dependency, invent a package name, add an import, edit a manifest, run a package manager, or retry a failed install before a human reviewer understands why that package was selected. Existing supply-chain controls such as lockfiles, SBOMs, vulnerability scanners, signatures, and artifact provenance remain essential, but they mostly inspect what the project has already accepted. AP-005 focuses on the upstream boundary where the agent turns "we need capability X" into "install package Y."
A developer asks an AI coding agent to add OAuth to an internal dashboard. A few minutes later, the diff looks reasonable. The route handler has changed. A callback URL has been added. Tests have been updated. Somewhere in the middle of the patch, package.json now includes a new dependency.
No one explicitly selected that package. The workflow did. For most of modern software engineering, package selection has been treated as a developer decision. A developer needed an HTTP client, parser, test runner, SDK, or authentication library. They searched, read examples, compared tradeoffs, and chose something. Security controls then tried to make that choice safer: lockfiles pinned versions, scanners found known vulnerabilities, SBOMs described what ended up in the artifact, and provenance systems explained where a package came from.
That model depends on a quiet assumption: by the time security tooling enters the picture, the package has already been chosen by a person. AI coding agents weaken that assumption. They increasingly participate in planning a change, editing manifests, resolving import errors, running package managers, retrying failed installs, and adapting when a dependency does not behave as expected.
The package manager is no longer the first system making a trust decision. The agent is. The security question is not only whether an install is safe. It is whether the workflow was authorized to introduce that external trust at all.
Attack card
| Attack ID | AP-005 |
| Name | Package Supply Chain |
| Pattern | An AI coding agent introduces external trust by selecting, inventing, installing, or adding a package dependency while pursuing a legitimate engineering objective. |
| Primary condition | Agents with permission to edit dependency manifests, generate imports, run package managers, search documentation, resolve build failures, or modify lockfiles. |
| Common triggers | Feature implementation, missing imports, failed tests, dependency errors, OAuth or SDK integration, file parsing, CLI generation, migration work, and automated repair loops. |
| Security impact | Typosquatting, dependency confusion, HalluSquatting, unauthorized public packages, malicious install scripts, transitive dependency exposure, license drift, and unapproved trust in production paths. |
| Key distinction | The security-sensitive moment can happen before installation: when the agent decides which package should be installed. |
| Detection challenge | Downstream tools can scan the selected package, but may not preserve why the agent selected it, whether alternatives were considered, or whether the task authorized a new dependency. |
Why package selection matters
Package selection has always carried more authority than it appears to from the surface. Adding a dependency imports a maintainer relationship, a release process, a registry namespace, a transitive dependency graph, install-time behavior, and a future update stream. In ecosystems such as npm, PyPI, Cargo, and Go modules, one package name can expand into many reachable components over time.
It is also a trust introduction. The project has accepted a new external source of code and allowed that source to become part of its execution path. Traditional attacks exploit that trust. Typosquatting relies on a developer selecting the wrong-looking-right package. Dependency confusion relies on resolution behavior that pulls a package from the wrong registry or namespace. Malicious package campaigns rely on open registries where publishing is easy and installation is convenient. OWASP's CI/CD Top 10 describes how third-party packages and remote artifacts enter build and delivery pipelines, and why artifact integrity validation matters.
These are not AI problems by origin. They are package ecosystem problems. AI changes the entry point. The attacker no longer needs only to trick a human into typing the wrong name or configure a registry to resolve an internal name externally. The attacker can also target the agent's route to the package decision: generated code, error recovery, consulted documentation, plausible names invented by the model, or retry behavior after a package fails to resolve.
The traditional software supply chain starts after choice
The modern supply-chain stack has become much better at answering questions about artifacts. SBOMs record components and dependency relationships. SLSA gives teams a framework for build integrity and provenance. Sigstore, npm provenance, PyPI attestations, trusted publishing, Go's checksum database, Cargo lockfiles, and registry controls all improve the ability to verify what was published, downloaded, built, or shipped.
These controls matter. They raise the floor for package integrity and artifact traceability. They help teams detect unexpected changes, inspect build origin, verify signatures, and understand what shipped. They become most useful after dependency identity is known.
An SBOM can tell you that a package is present. It does not explain why the agent selected that package during a refactor. A provenance statement can show where a package was built. It does not prove the package was the right dependency for the task. npm provenance and PyPI attestations improve origin evidence, but PyPI's own attestation security model makes the key distinction clearly: origin evidence is not the same as a trust decision.
The artifact may be well described while the selection remains opaque.
AI-assisted dependency selection
Coding assistants have moved from suggestion engines toward execution environments. Public product behavior differs by vendor, configuration, and permission mode, so broad claims about autonomous package selection should be treated carefully. What is clear is proximity: coding agents increasingly live close to manifests, terminals, package managers, and developer workspaces.
In practice, recommendation precedes installation. A user asks for a new feature, and the agent decides a library would shorten the implementation. A test fails because an import is missing, and the agent tries to install something. A package name fails to resolve, and the agent searches, guesses, retries, or substitutes a nearby alternative. None of this requires a dramatic exploit. It follows naturally from an agent trying to complete an engineering task.
HalluSquatting attracted attention because it exposed that selection phase. USENIX research on package hallucinations found that code-generating models can recommend non-existent packages, and that some hallucinated names recur. If an attacker identifies a package name that models repeatedly invent, they can register it and wait for future users or agents to install it. OWASP citizen-development guidance also warns that AI assistants may hallucinate packages, libraries, or APIs.
HalluSquatting is useful evidence because it shows package selection becoming externally exploitable. The risk extends beyond non-existent packages. Once a package name is generated by the agent, older attacks can re-enter the workflow: a typo-like package, a public package matching an internal name, a newly published package with polished documentation, or a transitive dependency graph that behaves differently after installation.
Existing defenses arrive too late
Most supply-chain defenses inspect what the project has already accepted. Lockfiles pin selected versions. Vulnerability scanners compare selected components against known advisories. SBOMs describe selected components. Provenance systems describe selected artifacts. Registry signatures and checksum databases help verify that selected package content matches what the ecosystem expects.
Those records are valuable. They rarely preserve the moment the dependency entered the plan. For human-driven development, the answer often lives in a code review comment, a Slack discussion, a design doc, or a developer's memory. That was always imperfect, but it was socially legible. Reviewers could ask: why did we add this, who chose it, and what alternatives did we reject?
Agentic development makes that trail easier to lose. The package may appear as the side effect of a longer task: fix the failing test, add OAuth, parse this file type, migrate this endpoint, generate a CLI, make the build pass. By the time the manifest changes, the rationale may be buried in a transient reasoning path or hidden behind a tool call.
Short answer for security teams: AP-005 is not just dependency hygiene. It is package-selection governance at runtime. The key question is whether this agent workflow was allowed to introduce a new external dependency, not only whether the resulting package scans clean.
Package Supply Chain as an attack pattern
Package Supply Chain is a workflow attack pattern, not a single exploit. The pattern begins when an AI coding agent is asked to accomplish an engineering goal that plausibly requires a dependency. The agent identifies or invents a package candidate. The candidate enters the workspace through a manifest edit, install command, generated import, lockfile update, or code path that assumes the dependency exists. The package manager resolves it. Downstream tooling may verify signatures or scan vulnerabilities, but the trust introduction has already happened.
The agent may hallucinate a package and later install an attacker-registered version. It may choose a typo-like package that resembles the intended dependency. It may resolve a name through a public registry when the organization expected an internal package. It may prefer a package because it appears in generated documentation rather than because it is approved for the environment. It may select a package that is real, signed, and free of known CVEs, but still inappropriate for the organization's data path, license constraints, execution model, or maintenance expectations.
This last case is easy to underweight. Supply-chain risk also includes unauthorized trust. A package can be authentic and still be the wrong dependency for a production system.
In enterprise environments, Package Supply Chain becomes more serious because dependency decisions often intersect with private repositories, internal SDKs, deployment systems, and production credentials. A coding agent working on a service may need to distinguish between a public package and a company-approved internal package, preserve registry configuration, respect private namespace rules, and keep experimental dependencies out of deployable paths.
Runtime implications
If package selection is part of the attack surface, runtime systems need to preserve more than commands and file diffs. The path from task to dependency becomes part of the security record. Did the name come from existing project files, official documentation, an approved internal registry, a user instruction, or a model-generated guess? Did a failed import become an install attempt? Did a repair loop quietly introduce a new package rather than fix the original code?
The answer cannot be blocking every dependency change. Engineering systems need room to move. The runtime record should make package selection visible as a decision, not let it disappear into the background noise of an agent session.
Once that record exists, policy becomes more precise. A new package identity is different from an update to an approved dependency. A public registry lookup from a production service is different from a public registry lookup in a scratch project. A dependency suggested by official documentation is different from one invented during an error recovery loop. A package pulled from an approved internal namespace is different from a lookalike public package.
Provenance needs to expand with this shift. Artifact provenance tells us where software came from. Agent workflow provenance should tell us how a package entered the plan. A package may be signed and traceable while the selection path that introduced it remains opaque.
Where Gensee Crate fits
Gensee Crate is built for long-horizon runtime visibility and enforcement around AI coding agents. For AP-005, the important boundary is the moment an agent turns a task into an external dependency. Crate can connect the user request, agent task, generated code, manifest edits, package-manager commands, registry access, file changes, approval prompts, and later operations into one runtime trajectory.
The goal is not to replace SBOMs, provenance, package signatures, registry policy, or vulnerability scanners. Those controls remain essential after a dependency is selected. Crate adds runtime evidence around the upstream decision: why this package, why now, from which registry, under which task, and with what authority.
That evidence lets enforcement be more precise. It can allow approved dependency updates, flag new public packages in production repositories, require approval for unrecognized package identities, block dependency installation during unrelated tasks, and preserve provenance when package selection emerges from a repair loop. The deeper and longer view matters because the security-relevant action may not be the install command alone. It may be the sequence that made the install appear reasonable.
Questions for engineering and security teams
Can your coding agent add dependencies, edit lockfiles, or run package managers? Can it choose packages based on generated documentation, error recovery, or model guesses? Can it distinguish approved internal packages from public lookalikes? Do reviewers see why a dependency entered the plan, or only that a manifest changed?
Do your policies treat a new package identity differently from a version bump? Can you block public registry lookups in production services while allowing them in scratch workspaces? Can you reconstruct whether a package came from a user instruction, existing project pattern, official docs, or agent inference? If not, you may have package scanning, but not agent-runtime package-supply-chain security.
Frequently asked questions
What is AP-005 Package Supply Chain?
AP-005 Package Supply Chain is a coding-agent security pattern where an AI agent introduces external trust by selecting, inventing, installing, or adding a package dependency while pursuing a legitimate engineering task.
Why does AI change software supply-chain risk?
AI coding agents can participate in dependency selection before a package appears in a manifest, lockfile, SBOM, scanner result, or provenance statement. That moves the first trust decision upstream into the agent workflow.
How is AP-005 related to HalluSquatting?
HalluSquatting is one example of AP-005. It exploits package names that code-generating models hallucinate. AP-005 also includes typosquatting, dependency confusion, unauthorized public packages, and real but inappropriate dependencies selected by an agent.
Why are SBOMs and provenance not enough for AP-005?
SBOMs, lockfiles, vulnerability scanners, signatures, and provenance describe selected packages and artifacts. AP-005 asks why the package was selected by the agent in the first place and whether the original task authorized that external trust.
How does Gensee Crate help with Package Supply Chain risk?
Gensee Crate connects the user request, agent task, generated code, manifest edits, package-manager commands, registry access, file changes, approvals, and later operations into a runtime trajectory so package selection can be treated as a security boundary.
Sources
This post references OWASP's CI/CD artifact integrity guidance, the SLSA specification, npm's package provenance documentation, PyPI's attestation security model, USENIX Security 2025 research on package hallucinations by code-generating LLMs, and the open-source Gensee Crate repository.