AI adoption is expanding beyond developers. People are installing VS Code extensions, coding assistants, desktop clients, command-line agents, local models, and MCP servers, sometimes without IT approval. That creates questions around source-code access, filesystem and terminal permissions, cloud data transfers, exposed secrets, broad MCP capabilities, and visibility into what is actually being used. How are you handling this in your organization? Do you maintain allowlists, block unapproved tools, separate policies for developers and regular users, use centralized enterprise platforms, or permit multiple approved options? I do not think an outright ban is practical long term, since these tools can provide a real productivity benefit, but a completely unmanaged collection of agents seems risky.
5 Answers
A tiered approval model works better than treating every AI tool the same. For example: autocomplete-only tools, agents with repository read access, agents with specific tool access, and agents that can create pull requests or modify systems. Each tier should define what data may leave the device, whether secrets are accessible, which extensions and MCP servers are approved, and what logging is available. The intake process should cover ownership, vendor security, retention, authentication, updates, audit logs, and offboarding. Blocking unknown tools is reasonable, but approvals need to move quickly or people will work around them.
Network and endpoint controls can provide useful defense in depth. Application allowlisting, extension policies, endpoint detection, and outbound controls can block unknown AI APIs while permitting approved services. High-risk machines should be segmented, especially when an agent runs scripts or interacts with operational systems. Limiting an agent to a dedicated workstation or VLAN can keep a compromised extension or script from spreading beyond the system it needs to manage.
Some organizations simply allow developers to choose their own tools, often because management encourages AI adoption without defining guardrails. That tends to create a flood of alerts and makes it difficult to know what agents are doing, especially when they use shells, screenshots, or local files. At the other extreme, banning everything can push users toward unapproved workarounds. A formal policy with a fast approval route, clear accountability, and different controls for autocomplete, repository access, and privileged changes is a more sustainable compromise.
Coding agents should be treated more like privileged automation or service accounts than like enhanced autocomplete. Use an allowlist of reviewed tools and versions, restrict MCP servers by team, and do not give agents access to production databases or cloud write operations unless there is a clear need. Long-lived API keys should not sit in files the agent can read; use a secrets broker or short-lived capabilities instead. Log agent tool calls and put a human approval step in front of pushes, infrastructure changes, and production actions.
We handle extensions like any other software: they need to be approved, have a responsible owner, and follow a patching and rollout process. For VS Code, we inventory installed extensions first, then enforce an allowlist through endpoint policy. In our case, only extensions from selected trusted publishers are permitted, with specific versions used where necessary. The same principle applies to AI clients and agents: approved environments and configurations only, with monitoring intended to identify shadow AI use.
Exactly. Rules that nobody can follow or get approved in a reasonable time become suggestions. The approved route has to be easier than quietly installing another tool, while still keeping sensitive data and production access behind stronger controls.