TL;DR: Put the control where the command runs, not inside the AI product. Settings in your AI tenant stop working the second someone copies a command out of the chat and pastes it into PowerShell. What works is an approved internal repository, plus rules at the network exit and on the laptop itself.
PowerShell, launched by Claude.exe. That's what a manufacturing security team found in their process tree after unvetted software started landing on laptops.
Sometimes it was bash.exe instead. Sometimes the agent ran a shell script that then called PowerShell. The shape held either way. Somebody asked an AI tool how to solve a problem and ran the command it gave back.
The part I keep chewing on is that almost none of it went through a package manager. Most of it was a plain web address. A release archive or a raw script pulled straight off public GitHub.
That call was published as an IANS Ask-an-Expert summary on September 11, 2026, titled "Securing AI-Driven Software Installs With Golden Repos." The client was a manufacturing company with a security team over 50 people and revenue above $10 billion. Their own phrase for GitHub was the wild wild west.
Why doesn't AI tenant governance stop an unsafe install?
It doesn't stop it because the command leaves the product. Whatever you set inside a corporate AI tenant governs what happens inside that tenant. The second a person copies text out of a chat window and pastes it into a terminal, your AI policy is a bystander.
So don't spend your first month writing AI usage rules and calling that the control. That's the shape of governance that exists while enforcement doesn't. Write the rules, then go put real enforcement where the command actually executes.
This is the whole reason the answer lives on the laptop and at the network exit. Two places, both of which you already own. The laptop is where the install happens. The network exit, the point where traffic leaves your environment for the internet, is where the download crosses.
One detail from that call stuck with me. The team said AI-generated PowerShell looks very different from what a human would type. That's a detection signal, and it's worth having. It's also an after-the-fact signal. It tells you something already ran.
What is a golden repository, and how do you build one?
A golden repository is one internal source of software your company has looked at and approved. Endpoints and build systems pull from it by default. They don't pull from the open internet.
The build is four steps, and the order is the whole trick.
Pull into a staging area. A tool like Artifactory reaches out to the internet and lands the artifact somewhere isolated first. Nothing goes straight to a laptop.
Scan and approve it there. This is where software composition analysis earns its keep. Software composition analysis is the scan that tells you what a package is actually made of. JFrog Xray, Endor Labs, Snyk, and Black Duck all came up as options on that call. What you're checking is dependencies, known vulnerabilities, licensing, and where the thing came from.
Publish the approved copy internally. Now it's in a repository that never faces the public internet.
Point everything at it. Endpoints and CI/CD pipelines default to the internal source. Not as a suggestion. As configuration.
Then add the part most teams skip. Build a small intake process for new package requests, with a published turnaround time and a required business reason. If getting a new package approved takes three weeks and four approvals, people will route around you, and they'll be right to.
I learned that one at home, not on a client call. I run four agents in my lab on a dedicated Mac Studio. I locked Forge, the coding agent, into a tight sandbox, and then gave it a real build job. Forge couldn't install the packages it needed. The job failed with no alert for two hours before I noticed. To get the work done, the workaround was running Forge outside the sandbox.
That's shadow IT, done by me, to myself, in my own lab. I rebuilt it with a curated allowlist. Forge installs from the list with no friction now, and anything off the list needs a human. The security stopped being the reason to bypass the security.
Do package controls stop raw GitHub downloads?
No, and this is the distinction that decides whether your money is well spent. Package repository and package analysis tools control package manager traffic. They watch npm and pip and NuGet. They do not see a PowerShell command pulling a zip file off a GitHub release page, because that traffic never touches the package ecosystem.
So split your control plan in two. Package manager activity goes through the golden repository. Raw web address downloads need a different answer entirely.
That manufacturing team had mostly the second kind. They also couldn't narrow the sources, because their engineers legitimately pull from hundreds of different GitHub projects. Their own word for the blocking they'd been doing was whack-a-mole. And the honest constraint they named: you can't block all of GitHub.
Which means the answer has to be systemic rather than a list. You don't win a list war against the public internet.
What controls actually stop a raw download?
Two, working together. Web gateway rules that target download paths and file types rather than whole domains. Plus application control on the endpoint that stops anything from executing out of folders a user can write to.
Set both, because either one alone leaks. Gateway rules miss what's already local. Endpoint rules miss nothing, but they're noisy to tune, so you want less arriving in the first place.
Here's where it gets organizationally hard, and the call showed this plainly. That team's outbound traffic runs through a proxy owned by a different team. They can block a whole domain through their own playbook. Blocking a specific path inside a domain takes a ticket and several approvals. So GitHub traffic just passes.
That's not a technology problem. That's a control you nominally have and functionally don't.
If you're standing up secure service edge tooling, and that team said theirs was in progress, this gets easier. Tools like Zscaler or Netskope let you write rules tied to identity rather than to a domain list. That's how you stop running the environment by exception.
While you're in there, lock down GitHub itself. Repository visibility and token usage are both governable and both usually aren't. And write down every exception you grant, with the person, the purpose, the credential, and the expiration date. An exception with no expiration date is just a permission you forgot about.
Can you use the same approach for NuGet and PowerShell Gallery?
Yes. The principle carries over exactly, and you should consolidate into one internal repository rather than running several. Artifactory can hold multiple artifact types, so a second ecosystem doesn't mean a second platform.
The implementation details do change per ecosystem, and one specific trap is worth naming. Some tools pull downloads on their own. VS Code extensions do it. PowerShell Gallery modules do it. If you block the path without reconfiguring the tool, you've broken somebody's workday and earned yourself an angry ticket queue.
The fix is centralized endpoint configuration. Group Policy, or whatever manages your fleet settings, pointed at the approved internal source. Roll it to a small pilot group first and watch what breaks.
This is as much culture as tooling. The goal is a safe path that's easier than the unsafe one, so that exceptions stay rare instead of becoming how the place runs.
Why is this suddenly everyone's problem?
Because the population of people running install commands got much larger, very fast. Every company is a software company now. Your accountant, HR, legal, and procurement people are developers, whether or not anyone gave them the title.
That's my read, and the call supported it. AI didn't create informal delivery or citizen development. It poured gasoline on both. Software shows up in production and nobody was told, which raises the same question as who approves the code an AI agent wrote.
The client's own line about a user running an AI-suggested command was that they may not know what it does. That's not carelessness. It's a person solving a problem with the tool they were handed, in an environment where the safe path was slower.
What can you do in the next week?
Look at your process tree. Find what's launching PowerShell and bash on developer machines. If an AI tool is the parent, you now know the scale of this.
Ask which downloads are package manager traffic and which are raw web addresses. The answer decides where your budget goes. Most teams guess wrong.
Find out who owns your proxy and what a path-level block actually costs. If it's a ticket and four approvals, that control isn't real and you should plan around it.
Stand up one staging repository. Pick your single busiest ecosystem and do that one. Don't design for all of them first.
Write the exception register. Person, purpose, credential, expiration. One spreadsheet beats nothing, and you'll want the history.
Time your own approval path. If a developer needs a new package today, how long does it take. That number predicts your bypass rate better than any policy document.
Key takeaways:
Governance set inside an AI tenant stops at the copy button. Enforcement has to live on the endpoint and at the network exit, where the command runs and the download crosses.
Most AI-driven installs in this case weren't package manager traffic. They were raw web address downloads of release archives and scripts, which package analysis tools don't see.
A golden repository works in four steps: stage from the internet, scan and approve in isolation, publish internally, then point endpoints and CI/CD at it by default.
Raw downloads need web gateway rules on paths and file types, paired with endpoint application control blocking execution from user-writable folders.
The same internal-source model extends to NuGet and PowerShell Gallery, but tools that auto-download must be reconfigured through managed endpoint settings or you'll break real work.
An approval path slower than a few days guarantees bypass, which is why intake turnaround is a security control and not an administrative detail.
Frequently asked questions
Can't we just block GitHub?
Not realistically, and the manufacturing team on this call said so directly. Their engineers pull from a wide set of projects, and the sources can't be narrowed to a short list. What you can do is block specific download paths and file types while leaving the site usable, then make the internal repository the faster option.
Does EDR catch AI-generated install commands?
Sometimes, depending on the command and what gets installed. That team saw their endpoint tool fire on some of it, partly because AI-written PowerShell looks different from human-typed PowerShell. Treat that as detection, not prevention. It tells you something already executed.
What about the AI product's own admin controls?
Use them. Coding agents running in a terminal or an IDE often have administrative settings and hooks, depending on your licensing and admin setup, and they're worth turning on. They supplement endpoint and egress enforcement rather than replacing it, because copy and paste into a terminal bypasses the product completely.
How is this different from normal software supply chain security?
The mechanics are the same and the population changed. Supply chain controls were built assuming developers behaved like developers, pulling through package managers into build pipelines. Now a procurement analyst with an AI assistant is pulling a script off a public repository onto a corporate laptop, outside any pipeline your controls watch.
Where does Zero Trust fit here?
Zero Trust is the foundation this sits on. Verify every request and grant the least access needed. Assume something inside is already compromised. The golden repository is that thinking applied to software artifacts, where nothing gets trusted because of where it came from. Agents need one more check on top of that foundation, and limiting an agent's blast radius is how you decide how much it gets to do on its own.
Do we need software composition analysis if we already run SAST and DAST?
Yes, because they answer different questions. Static and dynamic testing examine code you wrote. Software composition analysis examines code you pulled in, which is most of what an AI-suggested install brings with it. Decide where the other two fit based on what artifact types you plan to approve.
I spent years telling people the secure path has to be the easy path. Then I built a sandbox so tight my own coding agent couldn't work, and I bypassed it myself inside a day.