Editor extensions deserve a separate conversation, because they are a supply chain of their own with its own rules. Allowed publishers, signature verification and a delay before installing new versions are three mechanisms that together lower the risk of a short-lived malicious release. The logic is simple: such incidents usually last hours until the release is pulled, and an installation delay lets them pass by your machines without a single decision from the developer.

Underneath those mechanisms lies a different registry. Extensions come from Open VSX rather than from the Microsoft marketplace: not everything is there, and the same publisher.extension name can point to a different publisher and different code than in the familiar marketplace. Search and downloads do not go straight through but through a proxy of its own, marketplace.cursorapi.com, where an extension is run through automated malware and supply-chain analysis, and whatever fails review is blocked. For a few widely used extensions absent from Open VSX there are first-party Anysphere replacements. The consequence is simple: what you verify is the publisher, not the name, otherwise an allowlist approves a matching name instead of the code you expected.

Plugins have a dial of their own - installation modes and the team catalog. The difference between offering and mandating is not cosmetic here. A catalog with an approved set answers what may be installed but does not guarantee that what is needed has been installed: half the team may lack the thing you were counting on when you wrote the rules. A required mode, on the contrary, guarantees presence, and it is precisely what is needed for things the agent's behavior must depend on identically for everyone. Both modes are useful, but they answer different questions, and confusing them means building policy on an assumption about your colleagues' environment.

The main idea fits in one sentence: steering is not enforcement. A mandatory team rule can tell the model what to do, but it replaces neither the model allowlist, nor restrictions on external servers, nor the sandbox, nor an event handler. Policy must live in a mechanism that technically controls the resource in question rather than in text the model weighs alongside the rest of the context.

That mistake occurs more often than it seems and looks convincing. The rules say not to connect unapproved servers - so nobody will. In practice not all surfaces see the rule, it does not apply to some scenarios, its influence depends on the volume of context, and there is nothing to check compliance with after the fact: there was no refusal and no record was left. An administrator-level restriction, on the contrary, produces an observable refusal and a line in the log, that is, evidence you can present.

Hence the practical order of adoption. First an inventory: which models, servers, plugins and extensions are used today. Then an allowlist assembled from facts rather than from an ideal - it honestly includes what the team cannot work without. And only then tightening: whatever did not make the list is switched off on an announced schedule and with a clear exception path. The reverse order, forbidding first and finding out later, guarantees a stream of exceptions, policy circumvention and a reputation for a tool that gets in the way.

The engineering conclusion is simple: govern what you can observe and enforce with what technically controls the resource. Then policy becomes a property of the system rather than a statement of intent, and compliance is visible in logs rather than established by surveying the team on the eve of an audit.

The typical failures are predictable. Writing a requirement into rules instead of a restriction in a mechanism. Compiling an allowlist without an inventory of actual usage. Approving an external server and not restricting its tools and network. Leaving extensions outside the policy, treating them as part of the editor. And forbidding everything at once without leaving a clear exception path.