GitHub added an enterprise setting this week that looks like the kind of thing most developers will never read about unless it breaks their editor.
Enterprise managed settings now support strictKnownMarketplaces for VS Code and GitHub Copilot CLI. In plain English: an organization can restrict which extension and plugin marketplaces are known and allowed inside the developer tools people actually use.
That sounds like desktop management.
I think it is more interesting than that.
If coding agents can discover tools, install plugins, call commands, read repositories, modify files, and run workflows from the IDE or terminal, then plugin marketplace policy is no longer a minor preference. It is part of the runtime boundary.
The agent does not only need permission to think.
It needs permission to reach for tools.
And the place where those tools come from is now a security surface.
the tool catalog moved closer to the developer
For a long time, extension marketplaces felt like productivity infrastructure. You installed a formatter, a theme, a language server, a test explorer, a Docker helper, a cloud plugin, a database browser, maybe three things you forgot existed.
Some companies cared a lot. Many mostly hoped the endpoint security product would notice anything truly bad.
That world was already risky, but the blast radius was usually framed around the human developer. A plugin could read files, run code, exfiltrate data, or weaken the local environment. Bad, but familiar.
Agents change the framing.
An AI coding assistant sitting in the IDE or CLI may use plugins as capabilities. It may call into developer tooling, use installed extensions as context, or depend on local integrations to perform work. Even when the agent itself does not directly install anything, the available tool environment shapes what it can do.
So the question stops being "which extensions are developers allowed to install?"
It becomes "which tool supply chains are allowed to become part of our automated development loop?"
That is a much better question.
It is also a harder one.
agents make local tools feel like production dependencies
The uncomfortable thing about developer machines is that they are not production, except when they are.
They hold source code. They hold credentials. They build artifacts. They run tests. They open pull requests. They connect to cloud accounts. They talk to package registries, issue trackers, observability systems, feature flag tools, and internal APIs.
We pretend there is a clean line between local development and production infrastructure because it helps us sleep.
Agents make the line messier.
If an agent running through a CLI can modify a repository, run commands, use credentials, and prepare deployable changes, then the local toolchain is part of the path to production. Not every tool has the same privilege, of course. A color theme is not a cloud deployment plugin. But the old mental model of "just an editor extension" is too casual.
The more work we delegate to agents, the more the surrounding tool environment matters.
What can the agent invoke? What plugins can it discover? What commands are on the path? Which extension marketplace is trusted? Which publisher is allowed? Which update channel did this capability come from? Who reviewed it?
These are not paranoid questions.
They are ordinary platform questions, arriving through a weird side door.
marketplaces are policy boundaries
The word "marketplace" sounds too commercial for what it has become.
For developer tools, a marketplace is a distribution channel, identity system, trust model, update mechanism, discovery surface, and social proof engine. It answers questions like:
- where did this tool come from?
- who published it?
- how is it updated?
- what metadata describes it?
- can it be removed or blocked?
- what does the organization allow by default?
Once agents start depending on those tools, the marketplace becomes a policy boundary.
That does not mean every company needs to lock everything down and make developers file a ticket to install syntax highlighting. That would be the fastest possible way to create a shadow toolchain.
But it does mean the default should be intentional.
An enterprise should know whether the IDE and CLI are allowed to use random public marketplaces, internal marketplaces, approved mirrors, or some mix of them. It should be able to separate personal experimentation from work repositories. It should be able to say that certain plugin sources are fine for hobby code and not fine for repositories containing customer data.
That is the point of controls like strictKnownMarketplaces.
They create a place to draw the line.
the agent supply chain is not only npm
When people talk about software supply chain security, we usually jump to packages, containers, SBOMs, signing, provenance, and CI/CD.
All of that still matters.
But agentic development adds another layer: the tools that influence how code gets written before it becomes a package or a container.
A coding agent may use repository instructions, MCP servers, editor plugins, CLI extensions, browser automation, secret scanners, test runners, cloud CLIs, and whatever else the local environment exposes. Some of those tools are first-party. Some are open source. Some are internal. Some were installed two years ago by a developer who wanted a nicer diff view.
That is a messy inventory.
It is also the inventory agents will inherit.
This is why I find marketplace policy more compelling than it first looks. It is not a complete answer, but it is one of the first boring controls that acknowledges where agent capabilities actually live.
Not in a clean architecture diagram.
In the developer's editor, terminal, plugin list, and path.
governance has to happen before execution
There is a bad version of agent governance where everything is reviewed after the fact.
The agent did something. The logs captured it. The audit trail exists. Someone can investigate later.
That is useful, but incomplete.
Some controls need to happen before the tool is available. If a plugin marketplace is not trusted for work repositories, the agent should not be able to route through tools from that marketplace and then leave a beautiful audit log explaining the mistake.
Pre-execution policy is not glamorous. It is mostly allowlists, identities, scopes, signatures, provenance, and boring admin settings.
Good.
That is what real platforms are made of.
The agent world has spent a lot of energy on prompting, reasoning, model choice, evals, context windows, and autonomy. Those are important. But the operational question is often simpler:
What can this thing touch?
Marketplace policy is one answer. Not the only answer, but a practical one.
developers still need room to work
There is a balance here.
If companies turn agent security into a frozen desktop image with no escape hatch, serious developers will work around it. They will use personal machines, side tools, local scripts, unapproved CLIs, and whatever gets the job done.
That is not security. That is denial with screenshots.
The better version is tiered.
For low-risk repositories, allow more experimentation. For sensitive repositories, restrict plugin sources. For production credentials, require stronger identity. For agents that can open pull requests or run deployment-adjacent commands, require approved tools. For internal marketplaces, make the approval process fast enough that people do not hate it.
The goal is not to remove curiosity from development.
The goal is to stop unknown tools from quietly becoming part of automated engineering workflows.
This is where platform teams can actually help. Provide a blessed marketplace. Mirror common extensions. Publish internal tools properly. Document what is allowed. Give agent workflows a known-good tool catalog. Make the secure path easier than the weird path.
That is much better than yelling at developers for installing things.
what i would check first
If I were responsible for this in an engineering organization, I would start with a very boring inventory.
Which IDEs and CLIs are used for work? Which extension marketplaces are enabled? Which plugins are common? Which plugins can read files, run commands, or reach external services? Which ones are required by official workflows? Which ones are abandoned? Which ones overlap with agent capabilities?
Then I would connect that inventory to repository risk.
The frontend toy app and the payments service should not have the same policy. A documentation repository and an infrastructure repository should not expose the same local capabilities to an agent. A contractor machine and a platform engineer's machine probably need different defaults.
Finally, I would make agent traces show tool provenance.
If an agent used a plugin, CLI extension, MCP server, or marketplace-provided capability, I want to know which one. I want version, publisher, source, and policy decision. Not because I enjoy paperwork. Because when something weird happens, "the agent ran a tool" is not enough detail.
Which tool?
From where?
Allowed by whom?
Under which policy?
Those questions should be answerable without forensic archaeology.
the punchline
GitHub's strictKnownMarketplaces support is not the kind of announcement that gets a big keynote moment.
That is exactly why I like it.
The future of coding agents will not be governed only by model settings and chat prompts. It will be governed by the dull surfaces where work actually happens: IDE settings, CLI policy, plugin marketplaces, identity, audit logs, repository permissions, and tool catalogs.
Agents make the developer environment more powerful.
That means the developer environment needs better boundaries.
Plugin marketplaces used to feel like a convenience layer around the editor. For agentic coding, they are becoming part of the execution contract.
If your agent can use tools, you need to care where those tools come from.
That is not bureaucracy.
That is supply chain security finally catching up with the way developers actually work.
references
To test my projects, I use Railway. If you want $20 USD to get started, use this link.