Your Policy Was Complete. Then Your Company Adopted AI.

Your Policy Was Complete. Then Your Company Adopted AI.

By Jacqueline Winter, CISO & CFO, ActiveState

Most organizations have a dependency governance policy. Somewhere inside it is an exception nobody signed off on. That exception is now material.

At some point in the last few years, most security organizations made a governance decision about open source dependencies. They documented approved packages. They built a review process. They required SBOMs for production systems. The decision was real, the documentation was produced, and the policy looked complete.

It is not complete. There is an exception built into nearly every one of these policies that nobody explicitly approved, because the policy was written before the exception existed.

The exception is AI-suggested code.

How the Gap Was Created Without Anyone Deciding

When developers adopted AI coding assistants, the governance question was not raised at the executive level. It was not raised at the security team level. It was absorbed into normal development workflow, one accepted suggestion at a time. The developer did not think of it as a sourcing decision. The security team did not update the policy. The CISO did not write an addendum. The CFO did not ask about the liability implications.

The result is a governance policy that covers what it was designed to cover, and silently does not cover the most rapidly growing intake channel in the organization.

This is not a technology failure. It is the pattern I have watched play out in financial controls, operational governance, and risk management across different industries and different decades: an intake channel changes faster than the policy governing it, nobody explicitly decides to carve out an exception, and the audit discovers the gap in the worst possible context.

What the Attack Patterns Are Telling the Board

The software supply chain attack campaigns that have targeted AI developer tool workflows are not demonstrating a sophisticated new threat. They are demonstrating that attackers have found the policy gap before most organizations have.

When a malicious package impersonates a legitimate AI development tool and distributes through a standard registry, it enters because the sourcing policy permits anything that can be pulled from a public registry. The policy did not intend to permit this. But it does not prohibit it, because AI-suggested packages were not a named intake category when the policy was written.

When credential-harvesting campaigns target developer publishing workflows, they are exploiting the same structural condition: a trusted channel with no governance provision for what enters through it under AI-assisted development conditions. The channel is trusted. The credential is valid. The audit trail looks clean until the postmortem.

This is the accountability problem. The breach did not require a perimeter failure. It required a governance gap that nobody had explicitly closed.

The Defensibility Question

In the current regulatory environment, the question a board, a regulator, or a litigant will ask after a security failure is not only "did you have a policy?" The question is "was the policy adequate for how your organization was actually operating?"

SEC cybersecurity disclosure requirements, EU CRA personal accountability provisions, and the evolving legal framework around executive liability have changed the standard. A policy that predates the organization's AI tooling adoption is not adequate for how the organization is currently operating. It documents what the governance posture was before the intake channel changed. That documentation may be worse than having no documentation, because it demonstrates that the organization had a governance framework and allowed a material gap to develop inside it without acknowledgment.

The gap between what is documented and what is true is the liability. Not the breach itself.

What a Complete Policy Actually Requires

Closing the gap does not require rebuilding a security program. It requires asking a specific question that most security programs have not asked: does the governance policy explicitly cover AI-suggested dependencies as a distinct intake category?

A complete policy for the current development environment addresses four specific conditions:

• Explicit coverage of AI-suggested packages as a named category, not as an implied subset of ‘all packages’
• An intake process that scales to the velocity at which AI tools suggest and developers accept packages, not the velocity of manual search-and-select
• A provenance record that can answer ‘who authorized this package and under what criteria’ for every component in production, including those introduced through AI-assisted workflows
• Remediation obligations that are contractual and time-bound, not aspirational

None of these are new security practices. They are the application of existing governance disciplines to a changed intake model. The organizations that have done this work have not built something new. They have closed the gap between what their policy says and what their development environment actually does.

The Conversation That Should Already Be Happening

The governance review cycle that covers financial controls, operational risk, and legal exposure should already include this question. It likely does not, because the person who schedules that review cycle does not think of open source dependency governance as a financial risk item.
It is. The cost of a breach that follows a documented governance gap, in remediation, regulatory penalty, reputational exposure, and the personal liability that the 2026 regulatory environment attaches to executive security decisions, is not an IT cost. It is a balance sheet event with attribution.
The AI exception in your dependency governance policy is not a technical oversight. It is an unacknowledged liability. The organizations that will have a defensible answer when they need one are the ones that closed the gap before an incident required them to explain why they had not.