> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Local Agent Controls

> Configure Devin Desktop and Devin CLI settings across your enterprise with a root-level baseline and per-organization overrides.

Enterprise admins configure how members can use the local agents — [Devin Desktop](/desktop/devin-local) and [Devin CLI](/cli/enterprise/team-settings) — through a two-level system:

* **Root-level configuration** sets the baseline that applies to every organization in your enterprise.
* **Organization-level overrides** let you tailor individual controls for a specific organization without affecting the rest.

Both levels expose the same set of controls (features, models, permissions & security, MCP/ACP, codebase intelligence, sharing, and compliance). This page explains how the two levels interact.

<Note>
  These controls govern the local agents that run on your members' machines. They sit above any user- or project-level configuration a member sets locally — enterprise-enforced rules always take precedence. See [CLI team settings](/cli/enterprise/team-settings) for the individual settings and their meanings.
</Note>

## Root-level configuration

The root-level configuration is your enterprise-wide baseline. Every organization in the enterprise inherits these values unless an organization explicitly overrides a specific control.

Manage the root-level configuration from the enterprise settings:

* **Settings → Enterprise → Devin Desktop**

Set your enterprise-wide defaults here first. Anything you configure at this level becomes the effective value for all organizations that haven't overridden it.

## Organization-level overrides

<Warning>
  Applying organization-specific overrides requires attributing local agent billing to specific sub-organizations. **Contact your account team to enable this** before you rely on org-level overrides.
</Warning>

Within any organization, admins can open the same settings page and override individual controls for that organization only. On the org-level page, each control shows the value it currently inherits from the root, greyed out and non-editable, alongside an **Override** action.

<Steps>
  <Step title="Open the organization's settings">
    Navigate to the organization's **Devin Desktop** settings page. Controls that are inherited from the root are displayed but not editable.
  </Step>

  <Step title="Override a control">
    Click **Override** on the control you want to change. The control becomes editable and its value is now set at the organization level.
  </Step>

  <Step title="Reset to inherit">
    Click **Reset** on an overridden control to clear the override. The control returns to inheriting the current root-level value.
  </Step>
</Steps>

### Overrides are a pure replacement — lists are not merged

An organization-level override **completely replaces** the root-level value for that control. This is especially important for controls that hold lists, such as:

* Allowed models
* MCP servers and allowlisted MCP servers
* MCP registry URLs
* Permission rules (`allow` / `ask` / `deny`)
* Command allow/deny lists
* Sandbox domain allowlists and denylists

When you override one of these list controls, the organization's list is used **as-is** — it is *not* unioned, appended to, or otherwise combined with the root-level list. Whatever you set at the organization level is the entire effective list.

<Warning>
  Because lists are replaced rather than merged, an organization-level override does **not** inherit any entries from the root list. If you want the root entries to remain in effect for that organization, include them explicitly in the override.
</Warning>

For example, if the root allows MCP servers `A` and `B`, and an organization overrides the allowed MCP servers with just `C`, then members in that organization can use only `C` — not `A` or `B`.

### Each control is independent

Overrides are applied per control. Overriding one control has no effect on any other control:

* Controls you override take their value from the organization level.
* Every control you don't override continues to inherit from the root-level configuration.

This lets you diverge from the enterprise baseline on exactly the controls an organization needs, while everything else stays in sync with the root. If you later change a root-level value, that change flows through to every organization that hasn't overridden that particular control.

### Reset to inherit

Any override can be cleared with **Reset**. Resetting a control removes the organization-level value and returns that control to inheriting from the root — as if it had never been overridden. Resetting is scoped to the single control you reset; other overrides on the same organization are unaffected.

## When changes take effect

Control changes are not applied instantly. Both root-level and organization-level values are cached, so allow **up to 15 minutes** for an update to reach members' clients.

## Which organization's controls apply to a user

An enterprise user's organization controls are configured based on their **primary billing org**.

The primary billing org is the same organization a user's local agent usage is billed to. It is resolved in this order:

1. **Explicit assignment** — an administrator assigns the user a billing organization.
2. **Automatic resolution** — otherwise, the first organization the user can access (through direct membership or an identity provider group) is used.

In practice, a user gets the root-level configuration plus whatever overrides their primary billing org has set. Two users in the same enterprise can therefore see different effective controls if their primary billing orgs differ or override different settings.

<Tip>
  If you rely on organization-specific controls, we recommend **explicitly assigning a primary billing org to each user** rather than depending on automatic resolution. Explicit assignment makes it deterministic which organization's overrides apply to each user.
</Tip>

## Further reading

* [Devin CLI team settings](/cli/enterprise/team-settings) — the individual controls and what they do
* [Devin Local agent](/desktop/devin-local) — the local agent in Devin Desktop
* [Permissions](/cli/reference/permissions) — permission rule syntax used by the permission controls
* [Configuration](/cli/reference/configuration/config-file) — how local (user/project) configuration relates to enforced settings