Devin AI Security: Data Handling, Secrets, and Admin Controls

Cognition documents a training policy that surprises many security reviewers: by default, data may be used for model training to improve the service, and paid-plan customers must opt out on the Data Controls settings page if they want that stopped. After opt-out, Cognition states that customer data will not be used for training and that zero data retention is enabled with model providers. On Teams plans, only an administrator can exercise the opt-out. Enterprise customers sit on a different path entirely: Cognition says it will never train on Enterprise data without express prior written consent.

That distinction is the practical heart of Devin AI security. Buyers searching for "devin security" or "cognition enterprise security standards" often stop at encryption and audit logos. Those matter, but the day-to-day risk surface is how session data moves, who can grant repository access, how API keys are stored, and whether agent-produced code ships without a human review gate.

Devin AI is Cognition's autonomous software engineering agent. It can work through long tasks, touch repositories, and operate with credentials you supply. Treating it like a chat assistant understates the control model. You are onboarding a high-privilege engineering identity that needs the same data classification, least-privilege, and merge discipline you apply to a new contractor with write access.

This guide sticks to Cognition-published controls from the admin security docs, Enterprise packaging, Trust Center, and Secrets product guide. It does not invent certifications. Where Fast.io appears later, it is as a shared workspace layer for agent artifacts and handoffs around Devin, not as a built-in Devin feature.

Helpful references: Fast.io Workspaces, Fast.io Collaboration, and Fast.io AI.

Cognition's admin security documentation states that all data transmission is encrypted in transit and at rest. Production systems are monitored with logging, error handling, and live metrics dashboards. Unusual states such as high error rates or failures trigger alerts for investigation. Access to the AWS cloud environment is role-based, and only a small number of employees or contractors receive direct production access.

On the people side, Cognition requires multi-factor authentication on main work applications and annual security training for employees and contractors, covering password hygiene and social engineering awareness.

For third-party assurance, Cognition obtained SOC 2 Type II certification. Admin docs note certification activity and organization-wide security training in March 2024. Enterprise security docs state Cognition has been SOC 2 Type II certified since September 2024, with auditors reviewing policies and controls related to data security, privacy, processing integrity, confidentiality, and availability. For current reports and questionnaires, Cognition points buyers to the Trust Center rather than pasting claim sheets into sales decks.

Vulnerability reports go to security@cognition.ai. Enterprise documentation adds that Cognition notifies Enterprise customers of security incidents that may impact their environments according to contractual reporting obligations.

What SOC 2 Type II does and does not prove

SOC 2 Type II is a strong signal that Cognition operates under examined controls over a period of time. It does not mean every customer configuration is secure. Your GitHub app scopes, secret inventory, training opt-out status, and branch protection rules still determine whether Devin is safe for a given codebase. Reviewers who stop at "they have SOC 2" leave the highest-impact decisions unmade.

Enterprise packaging beyond the base cloud product

The Devin Enterprise page positions a stricter deployment story: virtual private cloud (VPC) deployment with support for major clouds, data kept in the customer's controlled environment, SOC 2 compliance claims, audit logs, fine-grained access controls, and integration with custom identity providers (IdP). Enterprise security docs also note that for dedicated deployments, customer data is stored within the customer's tenant, and by default Cognition does not train models on that customer data.

If you are buying for regulated engineering orgs, treat VPC, tenant isolation, IdP integration, and contractual training language as separate checklist items. Confirm each one in the Trust Center and your order form rather than assuming the public product and Enterprise product share the same defaults.

Keep Devin artifacts in one reviewable workspace

Store security checklists, secret inventories, and agent handoffs where humans and agents share versioned files, permissions, and search. Start a 14-day free trial and connect through Fast.io MCP when you are ready.

Start 14-Day Trial

Cognition processes Devin data based on how customers interact with the product. Through the web application, Cognition states it only processes data actively provided by the authorized user prompting Devin. For GitHub and messaging integrations, the administrator who installs the integration can review and manage permissions granted to Devin.

Retention is relationship-based: Cognition retains data processed through Devin for the duration of the customer relationship unless customers specify otherwise. Feedback data and user interaction data may be retained as long as Cognition determines it is needed.

Training and intellectual property

Paid plans: training use is on by default, with an opt-out path on Data Controls. Teams plan opt-out is admin-only. After opt-out, Cognition says training stops and zero data retention is enabled with model providers. Knowledge features can still help Devin fit team workflows without relying on model training of customer code.

Enterprise: no training without express prior written consent. Confirm the language in your agreement.

Output ownership follows a clear rule in Cognition's docs: code and other work product Devin produces is the customer's intellectual property for commercial use, with a restriction against using that output to train models aimed at reverse-engineering or competing with Devin.

GitHub and messaging data boundaries

For GitHub, installers can select which repositories Devin may access, and permissions can be adjusted later through GitHub App settings or by regenerating fine-grained tokens. Start narrow: a pilot repo is enough to evaluate quality before expanding to monorepos that hold secrets-adjacent configuration.

For Slack-style messaging, Cognition states Devin does not read, process, or store workspace data beyond information provided when Devin is tagged, initially prompted, and when additional information is shared in the active thread while a session is ongoing. Enterprise messaging docs generalize that pattern: Devin only processes data explicitly provided when tagged, when it receives a direct prompt, or when additional context is shared in an active thread.

Those scopes are helpful, but they still depend on human discipline. Pasting production credentials into a chat thread bypasses every Secrets feature Cognition ships. Treat integration permissions as necessary but incomplete controls.

Cognition's Secrets guide is explicit: when Devin needs credentials such as API keys, passwords, cookies, or similar material, use the Secrets feature under Settings rather than dropping values into the conversation. Secrets live primarily on the Secrets page in the Devin app, especially for organization-level material.

Cognition recommends a dedicated service account per platform (for example, a Devin-only email identity) instead of sharing a human engineer's personal logins. Notes on each secret can capture environment constraints, rotation schedules, and ownership. Examples from the docs include "production only," region-specific database credentials, deprecation timelines, and which user account owns the key.

Secret scopes

Organization global secrets persist across future sessions for the whole organization. All members can use them in sessions, but only admins can view or edit existing secrets. Secrets are encrypted at rest. New secrets apply only to sessions created after the secret was added, so rotating a key does not retroactively rewire old sessions.

Personal secrets stay scoped to sessions you create. They are useful for credentials tied to an individual tester account and should not become the home for production production credentials that the whole org needs.

Repo-specific secrets can be supplied as environment variables or a .env during environment configuration. Sessions using the same snapshot can access them; unrelated sessions cannot.

Session-specific secrets appear when Devin asks mid-task, or when you attach secrets to the current session only. They do not persist for future sessions, which is the right default for one-off credentials.

Supported types include raw secrets (API keys, SSH keys, usernames, passwords, tokens), site cookies for authenticated browser state, and TOTP secrets for two-factor flows on Devin-dedicated accounts. Cognition recommends against handing Devin 2FA material for personal human accounts. Key-value multi-field secrets are deprecated; create separate raw secrets for each field instead.

Once configured, applications read secrets as environment variables, with name normalization rules for invalid characters. That design keeps credentials out of prompt text while still letting Devin run authenticated workflows.

Practical secrets hygiene for agent coding

Mirror what you would demand from any automation bot:

• Prefer short-lived tokens and least privilege scopes on the external systems Devin must call.
• Separate staging and production secrets; never load prod keys into exploratory sessions.
• Rotate org secrets after contractor offboarding or when a session transcript may have leaked a value.
• Keep a human-owned inventory of which secrets Devin can use, even if the product encrypts values at rest.
• If Devin needs browser access to an internal app, prefer dedicated accounts plus Secrets-managed cookies or TOTP over shared personal sessions.

Teams that already use a vault such as HashiCorp Vault, AWS Secrets Manager, or 1Password should treat Devin Secrets as the delivery mechanism into the agent session, not as the only system of record. Sync or mint values into Devin Secrets on a controlled schedule rather than inventing a second unmanaged key store.

Cognition's own best-practice section is blunt: Devin can still hallucinate, introduce bugs, or suggest insecure code. Recommended mitigations include code reviews before deployment, branch protections so checks run before merges, and the same engineering review process you already apply to human pull requests. Security is not finished when encryption and SOC 2 boxes are checked. It finishes when unsafe code cannot reach production without a human gate.

That is also where many teams fail operationally. Session transcripts, patch notes, threat models, and "how we configured Devin" documents scatter across laptops, chat threads, and temporary object storage. Local disks work for a solo experiment. S3 or Google Drive work for bulk archives. Neither gives agents and humans a single permissioned workspace with version history, semantic search, and an append-only audit trail of who touched which artifact.

Fast.io is one option for that coordination layer around Devin AI, not a replacement for Cognition's product security. Engineers and agents can share org-owned workspaces with per-file version history and granular permissions at org, workspace, folder, and file levels. Intelligence Mode indexes files for hybrid search and citation-backed chat when you want to ask "what secrets policy did we approve for the payments service?" without grepping ten folders. An append-only audit log records activity for later review. Branded shares (Send, Receive, Exchange) help move packages to security reviewers or vendors with durable or expiring access and per-recipient grants.

Agents can connect through Fast.io's consolidated MCP toolset over Streamable HTTP at /mcp (with legacy SSE at /sse). Humans use the UI; agents use the same files. Ownership transfer lets an agent prepare structure and hand the organization to a human when the pilot moves from experiment to team standard. Workflows, tasks, and approvals can formalize "Devin opened a PR, security must sign off, then release engineering merges."

Pricing is usage-based across Starter ($29/mo), Business ($99/mo), and Growth ($299/mo) plans. Every organization starts with a 14-day free trial that requires a credit card. Paid subscription is required for ongoing work. If you only need a bucket, stay on S3. If you need agents and people to collaborate on security evidence, architecture notes, and handoff packages with searchable context, an intelligent workspace is a better fit.

A concrete secure pilot pattern

1. Create a dedicated Devin identity and GitHub app install limited to one non-production repository.
2. Opt out of training (or confirm Enterprise contractual defaults) and store proof in your vendor file.
3. Load only staging credentials into Devin Secrets with notes that forbid production use.
4. Require branch protection and two-person review on Devin PRs.
5. Store architecture decisions, scan reports, and approved secret inventories in a shared workspace humans and agents can both read.
6. Expand repository scope only after the first pilot merges cleanly under your normal quality bar.

Devin can also be used offensively for security work (for example Cognition's Security Swarm product for finding and remediating vulnerabilities). That is a separate product surface from protecting the Devin deployment itself. Do not confuse "Devin for security scanning" with "security of Devin as a vendor." Your enterprise risk review still needs Trust Center evidence, training controls, secrets practice, and merge policy regardless of how you use swarm-style scanning later.

Devin AI security is a stack of vendor claims you verify plus operational habits you own. Cognition publishes encryption in transit and at rest, SOC 2 Type II, a Trust Center, vulnerability disclosure, integration scopes for GitHub and messaging, paid-plan training opt-out with zero data retention after opt-out, Enterprise no-training-without-consent plus VPC and IdP options, and a Secrets product for credentials. Those are the published controls. Your residual risk is determined by whether training settings match policy, whether secrets stay out of prompts, whether repo access stays least privilege, and whether humans still review agent code.

For commercial buyers, the highest-impact actions are simple: read the current Trust Center materials, lock training defaults to your data policy, scope SCM access tightly, put every credential through Secrets, and refuse to merge Devin output without the same review you require from staff engineers. Pair that with a durable place for security evidence and session artifacts so the next incident review is not a scavenger hunt across personal drives.

If you treat Devin as a privileged engineer with a badge, MFA, scoped keys, and mandatory code review, the product's published controls are enough to start a careful pilot. If you treat Devin as a magic box that should never see production paths, you will still need the same checklist the first time someone pastes a prod token into chat. The difference is only whether you build the controls before that moment or after.