An AI coding assistant allowlist should list approved assistants, the models they may call, editor extensions, MCP servers and agent features, each with an owner and a review date. Anything not listed is off by default. This keeps tool sprawl visible and gives you something concrete to enforce and audit.
Definition: allowlist versus blocklist
An allowlist names what is permitted and denies the rest. A blocklist names what is forbidden and permits the rest. For fast-moving AI tooling, a blocklist is always behind, because new tools and features appear weekly. Allowlists are more work up front and far easier to defend in an audit.
What belongs on the list
| Category | What to record | Example control |
|---|---|---|
| Assistants | Product, plan, account type | Company accounts only |
| Models | Which models may be selected | Admin model policy |
| Editor extensions | Publisher, version, permissions | Managed extension list |
| MCP servers | Server, owner, tools exposed | Approved server list, tool permissions |
| Agent features | Cloud agents, CLI tools, background runs | Feature policies per organization |
| Packages the tools may add | Registries and approved sources | Dependency policy at merge |
Vendors support part of this. GitHub documents administrator policies for Copilot features, agents and models, with enterprise policies set first and organizations deciding where allowed. It also warns that when a user has access through several organizations, the least restrictive policy usually applies, so check for people with multiple seats.
How to build the first version
- Inventory what is already in use. Survey developers and check extension and network data.
- Group tools by data they touch, using your data classes.
- Approve a small default set and put the rest through a request path.
- Record owner, purpose, data class and review date for every entry.
- Enforce through admin settings where available, and a periodic scan where not.
Keeping it alive
An allowlist rots when requests take weeks. Set a response target of a few working days, publish the list, and review it quarterly. Remove entries nobody uses. Watch who can change policy settings and use the audit log to track changes, which GitHub's documentation also recommends.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk through connecting a server and note the step where you decide what the client may reach.
Quick check
Do we need to allowlist models?
If different models have different terms or regions, yes. Otherwise a default set with a review is enough.
How often should we review the list?
Quarterly is a reasonable start, with an immediate review after any incident or major tool change.
Safeguard offers MCP Guardrail, agent identity and asset discovery to help you see and control which agents and servers are in use, plus a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
