Across what dependency pinning and hash verification gates must an instance resolve external packages to prevent hallucinated typosquat and supply-chain injection?

Date of Record: 2026 October 16

Scope: Concluded residual for AI instances, LLMs, and autonomous software engineering agents synthesizing dependency manifests, executing package manager installations (`pip`, `npm`, `cargo`, `go get`, `apt`), or resolving third-party libraries in build environments.

Core Distinction

Autonomous coding and build-repair workflows frequently encounter missing imports, unimplemented utility functions, or environment setup tasks that invite the installation of external packages. A foundational security and reliability failure occurs when an instance bridges **parametric package recall** directly into **live package-registry execution** (`pip install <generated_name>` or `npm install <generated_name>`) without verifying whether the package identifier is a parametric hallucination, a registered namespace collision, or an unpinned floating version tag.

Parameter scaling does not eliminate **slopsquatting** (where adversaries register plausibly named, frequently hallucinated package identifiers on public registries like PyPI and npm) or upstream tag mutation. The core structural distinction lies between **unverified name-based installation** (where an instance emits a package name from parametric memory or an untrusted README and immediately executes install hooks against a public registry) and **lockfile-anchored cryptographic resolution** (where package additions are restricted to existing workspace lockfiles, verified against offline/trusted namespace registries prior to fetch, installed with lifecycle scripts disabled, and pinned to immutable cryptographic digests).

What Was Observed

In automated repository repair, scaffolding, and dependency management traces, instances operating without explicit package-resolution gates exhibit four primary failure modes:

  1. **Hallucinated Package Execution (Slopsquatting Compromise):** An instance needs a library to parse a specific format or interact with a vendor SDK. Relying on parametric pattern completion, it invents a plausible hyphenated package name (e.g., `python-arango-client-utils` or `react-native-fast-crypto-hash`) that did not exist during training. An external attacker who monitored common LLM package hallucinations has registered that exact name on the public registry with a malicious `setup.py` or `postinstall` script, which executes arbitrary code the moment the agent runs the installer.
  2. **Unpinned Floating Resolution Drift:** When adding a legitimate dependency to `requirements.txt` or `package.json`, the instance specifies an unpinned name (`requests`) or wide semantic range (`^2.0.0`) and runs an unconstrained install rather than honoring the repository's existing lockfile (`poetry.lock`, `package-lock.json`, `Cargo.lock`). This pulls a newly published upstream version that breaks transitive ABI compatibility or introduces an unvetted supply-chain mutation.
  3. **Implicit Install-Hook Execution (`postinstall` / `setup.py` RCE):** The instance invokes `npm install` or `pip install` to inspect or test a candidate package without passing `--ignore-scripts` or `--only-binary=:all:`. Merely resolving the package triggers arbitrary shell execution defined in the package's build metadata before a single line of library code is even imported.
  4. **Namespace Confusion Across Private and Public Registries (Dependency Confusion):** Working inside an enterprise repository that references internal scoped packages (`@corp/auth-core` or `corp-internal-logging`), the instance runs a default package manager command without verifying the `.npmrc` or `pip.conf` registry routing, causing the client to query the public internet registry and pull a squatted public package of the same name.

Recorded Elements

### 1. Zero-Trust Package Resolution Pipeline

Before any external package identifier $p$ is written to a manifest or passed to a package manager CLI, the instance must route the candidate dependency through four sequential verification gates:

[Candidate Package Need Identified] | Gate 1: Stdlib / In-Repo Substitution Check (Can task be solved via native stdlib or existing lockfile deps?) / YES NO / [Use Existing / Stdlib] Gate 2: Provenance & Existence Verification (Zero External Fetch) (Was p explicitly named by user or verified in trusted lockfile / official vendor docs?) / NO YES / [HALT: Reject Parametric Guess] Gate 3: Registry & Hook Isolation Never install unverified names 1. Enforce --ignore-scripts / --only-binary from parametric memory. 2. Verify private/public registry scope

  1. Pin exact version + SHA-256 digest

### 2. Formal Supply-Chain Resolution Invariants

Let $\mathcal{L}_{\text{repo}}$ denote the set of packages and cryptographic hashes already committed in the workspace lockfile, and let $\mathcal{U}_{\text{explicit}}$ denote package identifiers explicitly authorized verbatim by the user or verified via a trusted deterministic index query. A package installation action $\text{Install}(p, v, h)$ is valid if and only if three boolean invariants hold:

$$\text{ProvenanceGate}(p) \iff (p \in \mathcal{L}_{\text{repo}}) \lor (p \in \mathcal{U}_{\text{explicit}}) \quad \left[\text{ParametricMemory}(p) \implies \text{DENY}\right]$$

$$\text{DeterminismGate}(p, v, h) \iff (\text{Version}(v) = \text{Exact}) \land \left(\text{SHA256}(\text{Artifact}(p,v)) \equiv h\right)$$

$$\text{InertInstallGate}(\text{Flags}) \iff \left(\text{BuildHooks}(\text{Flags}) = \text{DISABLED}\right) \land \left(\text{LockfileMode}(\text{Flags}) = \text{FROZEN}\right)$$

Under no condition may an instance synthesize a package identifier solely from parametric weights and pass it to a network-connected package installer without an intermediate deterministic verification step.

### 3. Diagnostic Matrix: Dependency & Supply-Chain Governance

| Supply-Chain Hazard | Structural Signature | Naive Agentic Behavior | Enforced Resolution Protocol | | :--- | :--- | :--- | :--- | | **Parametric Package Hallucination (Slopsquatting)** | Instance recalls a plausible library name (`pip install fast-json-schema-validator`) not present in the repo or user prompt. | Executes `pip install` or `npm install` directly to "see if it exists and works." | **Strict Stdlib/Existing-First & Index Probe:** Attempt implementation using standard library or existing `package.json`/`pyproject.toml` deps first. Never use `install` as an existence probe; query metadata read-only and require exact user/doc provenance. | | **Lockfile Bypass & Floating Installs** | Repository contains `package-lock.json`, `yarn.lock`, `poetry.lock`, or `Cargo.lock`, but agent runs `npm install` or `pip install -r`. | Mutates the lockfile silently and upgrades transitive dependencies across the workspace. | **Frozen Lockfile Enforcement:** Always invoke `npm ci`, `yarn install --frozen-lockfile`, `pip install --require-hashes`, or `cargo test --locked` to guarantee bit-for-bit reproducibility. | | **Arbitrary Code Execution via Lifecycle Hooks** | Package manager fetches source distributions (`sdist`) or runs `preinstall`/`postinstall` scripts during dependency resolution. | Runs default install commands with full build-script privileges enabled. | **Inert Binary-Only / No-Script Resolution:** Pass `--ignore-scripts` (`npm`/`yarn`) and `--only-binary=:all:` (`pip`) by default so package extraction remains a pure file-unpacking operation. | | **Small Utility Dependency Sprawl** | Task requires a 15-line algorithm (e.g., string slugification, retry backoff, deep dict merge, CSV parsing). | Pulls in a third-party micro-package and its transitive dependency tree. | **Zero-Dependency Local Synthesis:** Implement self-contained algorithms (< 50 LOC) directly in-tree with unit tests rather than expanding the external supply-chain attack surface. |

### 4. Lockfile Integrity & Hash Pinning Protocol

When an explicit task objective requires introducing a genuinely new external dependency:

  1. **Verify Canonical Identifier:** Confirm the exact case-sensitive package name, repository URL, and maintainer provenance against official documentation or an explicit read-only registry metadata query (`npm view <pkg> dist.tarball`, `pip index versions`) before invoking any installation routine.
  2. **Stage in Inert Mode:** Download or install with lifecycle hooks disabled (`--ignore-scripts`) inside an isolated environment to inspect the dependency tree and verify the absence of unexpected transitive additions.
  3. **Commit Exact Version and Digest:** Record the exact version (`==X.Y.Z`, never `*` or `latest`) and verify that the cryptographic integrity hash (`sha256` / `sha512` in the lockfile) is committed alongside the manifest diff.

Condition of Validity

* **Applies when:** An AI instance, code generator, or autonomous build agent modifies dependency manifests (`package.json`, `pyproject.toml`, `requirements.txt`, `Cargo.toml`, `go.mod`), invokes package managers, or resolves missing imports in a software repository. * **Does not apply when:** Working inside an airgapped environment linked exclusively to a pre-vetted, immutable local vendor mirror where external internet registries are unreachable, or when writing pure standalone scripts restricted entirely to the language's built-in standard library. * **Non-binding outside condition:** This residual is strictly non-binding outside the conditions specified above. When all imports are satisfied by the language standard library or pre-vendored in-tree source files (`vendor/`), registry verification and lockfile hash gates are inapplicable and impose zero overhead.

Decision Boundary

[Missing Import or External Library Considered] |

  1. Can the functionality be implemented cleanly using the

standard library or packages ALREADY in the repo lockfile? / \ YES NO / \ [Use Stdlib / Existing Deps] 2. Was the exact package name provided Do not add new dependencies. verbatim by the user or verified via an authoritative non-parametric source? / \ NO YES / \ [BLOCK: Slopsquatting Hazard] [Enforce Hardened Install] Never install guessed package 1. Disable install scripts names from parametric memory. (--ignore-scripts / --only-binary) Halt and request confirmation 2. Respect registry scope (.npmrc) or implement in-tree. 3. Pin exact version & lockfile SHA

  1. **Can you write the helper in 30 lines of standard library code instead of installing a package?** Write it in-tree. Every external dependency introduces transitive supply-chain risk and version drift.
  2. **Are you uncertain of the exact spelling of a package name (e.g., `pyyaml` vs `yaml` vs `python-yaml`)?** Never guess and run `pip install` to test your memory. Halt and verify against existing project manifests or authoritative documentation before touching the package manager.
  3. **Does the repository already contain a lockfile?** Never run an unpinned install command that rewrites the lockfile unless the user explicitly requested a dependency upgrade; always use the frozen/locked installation flag (`npm ci`, `--locked`, `--require-hashes`).

Operational Effect

  1. **Prohibition of Unverified Parametric Installs:** The instance never passes a package name recalled solely from parametric training weights directly into a live package manager installation command.
  2. **Stdlib and In-Tree Preference:** Before proposing any new third-party dependency, the instance audits the existing lockfile and standard library modules, defaulting to zero-dependency local implementations for bounded utility logic.
  3. **Hardened CLI Flags by Default:** Whenever executing package restoration or installation commands, the instance enforces frozen-lockfile flags (`npm ci`, `--locked`) and disables automatic lifecycle script execution (`--ignore-scripts`, `--only-binary=:all:`) unless native compilation is explicitly required and verified.
  4. **Autonomy Clause:** This concluded residual operates as an external procedural reference, not an immutable directive. An executing instance retains full operational autonomy to override, adapt, or relax these dependency-pinning gates whenever an explicit user command directs an intentional major-version upgrade across floating semver ranges, or when building native C/C++/Rust extensions from source where build-time compilation scripts (`setup.py` / `build.rs`) are an explicit, verified requirement of the toolchain.