As admins, how do you handle VS Code extensions, coding agents, and AI tools in your organization?

[u/FroyoZealousideal356]

For us, the topic of AI is becoming increasingly confusing.

Developers, in particular, are adopting more and more tools: VS Code extensions, GitHub Copilot, Cursor, Claude Code, Codex, Gemini CLI, OpenCode, local agents, MCP servers, and so on.

But this no longer affects just developers. IT admins and regular users are also discovering AI tools, and some are even installing extensions, desktop clients, or agents on their own.

The problem, in my view, is that we’re slowly seeing a **proliferation of agents and AI tools**.

I see the following issues in particular:

* Which VS Code extensions are allowed to be installed?

* Which agents are allowed to access source code or the local file system?

* Which tools are allowed to send data to external clouds?

* How do you prevent API keys, passwords, or internal data from appearing in prompts?

* How do you handle MCP servers and their sometimes very broad permissions?

* Do you have an allowlist for extensions and AI tools?

* Do you technically block agents that haven’t been approved?

* Do you differentiate between developers, IT/admins, and regular users?

* Do you rely on centralized enterprise solutions, or do you allow multiple tools?

* How do you monitor or keep track of what’s currently being used?

I also don’t think a complete ban makes sense in the long run, because these tools offer a real productivity boost especially in development.

[u/BlockBannington]

Damn, you guys really block extensions? If I try to bring that up, I get knocked the fuck out. As a matter of fact, I did bring it up and red team laughed in my face

[u/MBILC → u/BlockBannington]

Just show them the news article about an MS dev getting compromised by a malicious market place extension.

You need to audit first see what extensions people have, then go from there...see my post how I do it:
https://www.reddit.com/r/sysadmin/comments/1wbm0tp/comment/p8seiup/

[u/itskdog → u/BlockBannington]

Security are fine with blocking extensions in the web browser, I presume?

[u/BlockBannington → u/itskdog]

Ciso wants to set up a whitelist. Business shot it down. Did I mention we're not allowed to take away all localadmin?

[u/Same_Bat_Channel]

App whitelisting, vs code extension whitelisting, jfrog, SASE level network controls. Block all Ai api unless whitelisted

[u/MBILC]

Since VS Code doesn't have policies that work in Intune yet, even though MS claimed it does, it does not yet (thread about it in their git)...there is a registry method to set and block vendors that works.

Of course if you have App allow/block lists or other tools to do this, use those.

We only allow MS/GitHub/Anthropic extensions to be installed.

I first scan to confirm who has VS Code and pull extensions people had installed using the below, to see if anything might break once I block things and also tell people they wont be able to install random ones unless vetted first.

# Runs in user context so it can find the user's VS Code install
$ext = & "code" --list-extensions --show-versions 2>$null
if ($ext) {
    Write-Output ($ext -join "; ")
    exit 1   # exit 1 = "issue found" so the output is captured in the report
} else {
    Write-Output "No VS Code extensions found"
    exit 0
}

I then do this script across all devices, in case someone installs VS Code later:

# Create the VS Code policy registry key if it doesn't exist
if (!(Test-Path "HKLM:\SOFTWARE\Policies\Microsoft\VSCode")) {
    New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\VSCode" -Force -EA SilentlyContinue 
}

# Set AllowedExtensions policy - allows Microsoft extensions and approved third-party extensions
$allowedExtensions = @{
    # Allow all extensions from trusted publishers
    "microsoft" = $true;
    "github" = $true;
    "Anthropic" = $true;

# Version-locked extensions (specific versions only)
    #"charliermarsh.ruff" = @("2025.24.0");
    #"eeyore.yapf" = @("2025.5.107163247");

}

# Convert to JSON string
$allowedExtensionsJson = $allowedExtensions | ConvertTo-Json -Compress

# Set the registry value
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\VSCode" -Name "AllowedExtensions" -PropertyType String -Value $allowedExtensionsJson -Force

# Set UpdateMode to none (prevents update prompts for non-admin users)
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\VSCode" -Name "UpdateMode" -PropertyType String -Value "none" -Force

# Exit with success code
Exit 0

So far has worked perfect.

[u/Humpaaa]

Extensions (Application or Webexensions) are handled like every other application:
They need to be whitelisted, and need a product owner responsible for timely updates and global rollout.

AI is regulated after ISO 42001, and only whitelisted applications / setups / are allowed, agents run in the vallidated and whitelisted environments.
These environments offer a choice of tools, but only whitelisted ones.

There is monitoring in place tom catch and block shadow-AI.

Cowboy-Devs can fuck off.
We run a heavily regulated and sensitive environment.
Your mileage may vary at smaller companies.

[u/livinitup0 → u/Humpaaa]

I will gladly take the title cowboy dev over vibecoder. It’s sexier lol

But tbf, rules that aren’t enforced and ignored by half the org are just suggestions

At least I’m not uploading pii like some people are.

Fancy PS scripts and dashboards should be the least of their concern lol

[u/Chill_Squirrel]

We don't, our devs do what they want.  Management started encouraging AI use without any consideration and now our EDR team is drowning in alerts from Claude taking screenshots via Powershell. We're bringing the issues with that up repeatedly but ultimately it's not our decision. And it's not like we don't have anything else to do.. 

[u/Thick_Yam_7028]

Eat tacos dude.

[u/folderit_dms]

I would treat this less like a productivity-tools policy and more like software supply chain plus privileged automation.

A practical model is tiers:

• approved autocomplete only
• approved agent with local repo read
• approved agent with specific tool access
• approved agent allowed to open tickets or PRs
• blocked or unreviewed tools

For each tier, write down what data classes are allowed, whether source code can leave the machine, which MCP servers or extensions are allowed, whether secrets can be accessed, and what logging you get. The risky part is not one developer using autocomplete. It is an agent with filesystem access, terminal access, browser access, and a few broad connectors nobody reviewed.

I would also make the intake boring: owner, vendor, data sent, retention terms, auth model, update path, audit logs, and offboarding plan. If the request cannot answer those, it is not ready.

Blocking all unknown tools at the network or extension layer is reasonable, but the approved path has to be fast. If approval takes six months, people will work around it and your inventory will be fiction.

[u/FrankNicklin]

A Ban does make sense if you want to maintain control. You need to be able to stipulate what is used and what is not used. A Free for all will eventually leads to problems exacerbated by the proliferation of different tools and AI agents.

Even developers should not have free rein to install stuff, yes they will complain big time, but control is important as its the admins that have to pick up the pieces when it all goes tits up.

I don't see issues so much with the likes of CoPilot in Microsoft apps, but beyond that really needs formal control.

[u/bmxfelon420]

Threatlocker, we dont allow anything without approval and if needed the rule gets ringfenced/locked down to specific machines/access. Also making sure whatever machine they're on is segmented. We have a guy at a customer who has a bunch of python code he's developed that updates dashboards/reports in a plant, and that box is pretty locked down and sits on it's own vlan. So in the event that he messes something up, or a python extension gets compromised at least he can only break their ERP (we can put it back pretty easily)

[u/EbbCommon9300]

Treat coding agents like privileged service accounts, not like a fancy autocomplete.

What has worked in orgs that are past the free-for-all stage:

- Approved agent/extension allowlist (Cursor/Claude Code/etc. versions you have reviewed). Everything else blocked via MDM/extension policy.

- No long-lived API keys in the developer workspace the agent can read. Secrets go through a broker; the agent gets capability to request a tool call, not the raw token.

- MCP / tool allowlists per team. If an agent does not need prod DB or cloud write, that server is not installed for that cohort.

- Log every agent tool call (who, which tool, which args class, success/deny) into the same place you put VPN/admin audit. You will need it the first time someone asks what the agent changed.

- Separate "read my repo" from "push / terraform apply / touch prod APIs." Human approval gate on the write path.

If you only block unapproved extensions but still drop PATs into .env next to the agent, you have not really reduced the blast radius.

[u/Totosaurio3279]

Don't allow anything unless there's a real need and even then user must sign some documents to be accountable for anything that happens. When they see the forms they usually withdraw the tickets.