Devin Security: Governing an Autonomous Coding Agent

Devin is an autonomous coding agent that clones your repositories into its own machine, runs commands, reads secrets as environment variables and opens pull requests, so governing it means governing a non-human identity with write access to source code. The security questions are concrete: which repositories the Git integration can reach, whose name goes on each pull request, which secrets land in every session, who can create sessions on behalf of others, and where the audit trail lives. This guide works through Cognition's own Devin documentation (checked 8 November 2026) for SSO and SCIM, built-in and custom roles, service users and API keys, the GitHub App permission set, blueprints and secrets, AI Guardrails, IP access lists and deployment models. It is written for platform engineers, application security teams and identity owners rolling Devin out at team or enterprise scale. The general risks of coding agents are covered in the AI Coding Agents Security Guide; this page is specific to Devin.

This is an independent guide from NHI Mgmt Group, based on Cognition's public documentation as of November 2026. It is not sponsored or reviewed by Cognition. Product features change, so confirm settings against Cognition's current documentation.

Key takeaways

The Git integration is the crown jewel. The Devin GitHub App requests read and write on contents, pull requests, actions and workflows, and Devin acts with organisation-level permissions rather than the permissions of the person running the session, so repository selection and branch protection are your main controls.
Enforce SSO and turn off the defaults. Configuring SSO does not disable email, GitHub and Google login; ask Cognition to select "Disable default login connections", and use SCIM so leavers lose access immediately rather than at their next login.
Treat impersonation permissions as privileged. Impersonate Sessions and Impersonate Account Sessions let a service user start sessions as other people; grant them to as few service users as possible and log every use.
Secrets become environment variables in every session. Enterprise secrets reach every organisation and session unless marked Build only, so scope credentials to the narrowest tier and keep registry and build tokens build-only.
Screen inputs and restrict where access comes from. AI Guardrails can log, warn or block prompt injection and exfiltration attempts in messages and PR comments, and IP access lists limit both the web app and the API to your egress ranges.

How identity and access work in Devin

Devin has two layers of tenancy. An enterprise (account) contains one or more organisations, and each organisation has its own members, secrets, knowledge, playbooks and repository permissions. Humans sign in to the web app, and automation authenticates to the API. Devin itself then acts in your systems through integrations: the source control connection, chat tools such as Slack and Microsoft Teams, ticketing integrations and MCP servers.

Identity	How it authenticates	What it can do	Main control
Human user	SSO (SAML 2.0, OIDC via Okta, Microsoft Entra ID or generic OIDC) or default login connections	Start and steer sessions, manage resources the role allows	SSO enforcement, SCIM, IdP group to role mapping
Service user	API key with the `cog_` prefix against the v3 Organization or Enterprise API	Create sessions, manage resources; with impersonation, act for other users	Custom role, key inventory, IP access list
Personal access token	Token issued to a human user	API calls attributed to that user	Manage API Keys permission, enterprise PAT inventory
Devin in source control	GitHub App or provider integration installed by an enterprise admin	Clone, push branches, open PRs, comment, read alerts	Repository scope, branch protection, Open PRs as setting
Devin in the session machine	Secrets injected as environment variables	Whatever those credentials allow	Secret tiering, Build only flag, rotation

SSO: you create the application in your IdP and Cognition configures the connection, together with your verified email domains. Setting up SSO does not by itself remove the default login connections (email, GitHub, Google). Ask for "Disable default login connections" and then confirm with Cognition which connections remain enabled, otherwise a user with a matching email can bypass your IdP's MFA and conditional access.

SCIM 2.0: with SCIM, users are created when assigned to the application, deactivating or unassigning them removes their enterprise membership, and group changes sync in real time. Without SCIM, deprovisioning and group changes only take effect at the user's next login, which in practice means a leaver keeps their roles until someone notices. See the SCIM Provisioning Guide.

Group mapping: send a groups claim (a SAML attribute statement or an OIDC groups claim) filtered by a prefix such as Devin-. Groups then appear under Settings, Enterprise, Membership, Groups (IdP), where you assign an enterprise role and organisation roles. Names are case-sensitive and nested groups are not supported, so flatten the groups you use for Devin.

Admin roles and privileged access

Devin ships built-in roles at both levels and supports custom roles built from named permissions. The built-in organisation roles are Admin, Member and DeepWiki Only; the account roles are Admin and Member. A Member can manage day-to-day organisation resources, which per Cognition's documentation includes knowledge, playbooks, secrets and snapshots, so "Member" is more powerful than the name suggests where secrets are concerned.

Permission (custom roles)	Level	Why it is sensitive	Suggested holder
Manage Git Integrations, Manage Repository Permissions	Account	Decides which repositories every organisation can reach	Small platform admin group
Manage Secrets, Manage Account Resources	Org, Account	Adds credentials that appear in sessions and builds	Platform team, not all members
Impersonate Sessions, Impersonate Account Sessions	Org, Account	Service users create sessions as other users, inheriting their attribution	Named automation service users only
Manage Service Users, Manage Account Service Users	Org, Account	Creates non-human identities and their keys	Identity or platform owners
Manage IP Whitelist	Account	Can remove all network restrictions	Security admins
Manage Enterprise Settings	Account	Controls AI Guardrails and enterprise behaviour	Security admins
Manage MCP Servers, Manage Account MCP Servers	Org, Account	Adds new tools and data sources the agent can call	Reviewed change process
View Audit Logs	Account	Read access to the security record	Security operations

Split duties: the person who adds a repository to an organisation should not also be the person who adds the secrets for it. Custom roles make this practical.
Use the DeepWiki Only role for people who need to ask questions about code but should not start sessions that change it.
Review Manage Sessions and View Sessions: session transcripts contain code, command output and sometimes credentials that a command printed, so viewing other people's sessions is a data access right.
Recertify quarterly: include the IdP group to role mapping in your access review, not only direct assignments.

Integrations, API tokens and service accounts

Source control

Only enterprise admins can create source control connections, and organisations cannot touch a repository until it is granted in Settings, Repositories, at group level (a GitHub organisation, GitLab group, Azure DevOps organisation or project, or Bitbucket workspace) or repository level. Prefer repository-level grants for organisations that do not need everything.

The Devin GitHub App requests read access to items including Dependabot alerts, code scanning alerts, secret scanning alerts, members and organisation administration, and read and write access to actions, checks, commit statuses, contents, issues, pull requests, repository creation, projects and workflows. Two consequences follow. First, write on workflows means a change Devin pushes can alter CI definitions, which run with your pipeline's own credentials. Second, read on secret scanning alerts means alert contents are visible to the integration. Install the App on Select repositories rather than All repositories and revisit that list in GitHub under the organisation's Settings, GitHub Apps.

Branch protection: Cognition recommends protection rules on the main branch so required checks pass before changes merge. Add required reviews from a human code owner and require review of changes under .github/workflows. See the CI/CD Pipeline Identity Security Guide.
Attribution: the Open PRs as setting offers Devin, User (falls back to Devin if the user has not linked GitHub) and User only (fails if not linked; automations and service users still fall back to Devin). The enterprise Commit authoring setting offers Devin only, co-authored, and user as author with Devin as committer. Choose deliberately: "User" attribution makes PRs look human-written, which can let an agent-authored change pass a reviewer who would scrutinise a bot.
Signing: for GPG-signed commits Cognition suggests a dedicated GitHub account that owns both the commit identity (set via the GIT_USER_NAME and GIT_USER_EMAIL secrets) and the push credential; commits show as Verified only when Devin is the committer.

API keys and service users

The v3 API has organisation endpoints (/v3/organizations/*: sessions, knowledge, playbooks, secrets) and enterprise endpoints (/v3/enterprise/*: analytics, audit logs, user management, billing, infrastructure). Service users authenticate with cog_ keys; personal access tokens act as the human who issued them. Creating a session for another user with create_as_user_id requires the impersonation permission. Legacy v1 and v2 keys still exist but receive no new features: inventory and retire them. Holders of Manage Account API Keys can view and revoke every user's PATs from an enterprise-wide inventory, which is the place to start a key review. Treat each service user as an NHI with an owner, purpose and rotation date; see the AI Agent Credential Lifecycle and Rotation Guide.

MCP servers and chat tools

Each MCP server is a new tool with its own credentials and its own route for untrusted content into the agent's context. Approve servers through change control and give each a scoped credential. In Slack and Teams, Devin processes messages it is tagged in or threads it is active in, so anyone who can post in those channels can instruct it: restrict which channels the app is in. See the MCP Security Guide.

Logging and detection

The audit log is available through the Enterprise API and is readable by holders of View Audit Logs. Confirm with a test which administrative actions it records before relying on a detection; the table lists what to look for. Pull it into your SIEM on a schedule rather than reading it in the UI. AI Guardrails events appear in audit logs as ai_guardrail_violation, with the triggering message, matched rule, action and a session link, and can also be retrieved from the guardrail violations API.

Signal	Source	What it can indicate
Guardrail violation on a PR comment or follow-up message	Audit log (`ai_guardrail_violation`)	Prompt injection planted in repository content or by an outside contributor
New service user, new API key or impersonation-capable role	Devin audit log	Persistence or privilege escalation through a non-human identity
IP access list cleared or replaced	Devin audit log	Network restriction removed
Devin-authored change to workflow files	Source control audit log and PR history	Path from agent output to CI credentials
Repository permission granted to an organisation	Devin audit log	Scope creep beyond the agreed set
Pushes or PRs by the Devin App outside working sessions	Source control audit log	Automation running unexpectedly, or misuse of the integration

Measure: percentage of users provisioned by SCIM; number of service users with impersonation permissions (target: a named handful); share of repositories granted at repository level rather than group level; percentage of Devin PRs merged with a human approval; guardrail violations per week by action (log, warn, block); age of the oldest unrotated secret. For reconstructing what an agent did after the fact, see Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs.

Hardening baseline

Secrets and blueprints

Blueprints exist at enterprise, organisation and repository level. A build runs enterprise then organisation initialize and maintenance steps, clones repositories, runs each repository's steps, then enterprise and organisation post-build steps, and saves a snapshot that sessions start from. Enterprise secrets are exposed as environment variables in every tier and in every session, unless marked Build only: build-only secrets are available only to enterprise and organisation steps, are removed before repositories are cloned, and are never available in sessions. Where an organisation secret and an enterprise secret share a name, the organisation secret wins.

Classify each credential as build-time (package registry, internal CA) or runtime (a test database, a staging API key). Mark build-time enterprise secrets Build only, so a prompt-injected session cannot read them.
Keep team credentials out of the enterprise tier. Cognition's guidance is that team-specific registry configuration belongs in that team's organisation blueprint so other teams do not inherit it.
Never put secrets in blueprint YAML. Cognition warns that secrets in YAML end up in logs, build artefacts and audit trails; use the secrets UI.
Give Devin its own credentials. Issue non-production, read-limited tokens created for the agent, never a developer's personal token, so revocation does not break a person and activity is attributable.
Rotate and prune. A value rotated in the UI takes effect on the next build. Remove unused secrets on a schedule.

Network and deployment

In Enterprise Cloud each session runs on its own isolated machine in Cognition's multi-tenant cloud, reached over the public internet or with IP allowlisting. A Customer Dedicated Deployment runs in a single-tenant VPC that Cognition hosts, connected to yours through AWS PrivateLink or an IPSec tunnel; Devin Connect is a gateway you deploy in your network to give one path to internal systems; customer managed keys are offered at the Enterprise Assured tier. Choose by what Devin must reach: public repositories and SaaS only suit Enterprise Cloud, while private registries, databases and internal APIs push you towards a dedicated deployment, where every route you open is a route an injected instruction could use.

IP access lists: set through the Enterprise API (/v3/enterprise/ip-access-list) with CIDR ranges, they restrict both the web app and the API (non-listed callers get 401). PUT replaces the whole list and DELETE removes all restrictions, so add all office and VPN egress ranges first and change the list with POST. The permission needed is Manage IP Whitelist; Manage Enterprise Settings does not grant it.

AI Guardrails

Guardrails screen initial messages, follow-up messages and PR comments, with per-guardrail actions Off, Log only, Warn user and Block message, configured enterprise-wide in Settings, Guardrails by holders of Manage Enterprise Settings. Start in Log only for two weeks, review the Violations tab for false positives, then move data-control and injection guardrails to Block. Guardrails screen messages; they do not inspect every file Devin reads, so they reduce rather than remove injection risk. See the Prompt Injection Guide.

Availability: per Cognition's documentation, SSO, SCIM, custom roles, IP access lists, AI Guardrails, enterprise secrets and dedicated deployments are enterprise features, and customer managed keys require the Enterprise Assured tier; confirm with your account team which apply to your contract.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Threat reference
SSO, SCIM, role reviews	AC-2 Account Management	PR.AA-05	ATT&CK T1078.004 Cloud Accounts
Repository scope, custom roles, impersonation limits	AC-6 Least Privilege	PR.AA-05	OWASP LLM06:2025 Excessive Agency
Secret tiering, Build only, rotation	IA-5 Authenticator Management	PR.AA-05	ATT&CK T1552.001 Credentials In Files
IP access lists, private networking	SC-7 Boundary Protection	PR.AA-05	OWASP LLM01:2025 Prompt Injection (exfiltration path)
Audit log export, guardrail events	AU-2 Event Logging, AU-6 Audit Record Review	DE.CM-03	ATT&CK T1195.001 Compromise Software Dependencies and Development Tools
MCP server approval	CM-7 Least Functionality	PR.AA-05	OWASP LLM06:2025 Excessive Agency

Common misconfigurations

SSO configured, defaults left on. Email, GitHub and Google login stay enabled unless you ask for them to be disabled, leaving a path around IdP policy.
GitHub App on All repositories. Combined with organisation-level permissions, every Devin user can direct changes to repositories they personally cannot write to. Select only the repositories Devin needs.
Developer tokens as Devin secrets. A personal token with production scope placed in an organisation secret gives every session, and anything that can steer a session, that developer's access.
Enterprise secrets not marked Build only. Registry and CA credentials needed only at build time end up readable in every session.
Impersonation on a general-purpose service user. A leaked cog_ key with Impersonate Account Sessions lets the holder act as any user.
No human review gate. Without branch protection and code owners on workflow files, an agent-authored change to CI can reach pipeline credentials. See the AI Agent Action Approvals and Spending Limits Guide.

Practitioner checklist

Enforce SSO, ask Cognition to disable default login connections, and confirm in writing which remain.
Enable SCIM and map flat, prefixed IdP groups to Devin enterprise and organisation roles.
Install the GitHub App on selected repositories only and grant organisations repository-level access where possible.
Protect main with required checks, human approval and code owners on .github/workflows.
Choose the Open PRs as and Commit authoring settings deliberately and document how reviewers recognise agent-authored changes.
Build custom roles that separate repository grants, secret management, service user management and IP list control.
Limit impersonation permissions to named automation service users, inventory every cog_ key and PAT, and retire legacy keys.
Mark build-time enterprise secrets Build only, keep team secrets in organisation blueprints, and issue agent-specific, non-production credentials.
Apply an IP access list through POST after loading all egress ranges, and enable AI Guardrails in Log only before moving to Block.
Export the audit log to your SIEM and alert on new service users, impersonation grants, IP list changes and guardrail blocks.