> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/developer-machines/device-policy/policies.md). # Policies Policies are reusable rules that you bundle into profiles to control what is allowed on developer machines. Each policy targets one category. IDE extensions is the first supported category: an IDE extension policy targets one IDE and defines which extensions and versions developers can install. The **Policies** page under **Developer Machines** > **Device Policy** lists all policies with their mode, category, rule count, the number of profiles using them, and when they were last updated.
### Create a Policy Click **New policy** and complete the following sections.
#### Basics Give the policy a name (for example, "Approved VS Code extensions") and an optional description of what it controls and why. Then select the category (**IDE extensions**) and the IDE (**VS Code**). #### Mode Choose whether the listed extensions are the only ones allowed, or the ones blocked: * **Allow-list**: block everything except the listed extensions * **Block-list**: allow everything except the listed extensions #### Rules Rules define the extensions and versions the policy applies to. You can add rules in two ways. **Add rules from inventory or manually** Click **Add rules** to open the rule picker.
* **From inventory**: search the extensions Dev Machine Guard has already observed across your fleet, by name or publisher. Each entry shows the extension ID, the IDE, and the number of devices where it is installed, so you can build the policy from real usage. * **Add manually**: add an extension that has not been observed in your fleet yet. Enter the publisher (for example, `ms-python`) and optionally the extension ID (for example, `python`). Leave the extension ID empty to write a publisher-wide rule. Manual rules use their own version strategy setting: allow any version, stable releases only, or pin specific versions.
Before adding the selection, choose a **default version strategy**. It applies to every selected extension, and you can change individual rules afterwards: * **Allow any version**: any published version is permitted. * **Stable releases only**: pre-release and preview builds are rejected. * **Pin specific versions**: add the extensions first, then pin exact versions on each rule from the rules table. * **Allow everything from the publisher**: creates one publisher-wide rule per distinct publisher in the selection. You can also add an optional **comment**. It is recorded on every rule you add, for audits and reviews, and is never delivered to devices. **Import an existing configuration** Click **Import** to upload an existing configuration and turn its entries into rules. Supported formats are an `extensions.allowed` JSON file, a `.mobileconfig`, or a preferences plist, up to 5 MB. #### Rules Table Added rules appear in a table showing the publisher, extension, version constraint, and comment. You can change the version constraint per rule or remove rules individually.
### Compiled Preview While you build the policy, the **Compiled preview** panel shows the exact configuration that will be delivered to devices. For VS Code, this is the `extensions.allowed` policy format. For example, an allow-list policy compiles to: ```json { "*": false, "bradlc.vscode-tailwindcss": true, "github.vscode-github-actions": true, "ms-vscode-remote.remote-ssh": true, "ms-vscode-remote.remote-ssh-edit": true } ``` Use the copy button to copy the compiled configuration at any time. When you are done, click **Create policy**. To enforce the policy on devices, add it to a profile. See [Profiles](/developer-machines/device-policy/profiles.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.stepsecurity.io/developer-machines/device-policy/policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.