AI coding tools have made it possible for almost anyone to build something. That's the upside everyone's talking about. The conversation usually stops there.

Most companies have a good handle on their production systems: what's running, who owns it, how it's reviewed. Far fewer have that same handle on the edges, the prototypes, the internal tools, the "quick automation" someone built over a weekend and quietly has running as production, from their laptop. AI has lowered the bar to build working software so far that the people doing it often aren't developers, don't report into an engineering org, and were never part of a security review to begin with.

Shadow IT and shadow production have always existed. What's new is how easy it's become to end up with shadow production AI, since most organizations are watching for the result to be delivered, not asking much about how it got done.

That's really a symptom of a bigger pattern: organizations focus on outputs and results, while paying too little attention to the increasingly complex chain of tools, packages, models, agents, and APIs that actually produce those results. Shadow AI is one version of that lack of visibility. Software and AI supply chain risk is another, and it's the one that became visible on August 4, when a compromised open-source npm package touched off a credential-stealing worm that ultimately poisoned more than 440 npm packages and over 2,000 individual package versions across the ecosystem. Qlik, a vendor Axis works closely with, was among those affected, and moved quickly to triage the issue once it was identified. The exposure was contained. The incident is still worth sitting with, though, as a reminder of how much modern software, and increasingly AI-assisted software, depends on a long chain of packages and trust that most people building with these tools never think about. 

None of this means open source is the problem. Using open-source packages is standard practice across the industry, including for the largest and most sophisticated software vendors, because it means not reinventing something that already exists. The issue isn't that these packages get used. It's how little visibility most organizations have into what's being pulled in, by whom, and under what review. Much of the software industry now runs on a "ship fast, ship often" approach, which is well suited to shipping features and fixing bugs quickly. It cuts the other way, though, when a vulnerability ships along with everything else and isn't caught before it's already out in the world.

If a vendor with established security practices like Qlik can get pulled into an event like this, it's worth asking what's sitting inside your own organization right now with far less oversight.

Where the Real Risk Actually Sits

It isn't "which AI coding tool should we adopt" or "should we allow this." That decision has already been made, by default, in most organizations. The question that actually matters is:

Is our company properly governing the usage of AI, and do we know who is developing, what they're developing, whether they're following best practices, and whether their code is leaving us exposed?

That's not a rhetorical question. It's worth asking plainly, in a leadership meeting, this week:

• What are we currently doing to protect ourselves against this kind of exposure?
• What did we actually do in the last 24 hours after news like this broke, and is there anything else that still needs to happen?

Most organizations will find the honest answer is "not much," and that's the point. The gap isn't a failure of any one team. It's a natural byproduct of how fast AI development tools spread, versus how slowly governance processes tend to catch up.

It's tempting to assume that a small, solo-built tool is low-stakes simply because only one person is using it. The August 4 incident is a useful reminder that this isn't how compromised code works. It harvested credentials and replicated itself automatically. It didn't matter whether one person or one thousand people were running it. The code was doing things nobody running it had any reason to expect.

Part of what makes this hard to catch is that most companies aren't doing much formal training on how to build with AI in the first place. People are largely learning as they go, whether on company time or in their own personal projects, and brought whatever habits they picked up back into work. If what they build works, they move on to the next thing. Happy and working does not mean safe and secure.

What AI Governance Looks Like in Practice

This doesn't require a full governance framework overnight. A few places to start:

Know who's building. Not just your engineering team. Anyone in the organization using an AI coding assistant to build something that touches company systems, data, or customers should be visible to someone. That doesn't mean locking it down. It means asking a simple question and expecting an answer: what have you built recently, and can we see it? It doesn't matter whether the person building it is a software engineer or someone in accounting who found a clever way to automate their own reporting.

Treat unfinished projects like they matter. A prototype or internal tool that never reaches production isn't automatically low-risk. A tool running in dev is still running. It's still pulling in dependencies, still executing code, and still worth a basic review before it's left unchecked. 

Set a default for how dependencies get pulled in. Whether that's pinning versions instead of using open ranges, delaying adoption of newly published packages, or simply avoiding tools that auto-install without review, small defaults reduce a lot of exposure without slowing teams down meaningfully.

Give people a place to ask. If someone building with AI tools has a question about whether something is safe, there should be an obvious answer for who to ask. Right now, in most organizations, there isn't one.

This Won't Be the Last Wake-Up Call

Events like this will keep happening. The specific package, vendor, or exploit will change, but the underlying pattern won't: AI has made building fast and easy, and governance hasn't caught up at the same pace. The organizations that get ahead of this won't be the ones with the most restrictive policies. They'll be the ones who simply started asking the right question before they had to.

Axis Group helps organizations bring structure to fast-moving data and AI initiatives, from governance and strategy through implementation. If your team is thinking through what AI governance should look like in practice, we'd welcome the conversation.