Skip to main content
Enterprise admins configure how members can use the local agents — Devin Desktop and Devin CLI — 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.
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 for the individual settings and their meanings.

​
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

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.
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.
1

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.
2

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.
3

Reset to inherit

Click Reset on an overridden control to clear the override. The control returns to inheriting the current root-level value.

​
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.
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.
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.

​
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.
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.

​
Further reading