Everybody’s shipping code they can’t read, and that changes trust

At a glance

What this is: This is an analysis of how AI-assisted coding shifts dependency trust decisions away from human review and into automated package selection and install-time execution.

Why it matters: It matters because teams must decide how to govern code, secrets, and runtime privileges when AI systems can introduce dependencies faster than traditional review and identity controls can keep up.

By the numbers:

• This month, an attacker republished 141 packages in the popular @mastra AI-agent ecosystem in a 45-minute overnight burst, slipping a malicious dependency into every one.

👉 Read Aikido's analysis of why AI-generated code changes dependency trust

Context

AI-assisted software generation changes the trust boundary in application delivery. Instead of a developer reading code, selecting dependencies, and approving install steps, an agent can assemble packages, run scripts, and hand back a working result with limited human oversight. That creates a governance gap for code provenance, dependency trust, and the credentials available in the build and runtime path.

The identity angle is real even in a software supply chain story. Once an agent can execute code, fetch packages, and interact with repositories or cloud services, it starts operating like a non-human identity with delegated access and implicit trust. That makes package selection, install-time execution, and downstream credential exposure part of IAM and NHI governance, not just AppSec hygiene.

Key questions

Q: How should security teams govern AI coding assistants that can execute commands?

A: Treat them as delegated non-human identities with bounded execution authority. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.

Q: Why do AI-generated package choices create more supply chain risk than normal developer workflows?

A: Because the agent can move from intent to execution without the human judgment step that usually filters suspicious packages. That widens exposure to typosquatting, slopsquatting, and malicious install scripts. The risk is highest when the agent also has access to tokens, signing keys, or repository write permissions.

Q: What breaks when automatic install scripts are allowed in AI-assisted builds?

A: Install scripts can execute before trust is established, which lets malicious code stage payloads, touch local storage, or pivot into credentials available in the build environment. In agentic workflows, that turns dependency installation into an execution channel. The result is a much larger blast radius than static code review alone would detect.

Q: How do security teams reduce the impact of slopsquatting and dependency poisoning?

A: Use package allowlisting, provenance validation, and strict egress controls for build environments. Then limit the agent’s ability to resolve or fetch arbitrary dependencies. The point is to ensure that package selection is governed by policy, not by a model’s guess about what package name looks plausible.

Technical breakdown

How AI agents introduce package trust risk

AI coding agents do not just generate code. They can resolve dependencies, invoke package managers, and execute install scripts as part of an automated workflow. That means a model or agent can move from suggestion to execution without a human validating each dependency choice. The risk is not limited to malicious packages already known to defenders. It also includes slopsquatting, where attackers register package names that an AI is likely to invent, turning hallucinated dependency suggestions into a delivery path for malware.

Practical implication: treat package resolution and install-time execution as controlled trust events, not background convenience.

Why install scripts and ephemeral build environments still leak risk

Sandboxing reduces blast radius, but it does not remove trust. Malicious install scripts can still run inside the build environment, reach browser storage, modify local files, or stage payloads for later use. If that environment can later publish code, access tokens, or sync with a repository, the compromise escapes the sandbox’s intended boundary. In practice, the dangerous part is not only what runs during installation, but what credentials and artifact access are available immediately afterward.

Practical implication: separate build execution from credentialed deployment paths and assume install-time code is adversarial until proven otherwise.

Why AI-generated code creates an identity and governance problem

When an agent fetches libraries or executes tools on behalf of a person, it is acting with delegated authority. That makes the agent’s permissions, audit trail, and tool access part of an identity model. Without clear ownership, you end up with shadow AI behaviour inside engineering workflows, where no one can easily explain which system chose a dependency, which secret it touched, or which repo it modified. The governance issue is therefore broader than malware prevention. It is about proving who or what performed each action and under what authority.

Practical implication: register AI coding agents, constrain their tool scopes, and log their actions like any other privileged non-human identity.

Threat narrative

Attacker objective: The attacker wants to turn automated dependency selection into a malware delivery channel that captures secrets, persists on developer systems, and contaminates software supply chains.

1. Entry occurs when an attacker plants or repackages a dependency that an AI coding workflow is likely to select automatically.
2. Credential access or payload execution begins at install time, when malicious scripts run inside the agent’s build environment and stage a second payload.
3. Impact follows when the payload persists on the workstation or build host, harvests wallet or browser data, and increases the chance of downstream repository or credential compromise.

NHI Mgmt Group analysis

AI coding has turned dependency trust into a non-human decision problem: the central failure is no longer that developers ignore package risk, but that agents can choose, fetch, and execute dependencies without the same review path humans rely on. That shifts governance from code review alone to controls on package provenance, install-time execution, and tool permissions. Practitioner conclusion: security teams need to govern the decision point, not just the resulting code.

Slopsquatting is a governance failure, not just a malware trick: the article shows that AI hallucinations can become an exploitation surface when attackers pre-register plausible package names. This is a supply chain problem with identity implications because the agent is effectively an unvetted requester acting on behalf of a user or pipeline. Practitioner conclusion: treat package naming, allowlisting, and provenance checks as part of the agent’s access policy.

Install-time execution is the new blast-radius multiplier: package scripts can bridge the gap between a sandboxed build and a real repository, token store, or developer workstation. That means the control failure is not only malicious code in a dependency, but code that is allowed to execute before trust is established. Practitioner conclusion: restrict automatic script execution and require explicit approval for high-risk package behaviors.

Shadow AI in engineering pipelines needs identity governance: once agents can act across repositories, package registries, and build systems, they are performing privileged actions that should be attributable and bounded. This is where NHI governance and software supply chain security meet. Practitioner conclusion: inventory AI agents, bind them to named owners, and monitor them like other privileged non-human identities.

Code generation speed will keep outpacing manual review: the article’s core warning is that the old answer of reading every diff does not scale to agent-driven development. That makes trust controls at retrieval and execution time more important than after-the-fact inspection. Practitioner conclusion: invest in prevention and telemetry at package intake, not just scanning after code lands.

What this signals

Shadow AI in software delivery: as agents become normal in coding workflows, the relevant control question shifts from code quality to delegated authority. Teams need to know which systems can fetch packages, run install scripts, and access secrets. That makes identity inventory, tool scoping, and artifact provenance part of the engineering security baseline, not an advanced add-on.

The operational signal is that trust has to move closer to retrieval and execution. Once package selection is automated, controls like allowlisting, signed provenance, and script suppression matter more than post-merge inspection. For identity teams, this is the same governance pattern seen in non-human identities: narrow the scope, shorten the access window, and maintain accountability for every privileged action.

For practitioners

• Control package intake before execution Block known-malicious packages and enforce allowlists or provenance checks before any dependency is installed in agent-driven workflows. Make the package manager fail closed when metadata is incomplete or the source is untrusted.
• Disable automatic install scripts by default Require explicit approval for postinstall and other execution hooks, especially in environments where an AI agent selects libraries. Many supply chain compromises begin at install time, not in the application code itself.
• Separate agent workflows from privileged credentials Run AI coding agents in scoped environments that cannot reach production secrets, signing keys, or long-lived cloud credentials. If the agent must build artifacts, give it only the minimum access needed for that isolated task.
• Log agent actions as identity events Record which agent chose a dependency, invoked a tool, or modified a repository, and tie those events to a named owner. That audit trail is necessary to investigate shadow AI behaviour and demonstrate accountability.

Key takeaways

• AI-assisted coding turns dependency choice into a machine-mediated trust decision, which expands the supply chain attack surface.
• The strongest evidence in the article is that attackers can poison popular package ecosystems quickly enough to reach widely used AI workflows.
• Security teams should govern AI agents like privileged non-human identities by constraining package intake, install-time execution, and secret access.

Key terms

• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated non-human identity: A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.

What's in the full article

Aikido's full blog post covers the operational detail this post intentionally leaves for the source:

• The package republishing timeline and how the malicious dependency was inserted into the @mastra ecosystem.
• The exact install-time behaviour of the payload, including how it launched and deleted itself to hide evidence.
• The attack path into browser crypto wallets and the persistence methods used across Mac, Windows, and Linux.
• The practical guidance around Aikido Device Protection and the Vibe Coding Checklist for Security.

👉 The full Aikido post covers the package attack pattern, install-time payload behaviour, and guardrail recommendations.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the control model needed when software agents start acting with delegated authority.