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

At a glance

What this is: Aikido argues that AI-written code changes software trust by moving dependency selection and execution into a workflow where humans may never review what gets installed.

Why it matters: For IAM and NHI practitioners, this matters because build-time packages and install scripts are becoming a new trust boundary, with direct implications for secrets exposure, privileged execution, and software supply-chain governance.

Context

AI-assisted development changes the control point, not just the pace of coding. When an agent can choose libraries, execute install-time code, and hand back runnable output, the trust boundary shifts from human review to machine-selected dependencies. That creates a governance gap for software supply chains, because the most consequential decision is no longer which lines of code get merged, but which third-party package is allowed to run in the first place.

This is also an identity problem in practice, even if the article is framed as developer tooling. Agent-driven coding systems can act like non-human operators with delegated authority over package selection and execution, which means their trust and privilege need governance before any repository or runtime receives the output. That pattern is now typical, not exceptional, for teams adopting AI coding workflows.

Key questions

Q: What breaks when AI-generated package names are allowed to install without review?

A: The main failure is that model output becomes an execution path. A hallucinated package name can be registered by an attacker, installed automatically, and allowed to run install-time code that steals secrets or plants further payloads. The control gap is unverified dependency execution, not merely poor model accuracy. Protect the install boundary first.

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: How do you know if package security controls are actually working?

A: Look for fewer unexpected publishes reaching build systems, lower rates of install-time outbound connections, and measurable reductions in secret exposure during pipeline execution. Strong controls should also produce clear denial events when packages attempt to fetch credentials, contact external endpoints, or install from unauthorised sources.

Q: Should organisations trust sandboxed AI coding workflows?

A: Only as a containment layer, not as a trust decision. Sandboxes can limit immediate blast radius, but they do not remove the risk that the same dependency choices, scripts, or artefacts will later be promoted into real repositories with real credentials. The safer approach is to validate dependencies and package provenance before promotion, not just after execution.

Technical breakdown

How agentic coding changes package trust

Agentic coding tools do more than autocomplete. They can create an execution environment, fetch dependencies, run install scripts, recover from errors, and return a finished artifact without a human ever reading the dependency tree. That matters because package trust used to be reinforced by visible workflow friction, such as pull requests, review comments, and manual package choice. Once an agent performs those steps autonomously, the trust decision becomes implicit. The real risk is not just bad code generation, but unvetted code execution through transitive dependencies and install-time hooks.

Practical implication: Move trust checks to package admission and install-time policy, not to later human code review.

Why slopsquatting works against AI-built software

Slopsquatting is the attack pattern where adversaries register or repurpose package names that an AI is likely to invent or select incorrectly. The mechanism depends on two weaknesses: hallucinated package names and the tendency of agents to choose whatever appears plausible or common. Once the agent resolves that name into a live package, the malicious code can execute during installation or subsequent runtime use. This is especially dangerous in ecosystems where install scripts run automatically and package names are only weakly governed by maintainers or registries.

Practical implication: Block unknown package names and require allowlisting for AI-generated dependency choices.

What install scripts and sandboxes do not solve

Sandboxing reduces blast radius, but it does not remove trust. If the agent’s output is later promoted into a real repository, the same dependency choices and execution logic can cross from the sandbox into production workflows, often with credentials and network access intact. Install scripts are the critical moment because they can fetch second-stage payloads, hide process creation, and persist across operating systems. The problem is therefore control timing, not just execution environment. A safer model treats install-time behaviour as something to be verified before execution, not observed after compromise.

Practical implication: Make install scripts opt-in and verify dependency provenance before any package is allowed to execute.

Threat narrative

Attacker objective: The attacker aims to get malicious code installed through AI-assisted workflows so it can persist, steal sensitive data, and reach downstream software environments.

1. Entry occurs when an AI coding agent selects or invents a package name and installs third-party code on behalf of a user.
2. Credential and execution abuse follow when the package’s install script runs automatically and launches a hidden second-stage payload.
3. Impact arrives when the malicious package persists, harvests wallet or other sensitive browser data, and ships code into real repositories or environments.

Breaches seen in the wild

• Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted coding has turned package selection into a delegated trust decision. The security issue is no longer whether developers can read every diff, because in many workflows they never see the dependency choice at all. That makes package admission a governance control, not a developer preference, and it should be treated with the same seriousness as privileged access.

Slopsquatting is a control-gap problem, not just a malware problem. Attackers are exploiting the gap between what an AI might name and what a human would have reviewed before install. The practical lesson is that dependency trust now needs policy enforcement at the point of resolution, especially where install scripts can execute automatically.

Non-human software actors now need identity and privilege boundaries. An AI coding agent that can fetch packages, run code, and commit output is acting with delegated authority, even if it is not autonomous in the full sense. That makes this an NHI governance issue as much as a software supply-chain issue, because the agent’s permissions, package access, and execution scope must be bounded explicitly.

Sandboxing is useful, but it is not a trust model. Isolated execution can reduce blast radius, yet it does not prevent malicious dependencies from crossing into real repositories once the output is accepted. The better model is control at the install boundary, where provenance, allowlisting, and execution rules can stop risky packages before they ever run.

Package trust is becoming a new software security primitive. Teams that rely on AI coding need to reframe dependency handling as a high-risk decision point, not a background build task. That means governance over package admission, provenance, and automated execution belongs in the same conversation as code generation itself.

What this signals

Package admission is becoming the new security boundary for AI-assisted development. The old assumption was that code review would catch dangerous dependencies before they mattered. That assumption fails when an agent can select and execute packages faster than a human can inspect them, so the control point has to move to resolution and install time.

Non-human software actors need governance over their delegated tool use. An AI coding agent that can reach package registries is not just a productivity feature, it is a governed identity with bounded authority. Teams should define what it may install, when install hooks may run, and which outputs can leave the sandbox.

Slopsquatting raises the value of package provenance controls. The best defence is not to inspect every generated line, but to ensure that dependency names, maintainers, and installation behaviour are validated before code is allowed to execute in a build or developer environment. That is where trust now fails.

For practitioners

• Enforce dependency allowlisting for agent-generated code Treat packages selected by AI coding tools as untrusted until they pass a controlled admission policy. Restrict installation to approved registries and known-good package names, especially where install scripts are enabled.
• Disable automatic install-script execution by default Require explicit approval before any package install hook runs, because the malicious payload often appears at install time rather than in source code. This reduces the chance that a look-alike package can execute a second stage unnoticed.
• Separate sandbox output from production promotion Do not treat a successful sandbox run as a trust decision. Revalidate the dependency tree, package provenance, and execution behaviour before code or artefacts move into real repositories or environments.
• Monitor for hallucinated package names Add review and detection steps for package names that do not map cleanly to established maintainers, usage history, or internal allowlists. Slopsquatting depends on plausible but incorrect naming, so name validation belongs in the pipeline.

Key takeaways

• AI-written code shifts software trust away from human code review and toward package admission controls.
• Slopsquatting exploits plausible package names and automatic installation to turn AI coding mistakes into supply chain compromise.
• The most effective control is to verify dependency provenance and block risky install-time behaviour before execution.

Key terms

• Agentic Coding Workflow: An agentic coding workflow is a development process where an AI system can generate code, choose tools, and trigger actions such as package installation. The security issue is delegated authority, because the agent may inherit permissions and secrets that a human would normally review.
• 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.
• Package Admission: Package admission is the decision point where tooling or policy determines whether a dependency is allowed into a build or deployment workflow. In mature programmes, this is where trust is enforced, exceptions are recorded, and automation is constrained by policy.
• 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.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern delegated access, machine identities, and trust boundaries across modern environments.