Security Profiles

Security profiles let you define reusable bundles of security restrictions — network access, MCP access, git access, and GitHub CLI credentials — and apply them to Devin sessions across your organization. Instead of configuring restrictions session by session, admins create named profiles once and attach them at the level that makes sense: as an organization-wide default, on a specific automation, or on an individual session. Enterprises can additionally share profiles across every organization and enforce them as a hard floor that no one below can loosen.

​

Restrictions in a profile

A profile is a named set of restrictions. Each restriction is optional — a profile only constrains the settings it configures.

​

Network policy

A network policy is an allowlist of destinations the session’s machine is permitted to reach. All other outbound connections are blocked. Allowlist entries can be:

• Hostnames, with * wildcards (e.g. *.github.com, registry.npmjs.org). A * matches any sequence of characters, including dots.
• IPv4 / IPv6 CIDR ranges (e.g. 10.0.0.0/8).

The restriction applies to all network access from the session — shell commands, browsing, package installs, and scripts alike. Devin is aware when it’s running under a restricted network policy: it can see the current allowlist and, when it’s blocked by a missing destination, it will ask for access. Approving the request adds the destination for that session (subject to any mandatory envelope — see enforcement). Destinations required for Devin to function (such as the git proxy used to reach your connected repositories) are allowed automatically.

​

MCP access

By default, sessions can use any MCP server installed in your organization. A profile can restrict this with an allowlist of MCP servers — sessions governed by the profile can only use the listed servers.

​

Devin MCP access

Sessions also have access to Devin’s own management tools via the built-in Devin MCP — creating and messaging child sessions, editing knowledge and playbooks, managing schedules, and so on. A profile can restrict this surface with Devin MCP read-only: sessions governed by the profile can still read Devin resources (list sessions, look up knowledge, inspect playbooks) but cannot perform write operations like creating sessions or editing knowledge.

​

Git access level

Controls what the session can do with your connected repositories:

​

GitHub CLI token

Beyond the base git operations covered by the git access level, Devin’s machine can carry a GitHub CLI (gh) token that lets Devin use GitHub features directly through the GitHub API. A profile can remove the GitHub CLI token from the machine: sessions governed by the profile keep working with your repositories through Devin’s git integration, but cannot make direct GitHub API calls. A profile may only keep the token if it also grants Full git access and, when it sets a network policy, allows api.github.com. Both conditions are enforced when you save the profile.

​

Where profiles live

Profiles exist at two scopes:

• Organization profiles are created in Settings → Customization → Security profiles and are usable only within that organization.
• Enterprise profiles (enterprise accounts only) are created in Enterprise settings → Devin → Security profiles and are usable by every organization in the enterprise. Organizations can select an enterprise profile for their sessions, automations, or org default, but only enterprise admins can edit the profile itself.

Profile names must be unique within their scope. Each profile also carries an enforcement level that determines whether lower levels can override it.

​

What you can bind a profile to

A profile takes effect by being bound to a resource. Bindings form a hierarchy, from broadest to most specific:

1. Enterprise default — applies to new sessions in every organization in the enterprise.
2. Organization default — applies to new sessions in that organization.
3. Automations default — applies to sessions started by automations in that organization, overriding the organization default for those sessions. Set from the same security-profiles settings page.
4. Automation — applies to sessions started by that specific automation, overriding the automations default. Set from the automation’s editor.
5. Session — chosen for an individual session when it’s created (via the options menu in the session start box), or changed later from the session’s settings.

At each level you can make one of three choices:

• Inherit (the default) — no opinion; the level above decides.
• Pin a profile — sessions at this level use the selected profile.
• No profile — explicitly opt out, so sessions at this level run unrestricted even if a level above sets a recommended default.

When a session starts, Devin walks the hierarchy from the top down: the most specific binding wins, unless a mandatory profile higher up locks things down (see below). Sessions spawned by other sessions (child sessions) are governed by the same chain as their parent, so restrictions can’t be escaped by delegating work.

​

When changes take effect

A session resolves its governing profile at the moments it boots: when it’s first created, and each time it wakes from sleep or reboots. Edits to a profile’s contents or to any binding (a default, automation pin, or session selection) do not automatically propagate to sessions that are already running — a running session keeps the restrictions it resolved at its last wake. Changes take effect for new sessions immediately, and for existing sessions the next time they resume.

​

Mandatory vs. recommended enforcement

Every profile has an enforcement level:

​

Recommended

A recommended profile is a default, not a mandate. Anyone (with the appropriate permission) at a lower level can pin a different profile or opt out entirely. Use recommended profiles to give teams a sensible starting posture while preserving flexibility.

​

Mandatory

A mandatory profile is a floor that lower levels cannot escape:

• Opting out has no effect. A “no profile” selection below a mandatory profile is ignored.
• Lower-level selections can only tighten, never loosen. If a lower level pins another profile, the two are intersected:
  • Network allowlists narrow to the destinations allowed by both profiles.
  • MCP allowlists narrow to the servers allowed by both.
  • Git access takes the minimum (read-only wins over full).
  • Devin MCP access is read-only if either profile sets read-only.
  • The GitHub CLI token is removed if either profile removes it.
• Mid-session edits are clamped. Network access granted during a session (e.g. by approving Devin’s request for a new domain) is intersected with the mandatory profile’s policy, so a session can never be granted access beyond what the mandatory profile allows.

For example, an enterprise can bind a mandatory profile with a network policy allowing *.internal.example.com as the enterprise default. Organizations can then layer their own profiles on top to further restrict specific teams or workflows — but no organization, automation, or session can widen access beyond the enterprise policy.

​

Permissions and governance

Managing profiles is governed by a dedicated Manage security profiles permission, separate from general settings management. It exists at two levels, each granted independently: Both levels of the permission can be granted to custom roles, so you can delegate security-policy management (for example, to a security team) without granting full admin rights. Members without the permission can’t enumerate, select, or change profiles — their sessions simply follow the resolved default — but anyone can see whether their session is governed by a profile and what network access it has.

​

Setting up security profiles

1. Create a profile. Go to Settings → Customization → Security profiles (or Enterprise settings → Devin → Security profiles for an enterprise-wide profile), create a profile, and configure its security settings and enforcement level.
2. Set a default. Bind the profile as your organization default (or enterprise default) so new sessions pick it up automatically.
3. Pin where needed. Override the default on specific automations — for example, a stricter profile for an automation that touches sensitive systems — or on individual sessions at creation time.
4. Tighten over time. Start with a recommended profile to observe impact, then switch it to mandatory once your allowlists cover your teams’ legitimate needs.

​

Automations and profiles

Automations can carry their own network policy and MCP selection. These are restriction-only layers on top of the governing profile — sessions started by the automation only get network destinations and MCP servers allowed by both the automation and the profile, so an automation can never widen the profile’s access. The automation layer is resolved live at each session boot and wake, so editing an automation’s network policy takes effect without recreating its sessions.

​

Outposts and profiles

Sessions that run on Devin Outposts resolve their governing profile through the same binding chain as cloud sessions, and the restrictions Devin enforces from its cloud — the MCP allowlist, Devin MCP read-only, the git access level, and GitHub CLI token removal — apply to outpost sessions exactly as they do to cloud sessions. The network policy is different. Devin enforces a session’s network allowlist at the machine level on Devin-managed VMs, but an outpost worker runs on infrastructure you operate, so Devin does not install firewall rules on your machines. Instead, each queued session’s effective network policy is published to your orchestrator in the Outposts API as spec.network_policy (whether the policy is enabled, plus the allowed hostnames and CIDRs). Enforcing it — for example with a per-session egress proxy, a Kubernetes NetworkPolicy, or VM firewall rules — is the outpost operator’s responsibility. Devin still sees the allowlist and requests access to missing destinations as usual, but approving a request only updates the session’s policy in Devin; it does not change your network by itself. spec.network_policy is captured when the session is queued for an outpost and refreshed when it is re-queued (for example after the session sleeps and wakes), so re-read it from the API rather than assuming it is static.