Devin Makes Security Scans Mandatory, Locks PR Access

Devin removed the opt-out for security scanning in every review and added a setting that stops a PR comment from summoning a session it should not reach.

Devin's code review no longer lets a team turn off security scanning. As of September 16, 2026, Cognition removed the “Security scan” toggle from Devin Review's settings, and two days later, on September 18, it shipped a setting that keeps a pull request comment from reaching any Devin session the commenter is not already authorized to see. Both changes convert something that used to be a choice into something the product now does by default, and they landed two days apart.

Cognition describes Devin on its own site as “the AI software engineer,” built “to plan and execute complex engineering tasks, from code migrations to on-call incident resolution.” Devin Review is the code review layer of that product: it reads a diff, organizes it for a human to skim, and can flag or fix bugs before a person ever opens the pull request. The two settings changes below both live inside that review layer, and inside the permissions that decide who can talk to a running Devin session at all.

Sources: Cognition / Devin

Cognition's release notes describe both changes in plain, dated entries. The September 16 entry, titled “Security Bugs Are Always Checked in Devin Review,” reads: “Devin Review now always checks for security bugs in every review; the ‘Security scan’ toggle has been removed from Settings > Review. Whether security bugs are posted to GitHub remains toggleable.” The September 18 entry, titled “‘Require Session Access for PR Comments’ Org Setting,” reads: “Org admins can require that PR comments only reach Devin sessions the commenter has access to, under Settings > Devin > Pull requests. Enterprise admins can enforce it for all organizations.”

Sources: Devin release notes, September 2026

The first entry hardens what Devin checks. The second hardens who can make Devin do anything at all inside a pull request.

Security scanning stops being optional

Before September 16, Devin Review's security check sat behind a switch in Settings > Review, next to controls for style, test coverage, and other review dimensions. A team could disable it, and nothing in the product surfaced that fact anywhere a reviewer would see it later. After September 16, the scan itself stops being a choice: every review Devin runs checks for security bugs, without exception. What remains configurable is narrower and easier to defend: whether a confirmed finding gets posted as a comment on the pull request itself. A team can still keep findings inside Devin's own interface instead of surfacing them publicly on the PR, which is a workflow preference about visibility, not a decision about whether the code gets checked in the first place.

How does Devin restrict PR comments from reaching sessions?

The September 18 change addresses a different problem, and a more interesting one. Before it shipped, any account able to leave a comment on a pull request could, in principle, address that comment to a Devin session, regardless of whether the commenter had access to anything that session could see or touch. A contractor with comment-only access to a shared repository, an external collaborator on a fork, or anyone permitted to open an issue could type a comment that a Devin session would read as an instruction. Prompt injection in AI-generated code is usually framed as a code-generation problem, a model tricked by text hidden in a file it reads. This is the same mechanism aimed at a different surface: an attacker does not need code execution or stolen credentials, only a text box the agent reads and treats as legitimate input.

The new org setting closes the gap at the access-control layer instead of the model layer. Once enabled, a PR comment reaches a Devin session only if the commenter already has access to that session, which in most organizations means access to whatever repository, environment, or credential the session can reach. Enterprise admins can force the setting on across every organization they manage, which matters because a permissive default left on in a single org is enough for the gap to matter company-wide.

• A commenter with read-only or comment-only access could previously trigger a Devin session scoped to whatever the pull request touched, not to what the commenter personally could see.
• The exposure did not require a bug in Devin's code. It only required the ordinary fact that comment permissions and session permissions were two separate systems nobody had wired together.
• The fix is an access-control check performed before a comment reaches a session, not a smarter model deciding which instructions to trust.
• Enterprise-wide enforcement matters because one lagging organization inside a larger company is enough to leave the door open for everyone connected to it.

A pattern with a name: hardening defaults because toggles get left off

Neither change is unique in isolation. What stands out is the shape of the move: a security-relevant behavior that started as an opt-in setting became the default, and the opt-out was removed rather than merely relabeled or defaulted to on. A checkbox that starts checked still gives whoever is rushing through a setup wizard something to uncheck. Deleting the checkbox removes that option for everyone, rushed or not, which is a meaningfully different kind of fix than a changed default.

Approval gates for high-risk AI changes usually get discussed as a question of who signs off before a merge. Devin's two changes are the same argument applied earlier, before the merge question even comes up: a rule that depends on someone remembering to leave a switch on functions as a suggestion with a settings page attached, not as a rule, whether the switch guards a merge or a security scan.

Why security toggles get left off in the first place

• Defaults survive. Most teams never revisit a setting after the initial rollout, so whatever a feature ships as becomes what most organizations run for years afterward, which is exactly why Devin's fix targets the default rather than adding a warning about it.
• Toggles get disabled once, temporarily, to unblock a noisy rollout, and the switch rarely gets flipped back once the noise stops.
• Nobody audits a toggle until an incident forces the question, and by the time that happens the exposure window has already closed the wrong way, whether the toggle in question controlled a security scan or a comment-permission check.

What org admins should check before relying on the new PR comment setting

The September 18 change is opt-in at the organization level, not automatic. A team running Devin today does not get the tighter comment-to-session mapping simply because Cognition shipped it. An admin still has to go into Settings > Devin > Pull requests and turn it on, and an enterprise admin still has to decide whether to force it across every connected organization or leave that decision to each one individually.

• Confirm who currently has comment access on every repository connected to Devin, not just who has write access. Comment-only accounts are the ones this setting is built to constrain.
• Decide, before turning the setting on, whether any existing automation or bot account depends on commenting into sessions it does not have direct access to. Flipping the setting can silently break that workflow rather than only closing a gap.
• If the organization spans multiple connected orgs under one enterprise account, use the enterprise-wide enforcement option rather than relying on each org's admin to enable it individually.

What this means if you run Devin, or anything built like it

Two practical checks follow from these two changes, and neither one requires waiting for Cognition to ship the next update.

• Audit every AI coding tool in your stack for security-relevant settings that default to off, not only the ones that default to on. A missing feature is invisible during a settings review. A switched-off feature usually is not, but only if someone actually looks for it.
• If your organization uses PR-comment-triggered agent sessions of any kind, whether Devin or something built in-house, check today whether comment access maps to session access. If it does not, that gap exists right now, independent of what Cognition shipped on September 18.
• Treat “the scan runs but posting the result is optional” as a reasonable middle ground. Treat “the scan itself is optional” as a finding worth escalating in any tool your team evaluates next, including ones that have not made the change Devin just made.

TLM Forge applies the same fix Devin just applied to its scan, earlier in the pipeline: there is no settings page where a team can quietly leave the merge gate off. A commit-gate hook blocks the merge until every critical finding clears, so the failure mode this post describes, a toggle nobody remembers to check, was never a design decision TLM Forge had to make. There was never a toggle to leave off in the first place.