Explainer · technology · October 2026

How Trust Becomes Access

A software supply-chain attack can begin with something as ordinary as installing a useful library. This companion to The Load-Bearing Volunteer follows the steps between accepting software and handing it authority — and shows where the chain can break.

Reading time ≈ 9 min · Draft · Last updated: 4 October 2026

The developer wanted a small improvement. The application needed to read a file in another format, and a reusable package seemed the quickest way to add it. The package installed successfully. The tests passed.

Those observations would establish that the installation completed and the tested behaviour worked. They would say little about what else the package had done.

This is an illustrative situation, not a reconstruction of a particular attack. It exposes the question behind The Load-Bearing Volunteer: when does accepting another person's work also give that work access to your systems?

Before the attack: what travels through the chain

A package is reusable software. A registry stores published packages; a package manager retrieves them and resolves their dependencies. A dependency is software a project needs. An indirect dependency arrives because another dependency needs it, although the project's author may never have selected it by name.

The source repository contains the development history. A release is a particular published version. A build processes source and dependencies into an artefact ready for distribution: a package, an application or a container image. Those objects are related, but checking one does not automatically establish what is in another.

An automated pipeline usually tests, builds and sometimes publishes software. Different stages need different permissions. Running a test might require access to a temporary directory. Publishing a release requires authority over a registry account. Deploying it may require access to a production service. Combining those permissions makes work convenient and makes a failure harder to contain.

The first diagram is the ordinary route, before anything goes wrong.

1. Source and dependencies
2. Build and test
3. Published artefact
4. Installation and execution

At each step, an organisation accepts something produced elsewhere. Security depends on what it verifies and what authority the next step receives.

The first route: change something people already trust

Suppose an attacker gains authority to publish a new release of a legitimate dependency. Existing users already recognise its name. Their applications may retrieve the new version through routine maintenance.

1. Release authority compromised
2. Malicious version published
3. Dependency update accepted
4. Code executes downstream

The attacker might obtain that authority by compromising an account, taking over maintenance or reaching a build system. These are different routes, with different evidence. Reviewing incoming source changes helps with one route; it cannot necessarily detect a package published outside the reviewed process.

The xz compromise illustrates the distinction. Andres Freund's March 2024 disclosure identified malicious material in release archives, including a build modification absent from the corresponding repository file. The affected library reached the secure-login service indirectly in certain Linux configurations. The compromised versions had not yet been widely deployed. Those conditions mattered: installing any version of a compression package did not automatically compromise every Linux machine. Original disclosure.

A signature can establish which key signed a release. It cannot establish that the signer was honest or the release harmless. Evidence of provenance can connect an artefact to a build process; it must also be checked against the process the organisation intended to trust.

Useful barriers therefore belong at several stages: protected release authority, reviewed changes, verification of the distributed artefact and restricted execution. No single badge replaces that chain of checks.

The second route: make an invented dependency real

A coding assistant can recommend a package that does not exist. If it repeatedly suggests the same plausible name, an attacker may publish a package under that name before a later user looks for it. Research on package hallucinations describes this supply-chain exposure in code-generating models. The measured frequency depends on the models, prompts and sampling procedure; it is not a universal probability for every coding task. Package-hallucination study.

1. Assistant suggests invented name
2. Attacker registers that name
3. User or agent installs it
4. Package code runs

The registry now appears to confirm the recommendation: there really is a package with that name. But existence is the only thing that has been confirmed. Nobody has established that it is the intended project or a safe substitute.

This differs from typosquatting, where the attacker chooses a name resembling a real package. It also differs from dependency confusion, where package resolution selects an unintended public package in place of a private dependency. The underlying mistakes are related, but the selection rules and remedies differ.

An agent can shorten the distance between suggestion and installation if its tools permit both. A human may approve the task of fixing a project without separately approving a newly introduced dependency. Whether that approval is sufficient is a system-design decision with security consequences.

Checking the project's identity and reviewing additions can interrupt the chain. Restricting agents to approved dependencies can prevent some installations. Package reputation and download counts may inform a review; neither proves safety.

The hinge: downloading becomes execution

A downloaded file is not equivalent to running its contents. A package may execute through an installation hook, a build step, an import or an application calling its functions. The timing depends on the ecosystem and the package.

When execution occurs, code normally uses the permissions of its process. It may be able to read project files or credentials available to that process. A sandbox can restrict those actions. A production database elsewhere remains inaccessible unless a network route and suitable authority, or a separate exploitable weakness, allow access.

That is why a dependency need not ask for a new password to cause damage. Its host process may already possess authority. It is also why compromise does not imply unlimited control: permissions and isolation can still refuse particular actions.

Disabling installation hooks can close one route while leaving execution during use possible. Testing in a disposable environment helps only if that environment is actually isolated from valuable credentials and services. A temporary machine with a powerful publishing credential is still a powerful machine.

The third route: turn execution into publishing authority

A publishing token is a credential a registry accepts as permission to release software. If malicious code can obtain a usable token, it may publish under the victim's authority. How far that goes depends on which packages the credential covers and what additional checks apply.

1. Code runs near credentials
2. Publishing credential exposed
3. Other releases contaminated
4. More users execute them

This can repeat when downstream victims also hold publishing credentials. Repetition is conditional, not automatic: many users have no release authority, and a narrowly scoped credential may permit changes to only one package.

Nx's account of its August 2025 incident describes a concrete route. A compromised automation workflow enabled theft of an npm publishing token. Attackers used it to release malicious packages outside the normal release pipeline. Installation scripts searched users' systems for sensitive information and attempted to use locally installed AI tools. Nx says it subsequently adopted trusted publishing and additional release approvals. This is the affected supplier's explanation, rather than an independent audit. Nx post-mortem.

The distinction matters for AI: malicious software using an assistant installed on a victim's machine is different from a model initiating an attack on its own. Both deserve investigation, but they establish different things.

The pipeline can carry the attack too

A pipeline reads information from outside the organisation: proposed code, dependency files, change descriptions and other contributions. That material must remain data where data is expected. If a workflow interprets untrusted text as executable instructions, a contribution can influence more than the proposed change.

GitHub's security guidance warns about untrusted inputs, recommends restricting workflow permissions and explains risks when privileged workflows process untrusted contributions. These are properties of the surrounding automation, whether the contribution was written by a person or generated by a model. GitHub secure-use guidance.

There is a related agent risk when retrieved material is treated as an instruction. A project's text may tell an agent to change its behaviour, but that text has no authority merely because the agent can read it. Ordinary software injection and instruction manipulation in a model are different mechanisms. Their practical meeting point is a tool that can execute actions under an identity with permissions.

The defensive question is concrete: can material supplied by an outsider influence an operation that holds release or deployment authority? An answer requires inspecting the workflow, rather than assuming that human review somewhere in the process protects every later step.

What stronger controls actually establish

Trusted publishing replaces a stored registry token with short-lived authority associated with an approved automation identity. npm's documentation explains how the registry verifies that identity and grants publication permission. It can reduce exposure to stolen long-lived credentials. It does not make an approved workflow incapable of producing a malicious release. npm documentation.

A version lock makes dependency selection more predictable. An integrity hash detects a mismatch with expected bytes. Provenance records how an artefact was produced. Isolation limits what executing code can reach. Each answers a different question.

For example, the expected bytes may already contain the malicious change. A reproducible build can faithfully reproduce compromised source. An approved pipeline can execute an unreviewed dependency. Controls are strongest when their assumptions are explicit and their protections remain effective when a neighbouring control fails.

Why stopping distribution is not the end

Removing a malicious package can prevent some new installations. It does not remove copies already downloaded or undo actions already performed. Revoking a stolen credential stops further use of that credential; it does not establish that every affected system is clean.

Recovery has to distinguish the published package, the machines that ran it, the credentials exposed and the artefacts produced afterwards. Rebuilding from trusted inputs may restore software while leaving questions about information already taken. Restoring a service and completing an investigation are different milestones.

CrowdStrike's 2024 outage belongs beside this argument as a comparison. Trusted distribution carried a legitimate but faulty update to many machines. The incident demonstrates amplification through a shared channel; it does not demonstrate a malicious dependency or an autonomous attacker. CrowdStrike's technical report.

The companion essay asks who has time to maintain the foundations. This one asks what those foundations are allowed to do. Funding, review and staffing matter because people must operate the controls. Permissions and separation matter because even careful people can accept a change that later proves dangerous.

Reading this with the series

Read The Load-Bearing Volunteer for the maintenance argument, and How an AI Agent Works for the model, tools and permissions behind an agent. The Warning Shot follows the incident that prompted the series. The diagrams here describe general routes; they do not assert that every step occurred in that incident.

Sources and method

Primary disclosures, research, supplier accounts and official documentation are linked at the claims they support. Sources were consulted on 4 October 2026. Supplier descriptions retain their attribution. The opening example and flow diagrams are explanatory constructions, not reports of additional incidents.

The technical standard is to explain mechanisms, required access, failed boundaries and defensive interventions without exploit payloads or reproducible attack procedures. This draft does not establish the security of a particular organisation or product.

Draft prepared with Codex (OpenAI). OpenAI develops agents discussed in the series and has a commercial interest in the subject. Anthropic, maker of Claude, also develops competing agents discussed elsewhere in the series; this post was not reviewed with Claude. Tool assistance is not independent expert review. Authored by Luis Matos Ferreira.

Updates and corrections: initial draft, 4 October 2026.