Your Open Source Policy Assumes a Human Picked the Package
Eric Gallagher
October 19, 2026
Share post:
Most enterprise open source policies rest on an assumption nobody wrote down: a developer chose the package. Someone searched a registry, compared two libraries, checked the license, and made a call the policy could later hold them to. Every approval step, exception path, and allow list in the policy hangs from that decision point.
AI coding assistants and agents removed it. A suggestion accepted with one keystroke, or an agent that installs whatever its task needs, adds open source dependencies to the build without anyone deciding to add them.
The policy still exists. The decision it was written to govern has disappeared.
Key takeaways
Open source policies assume a human chose each dependency, and AI coding assistants and agents now make that choice at machine speed.
Review, approval, and scanning still run as designed, for a decision rate that has changed.
When no one approves a dependency, accountability travels up the org chart to the executives who signed the policy.
The control that holds operates at the source, where every developer and agent inherits the same decision.
How an open source policy governs a decision
An open source policy is a set of rules about a choice. It names the licenses the company accepts, the registries developers may pull from, the review a new package needs, and the exception path for anything outside those lines. The rules are sound. They work through a person.
The developer is the first control point, because the developer decides what to import. The reviewer is the second, because the reviewer sees the change and can ask why. The scanner is the backstop, reporting what entered the build after the fact. Each layer assumes the one before it involved judgment.
The policy's real output is an answer. When an auditor asks why a component is in production, there is a ticket, a review, and a name.
That answer is what the board approved when it approved the policy, whether or not anyone described it that way.
Where the policy hits its ceiling
AI changed who chooses the dependency. Coding assistants suggest imports inline, and a developer can accept one in a keystroke without the research that manual selection used to involve. Agents go further: they resolve and install dependencies while completing a task, often with no one watching the step. One accepted suggestion brings an entire tree of transitive dependencies that nobody chose. Models also suggest packages that do not exist. Researchers documented this package hallucination across code-generating models in a study presented at USENIX Security 2025, and attackers register the hallucinated names so the next install pulls their code, a practice called slopsquatting.[1] The mechanism is covered in who governs the dependencies your AI assistant picks.
A careful developer at the keyboard changes none of it. The policy was built for a decision rate that no longer exists.
The ceiling is structural, and better tooling or a more mature team does not raise it. Add reviewers and the review queue grows with the code. Add scanners and they report faster on what already arrived. Both are useful. Both scale with people.
Review scales with headcount. Generation scales with compute.
Scanners keep doing their job here: they tell you what got in. The question the policy was built to answer is who decided it should. Why a scanner on its own no longer settles that question is laid out in "We Had a Scanner" Is Not a Defense Anymore.
Who owns a dependency no one approved?
When the decision point disappears, accountability moves with it, up to the last person who signed something. The developer accepted a suggestion. The reviewer saw a diff and a one-line manifest change. The agent ran unattended. The last signature on the chain is the policy itself, approved by the security leader and often reported to the board.
The fair counterargument is that AI-generated code still passes through pull request review, so a human still approves it. That holds for the code a reviewer reads. A dependency enters as one line in a manifest and brings a tree the reviewer never sees.
Security leaders already feel where the exposure lands. In Splunk's The CISO Report 2026, 78% of CISOs said they are concerned about their own liability for security incidents, up from 56% in the prior year's report.[2] The rules around them assume someone can say what is in the product and why. EU Cyber Resilience Act reporting obligations have applied since September 11, 2026: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a full notification within 72 hours, and a final report on an exploited vulnerability within 14 days of a corrective measure being available.[3] OWASP ranked Software Supply Chain Failures third in its 2025 Top 10.[4]
Each of those clocks starts with a record of what entered and who allowed it. A policy that governs a decision nobody made produces no such record. The cost lands in pieces, as rework, release delays, and audit findings spread across different budgets, which is why it stays an unmanaged liability on no ledger the board reviews. The same ownership problem runs through the business costs that follow faster AI delivery.
Within 12 months, auditors will start asking who approved the dependencies an agent pulled in.
In most enterprises, that question produces a pause. The pause is the governance gap.
What governing at the right layer requires
The decision point at the moment of selection is gone, and more review won't bring it back. The control has to move to the place every request passes through: the source.
Operating there requires three things. The organization decides, before anyone asks, which open source components it will accept. Every package request, from a developer or an agent, resolves against that decision. Scanning stays as the backstop, with less to find. Make the safe decision once, at the source, and every developer and agent inherits it.
This is the layer ActiveState works at. The ActiveState Curated Catalog is a private, vetted repository of open source components that ActiveState builds from source, and dependencies requested by AI coding assistants resolve from it. The request lands on a decision already made.
For engineering, the workflow stays the same. Developers and their agents keep the same package commands, and what comes back is already approved. Put control at the source and the speed AI delivered stays with the team. Every package that never enters is remediation work that never has to happen.
For the board, the line is short: say yes to AI at full speed, with a record that shows you took reasonable care.
Start with one question for your team this week: for the last dependency an agent added to production code, who approved it? If the answer takes a search through tickets and logs, you know which layer your policy runs at.
The policy states what should enter. The source decides what can.
That decision gets made before the request, or it never gets made. Right now, for most organizations, it never gets made.
Eric Gallagher is Principal Strategist, Open Source Governance, at ActiveState. He writes about how open source governance works, where it reaches its limits, and the decisions security leaders and boards need to make about it.
Sources
Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath, and Murtuza Jadliwala, "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs," 34th USENIX Security Symposium, 2025. https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen
Does an open source policy apply to dependencies added by AI coding assistants?
It applies on paper. Most policies govern a developer's choice of package, and an assistant or agent that adds a dependency skips that choice, so the approval step never runs. Closing the gap means applying the policy where packages come from, so every request from a developer or an agent resolves against the same approved set.
Who is accountable when an AI agent adds a vulnerable dependency?
In practice, the question moves to whoever owns the control model, usually the security leader who approved the open source policy. With no developer decision to point to, auditors and boards look to the executives who set the rules, which is why a defensible record of reasonable care matters before an incident.
What is slopsquatting?
Slopsquatting is an attack in which someone registers a package name that AI coding tools tend to hallucinate. When a developer accepts a suggestion for that name, the install pulls the attacker's package. Governing which packages can be installed at the source closes that path before any code runs.
Do scanners catch dependencies added by AI agents?
Scanners report what entered the build, and they remain the backstop. They identify a dependency after it arrives; the decision about which open source components can enter at all happens at the source, which leaves the scanner less to find.
What should a CISO ask the team first?
Ask who approved the last dependency an AI agent added to production code. If the answer takes a search through tickets and logs, the policy is describing a decision nobody is making.
.png)
.png)