TL;DR: AI-assisted coding and fragmented developer environments make IDE-only security coverage incomplete, so GitHub PR scanning is needed to reach code that actually ships, according to Symbiotic Security. The deeper issue is not where detection happens, but whether security decisions remain consistent across the SDLC as developers move between tools and agents.
At a glance
What this is: Symbiotic Security argues that AI coding security now has to span both IDE workflows and GitHub PRs because developers do not work in one uniform environment.
Why it matters: For AppSec and platform teams, the issue is not just earlier detection but consistent enforcement and remediation context across the software delivery workflow.
Context
AI-assisted development changes the control problem because code is now created, modified, reviewed, and merged across multiple tools rather than one central gate. Security models that depend on a single developer environment break down when teams use different IDEs, automated assistants, and repository workflows.
The governance issue is consistency. If a finding is handled one way in the IDE and another way in the pull request, teams create duplicate work, policy drift, and avoidable delays. This article is really about how application security has to follow the development workflow instead of assuming the workflow will adapt to the control.
Key questions
Q: How should security teams govern AI-assisted coding tools in the IDE?
A: They should treat AI-assisted coding tools as part of the control surface, not just a developer convenience. That means applying policy at the point of code generation, controlling which plugins and packages can run, and logging every allow, block, and override with identity and context. The goal is to keep untrusted code from becoming trusted software.
Q: Why do AI-generated code issues reappear across the development workflow?
A: They reappear when security state is not shared between the editor, the pull request, and CI. A finding marked irrelevant in one place can look new in another unless the workflow preserves that decision. That creates duplicate work, inconsistent enforcement, and reviewer fatigue.
Q: What breaks when security review happens only inside the IDE?
A: Coverage breaks, because not every developer uses the same editor or extension. Code can still reach the repository through tools and workflows that the IDE never sees. A PR-level control is needed to inspect what is actually being merged, not just what was written locally.
Q: Should security teams prioritise developer experience or stricter code review?
A: They should treat them as linked requirements rather than a trade-off. If controls slow developers too much, they are bypassed or ignored. If controls are too loose, insecure code ships. The better pattern is low-friction detection at creation time plus shared enforcement at merge time.
Technical breakdown
Why IDE security catches AI-generated code earlier
An IDE integration places security checks at the point of code creation, which matters when developers are using AI coding assistants that can generate insecure patterns quickly. The technical value is not just faster detection, but shorter feedback loops: the fix is made while the relevant code context is still visible. That reduces review overhead and helps prevent defects from accumulating until a later gate. In practice, this is strongest when the IDE can surface precise findings without interrupting normal developer flow.
Practical implication: move high-friction findings into the editor only when they can be fixed in seconds, not after a separate review cycle.
What GitHub PR scanning adds to developer security workflows
Pull request scanning compensates for the fact that not every developer uses the same IDE or installs the same extension. A PR-based control sees the code that is actually headed toward merge, which makes it a workflow-level control rather than an individual-endpoint control. This is especially important in mixed environments where AI-generated code may bypass local tooling or where contributors use different editors. The PR becomes the common inspection point for coverage, policy checks, and reviewer context.
Practical implication: treat PR scanning as the coverage layer that catches what editor-based controls miss.
How security state has to persist across the SDLC
The hard problem is not finding issues in one place, but preserving decisions across places. If a developer marks a finding as irrelevant in the IDE, that decision should carry into the PR and CI view so the same issue is not re-litigated repeatedly. The same logic applies to fixes and policy breaches: security metadata has to travel upstream and downstream with the code. This is a workflow integrity problem as much as a detection problem, and it becomes more acute as AI tools make code changes faster.
Practical implication: design security tooling so findings, suppressions, and policy labels persist across IDE, PR, and CI.
Threat narrative
Attacker objective: The attacker objective is to get insecure code into production by exploiting gaps between developer tools, review stages, and policy enforcement.
- Entry occurs when developers introduce AI-generated or manually written code inside the IDE before any repository-level review is available.
- Escalation occurs when that code moves into pull requests without shared security context, allowing inconsistent decisions or missed findings to persist.
- Impact occurs when vulnerable code reaches merge and production because controls were fragmented across tools instead of enforced across the workflow.
Breaches seen in the wild
- JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Workflow consistency is now the core application security problem in AI-assisted development. The article shows that detection location matters less than whether the same decision follows the code from IDE to PR to CI. Once AI-generated code enters the pipeline, duplicated review and inconsistent state become governance failures, not just usability issues. The practitioner conclusion is that security control state must be portable across the SDLC.
IDE-only control coverage will always be incomplete in mixed developer environments. Teams rarely standardise on one editor, and that reality weakens any security model that depends on universal extension adoption. This is not a tooling preference issue, it is an access-path problem: if the code can be created in multiple places, the control plane must meet it in multiple places. The practitioner conclusion is to use the PR as the shared enforcement backstop.
AI coding security creates a new form of security metadata debt. Suppressions, policy labels, and remediation state can become inconsistent as code moves between assistants, editors, and repository checks. That creates noise, delays, and mistrust in the security workflow. The practitioner conclusion is to treat state synchronisation as part of control design, not as an implementation detail.
Developer-first security only works when the workflow is low-friction and the policy outcome is stable. The article’s symbiosis model is really a control-design argument: if a finding is accepted in one stage, it should not reappear as an unrecognised issue later. That is the governance pattern AI-assisted development now demands. The practitioner conclusion is to align security decisions across tools before scaling AI coding adoption.
AI coding security and NHI governance intersect at the automation boundary. Where agents, assistants, and repository automation participate in code creation and review, the organisation is governing machine-mediated change, not just human developer behaviour. That makes provenance, policy consistency, and control handoff important even when the article is framed as AppSec. The practitioner conclusion is to review agent-assisted development as part of broader identity and workflow governance.
What this signals
The practical shift for AppSec teams is from tool coverage to state consistency. Once developers move between IDEs, agents, and GitHub PRs, the security programme has to preserve one decision model across all of them or risk duplicated findings and inconsistent enforcement.
A workflow integrity gap emerges when findings are handled differently depending on where they are discovered. That gap becomes more visible as AI coding assistants accelerate change, because the review path has less time to reconcile conflicting security states.
For practitioners
- Standardise security state across IDE, PR, and CI Keep suppressions, policy decisions, and remediation notes synchronised so the same code issue is not handled differently at each stage of delivery.
- Use pull request scanning as the common control point Apply repository-level scanning to catch code that was created in different editors, by different assistants, or without the same local extension coverage.
- Reduce friction in IDE findings Surface only actionable issues in the editor so developers can fix code while the context is fresh and avoid repeated review cycles later.
- Carry policy-breaching labels upstream Tag issues in the IDE when they would fail CI so developers can see policy impact before they submit code for review.
Key takeaways
- AI-assisted development does not fail only at detection. It fails when security decisions do not remain consistent as code moves from creation to merge.
- IDE-only coverage is incomplete in mixed developer environments, so repository-level inspection is needed to catch what local tooling misses.
- The strongest governance pattern is shared security state across IDE, PR, and CI, with low-friction developer workflows and stable policy outcomes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST AI RMF and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | AI coding assistants can generate or propagate unsafe code through developer tools. |
| ASI03 — Identity & Privilege Abuse | The article is about keeping consistent control over code changes made through AI-enabled workflows. | |
| Recommendation — Constrain agent-assisted code changes with review and policy checks before merge. Bind agent actions to least-privilege permissions and track policy state across tools. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Mixed IDEs, PRs, and CI views create governance gaps when the code path is not fully covered. |
| Recommendation — Inventory every code path and security checkpoint so no change route bypasses review. | ||
| NIST AI RMF | MEASURE — AI Risk Measurement and Monitoring | AI-assisted coding requires ongoing monitoring of how controls behave across the workflow. |
| Recommendation — Measure whether AI coding controls remain consistent across IDE, PR, and CI stages. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article addresses secure code production and the controls around how code reaches production. |
| Recommendation — Embed security checks into the code workflow so architecture decisions are enforced before merge. | ||
Key terms
- AI Code Security: AI code security is the practice of finding and controlling vulnerabilities introduced by generative coding tools and AI-assisted development workflows. It combines AppSec, policy enforcement, and runtime validation so machine-generated code is checked for unsafe logic, hallucinated dependencies, and secret exposure before production.
- Pull Request Scanning: Pull request scanning is the automated review of code changes before they are merged into a repository. It checks new or modified code for security flaws, secrets, policy violations, dependency risks, and unsafe patterns. In identity and security programs, it helps stop risky changes from reaching production and supports controlled software delivery.
- Workflow State: Workflow state is the current position of a task or control action within a managed process, such as pending, approved, remediated, or closed. It matters because governance programmes need more than static status fields. They need a durable, traceable state that survives handoffs and review cycles.
- Developer-First Security: Developer-first security is an operating approach that places security feedback inside the tools and workflows developers already use. Its purpose is to reduce friction while improving remediation speed, ownership, and consistency across the delivery lifecycle.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, to strengthen governance across human and machine-mediated workflows.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org