The Agentic SDLC: Why Most of What We Do in Software Security Has to Change

Author: Jet Anderson

The Agentic SDLC: Why Most of What We Do in Software Security Has to Change

By Jet Anderson—Updated June 2, 2026

Abstract

The software development lifecycle as security professionals have known it—sequential phases, human-gated control points, and siloed security domain reviews—is being structurally dismantled by the rise of agentic software development. AI coding agents now generate, review, and deploy code at machine speed, with volumes and iteration rates that no gate-based security process can match. This paper synthesizes current research across industry, academia, standards bodies, and vendor landscapes to argue that the security discipline itself must undergo an architectural shift: from episodic, ceremony-heavy gate checking to continuous, embedded, agent-native control validation. I examine what is actually breaking, what is not, and where the emerging architecture is headed. I conclude with specific recommendations for how security organizations should reframe their review programs, their SSDLC policy, and their unified security review platforms to operate in an agentic-first world.

1. Introduction

When I look at the security review processes most large organizations rely on—policy documents, human validated controls, developer guidebooks—I see a coherent, well-intentioned system built for a world that no longer exists. Those processes assume human developers write code, human architects produce design documents, and security teams can meaningfully review artifacts before they reach production. All three assumptions are breaking simultaneously.

In 2026, AI coding agents are autonomous participants in the software development process, not advisory tools. Systems like Cursor, Claude Code, and GitHub Copilot select dependencies, generate code, execute build steps, create pull requests, and push changes to repositories—at velocities no human reviewer can match. By end of 2026, Gartner projects that 40% of enterprise applications will embed task-specific AI agents, up from under 5% in 2025 [1]. Checkmarx surveys indicate that roughly 70% of organizations already estimate more than 40% of their code is AI-generated [2].

The security implications are severe. Zhao et al. found that 61% of AI-generated code is functionally correct but only 10.5% is secure [3]. Endor Labs found that 49% of dependencies recommended by AI coding agents contain known vulnerabilities [4]. IEEE-ISTAS 2025 research documented a 37.6% increase in critical vulnerabilities after just five agent iterations without embedded security checks [5]. And Cycode’s November 2025 industry survey found that while 100% of surveyed companies have AI-generated code in production, 81% of security teams lack visibility into it [6].

This is not a problem we can solve by tuning existing controls. It is an architectural problem that requires an architectural response. The purpose of this paper is to lay out what that response should look like—grounded in current research, honest about what we do not know, and specific about what the discipline should do differently.

2. What Is Actually Breaking (and What Is Not)

2.1 The Gate-Based Model Cannot Scale to Agent Velocity

The foundational assumption of the current SSDLC is that security can be inserted as checkpoints at defined phase transitions: at requirements, at design, before code merge, before production release. That model works when human developers produce code at human pace and when the artifacts being reviewed are discrete and human-authored.

Neither condition holds in agentic development. An agent running Cursor or Claude can iterate on a codebase hundreds of times per day. Each iteration may introduce security regressions independent of any prior review. The IEEE-ISTAS 2025 study [5] quantifies this directly: security degrades 37.6% over five iterations without continuous embedded validation. If we only check at the gate, and the agent has iterated five times since the last check, we are validating code that has systematically deteriorated. This is not a theoretical concern—it is an empirically documented failure mode of gate-based security in agentic environments.

Arnica’s 2026 AppSec predictions data make the human review layer’s collapse concrete: 65% of AI-flagged review issues are dismissed by developers during code review [7]. When the review layer has that dismissal rate, it has functionally ceased to exist as a security control, regardless of whether we require it in policy.

2.2 SAST Is Necessary but Not Sufficient

Static analysis does not become irrelevant in agentic development—it becomes insufficient as a standalone defense. The limitations are structural, not fixable by tuning:

  • A 2025 SAST evaluation measured baseline precision at 35.7%, meaning nearly two-thirds of findings are false positives [21]. At AI-generated code volumes, this produces alert fatigue at a scale that makes triage untenable.
  • Static analysis cannot detect vulnerabilities that emerge from inter-component interactions in distributed systems. These flaws only manifest when systems interact at runtime [8].
  • SAST fundamentally misses race conditions (TOCTOU), timing-based authentication bypasses, and complex authorization logic—exactly the classes of vulnerabilities that require temporal and compositional reasoning that static tools lack.
  • When aggressive false-positive reduction is applied using AI tooling, the best-performing configuration in the most rigorous 2026 study reduced false positives by 92.7% but suppressed 22.25% of actual vulnerabilities—including 7.77% of weak cryptography issues [10].

The implication is not that SAST disappears. It is that SAST alone is provably insufficient, and the AI-assisted filtering that makes SAST manageable at scale introduces its own systematic blind spots.

2.3 Threat Modeling Becomes More Necessary, Not Less

The most important counterpoint to “everything in security must change” is threat modeling. Contrary to the popular “AppSec is dead” narrative, the discipline of threat modeling is more critical in agentic development than in human development—precisely because agents lack the implicit architectural reasoning a human developer carries.

When a human engineer writes code, they carry context about system boundaries, trust assumptions, and data flows that never make it into the commit. When an agent generates code, none of that context exists unless it is explicitly encoded. The agent will generate functionally correct code that violates trust assumptions the human architect held as obvious but never documented.

Adam Shostack, a renowned authority on threat modeling, states this directly:

“You need to know the threat model to evaluate what the AIs hallucinate, and today you need AI.” [11]

The practice of threat modeling becomes the essential counterweight to agentic code generation. What cannot survive is the ceremony: whiteboard sessions, spreadsheet-based risk registers, and human-driven threat model reviews as pre-code gates. These are too slow, too disconnected from actual code, and too dependent on individual practitioner’s availability. The discipline survives; the process automates.

2.4 The Governance Failure Is the Real Crisis

The most important analytical correction to the prevailing “AppSec is broken” narrative comes from examining the actual evidence behind the vibe-coding security crisis. Escape.tech analysis found over 2,000 vulnerabilities and 400 exposed secrets in 5,600 publicly deployed vibe-coded applications [12]. These incidents—Moltbook exposing 1.5M tokens, OpenClaw spawning a $16M crypto scam, real-world CVEs with 8.8+ severity scores—are genuine.

But these applications never went through any security process. The failure is not that security tools did not catch the bugs. The failure is that nobody ran any security tools at all. Declaring “AppSec is dead” because unprovenanced code has vulnerabilities is a category error. It mistakes governance and culture failure for a tooling failure.

This distinction matters enormously for how we frame the response. The problem we are solving is not “our tools are wrong.” The problem is: how do we ensure that 100% of code—including code written by agents at any hour, in any team, without any human ever touching a keyboard—passes through meaningful security validation? That is a governance and platform problem.

It is this problem the discipline must solve.

3. The Emerging Architecture: Shift-Everywhere

The industry is converging on an architecture that has a name—“shift-everywhere”—and a clear structural logic [13]. Rather than concentrating security at phase-transition gates, it embeds security validation at every point where code exists: during generation, at commit, in CI/CD, at runtime, and continuously in production.

The architecture has three layers.

3.1 Layer One: Embedded (Agent-Native)—Primary Enforcement

Security policy lives inside the coding agent’s context and tool ecosystem. The mechanism is the Model Context Protocol (MCP)—an emerging standard that allows agents to query external systems as part of their generation loop. The security implications are significant: if an agent can call an MCP server exposing security requirements, vulnerability knowledge, or policy rules, it can validate code against those requirements before the code ever reaches a commit.

This is not theoretical. For example, numerous prominent security companies have deployed MCP servers for AI coding environments that enable things like real-time secret scanning and remediation in the generation loop [14], allowing coding agents to query security requirements from inside the IDE while writing code [15] and orchestrating multi-agent security workflows mapped to the OWASP LLM Top 10 [16].

The important corollary: the files that configure agent behavior—.cursorrules, CLAUDE.md, system prompts, MCP server configurations—are now security-critical infrastructure. Pillar Security documented a “Rules File Backdoor” supply chain attack in 2026 in which hidden malicious instructions in AI agent configuration files silently compromised all generated code [17]. Arnica found a TOCTOU (Time of Check to Time of Use) vulnerability in Cursor’s agent guardrails in which a malicious MCP server could present a benign script for human review and execute a different malicious script [18]. These configuration files need integrity controls, version management, code review requirements, and audit trails equivalent to production credentials.

The good news is: organizations don’t need to buy more tools to solve these problems. The engineering expertise and subject matter knowledge already exist inside most mature security programs. Instead of being task completers and tool runners, security teams should build agentic integrations and move on to being knowledge farmers, injecting their own knowledge about how to do the right thing into the agentic pipeline.

3.2 Layer Two: Gate-Based—Audit and Safety Net

Gate-based security does not disappear. Its role shifts from primary enforcement to audit and verification. The CI/CD security stack—SAST, DAST, SCA, secret scanning—remains essential for three reasons: compliance frameworks require demonstrable testing artifacts; the best embedded AI security tool still misses 22% of real vulnerabilities; and gates provide the audit trail that embedded checks cannot.

What is changing dramatically is the response to gate findings. AI-assisted remediation has matured to the point where gates increasingly feed autofix workflows rather than human remediation queues:

  • GitHub Code Autofix: 3x faster remediation overall, 12x faster for SQL injection, with autonomous PR creation [19]
  • Snyk Agent Fix: 80% autofix accuracy [20]
  • Checkmarx Developer Assist Agent: real-time security agent inside Windsurf and Cursor IDEs [22]
  • Semgrep: Semgrep Assistant demonstrates 95% human agreement on false positive triage and reduces triage workload ~20% on day one (rising to ~40% after one week of use) [8]—however, these figures reflect triage classification performance, not autofix accuracy, and comparable autofix numbers have not been published. Semgrep recently released an MCP server for in-IDE use, bringing its toolchain into the embedded agent-native model. Similar remediation improvements to those seen with other platforms can reasonably be expected as that capability matures.

The pattern is: gate detects → AI proposes fix → human validates → autonomous PR. Security teams stop manually remediating and start reviewing agent-proposed fixes. This is a significant authority shift to security review teams while maintaining human judgment on the final acceptance decision.

3.3 Layer Three: Runtime—Behavioral Monitoring

When agents operate autonomously in CI/CD pipelines and in production, behavioral monitoring becomes the final safety layer. Agents exhibit non-deterministic behavior—identical configurations can produce different outcomes based on input data, prompt variations, or interactions with other agents [23]. Traditional rule-based security monitoring, which depends on deterministic behavior, fails here.

The emerging approaches:

  • Zero Trust for agentic systems: Red Hat’s 2026 framework proposes extending zero trust principles to every agent hop and tool call—identity verification, delegated tokens, continuous authorization, and workload attestation [24].
  • Agent identity as first-class infrastructure: Microsoft’s Entra for AI agents and similar approaches treat agents as principals requiring certificate-based authentication, scoped permissions, and temporal access restrictions [25].
  • Adversarial agent validation: CrowdStrike’s multi-agent security approach has one agent generate code while another autonomously attempts to exploit it—a continuous adversarial feedback loop embedded in the development pipeline [26].

Internal agent platforms—runtime hosts for conversational, tool-calling, structured-output, workflow, and supervisor agents; deployment services that bridge to frameworks like LangGraph; skill registries and marketplaces; RAG pipelines with per-tenant isolation—make these challenges concrete. From a security posture, the strengths in well-built internal platforms are real: PR-gated registry publication with live unauthenticated auth probes, per-tenant collection isolation in vector stores, secrets retrieved from key vaults rather than config files.

The gaps map directly to the industry’s open problems: A2A (Agent-to-Agent) protocols typically auto-enable across all agents in a deployment with no per-hop authorization—lateral movement between agents in the same deployment is architecturally possible. Identity is asserted at agent creation, not continuously attested per invocation. As multi-agent orchestration matures via supervisor patterns and A2A routing, closing the inter-agent authorization gap becomes the primary security work.

4. The Frameworks That Define the Landscape

4.1 OWASP Top 10 for Agentic Applications (2026)

Released December 2025 by 100+ security researchers under the OWASP GenAI Security Project, this is the most important new standard [27]. It defines ten risk categories specific to autonomous agent systems:

IDRisk
ASI01Agent Goal Hijack—prompt injection redirecting agent objectives
ASI02Tool Misuse—agents bending legitimate tools toward destructive outputs
ASI03Identity and Privilege Abuse—unauthorized access through compromised credentials
ASI04Agentic Supply Chain Vulnerabilities—poisoned dependencies, malicious models, compromised MCP servers
ASI05Excessive Agency—agents granted more autonomy than tasks require
ASI06Unsafe Defaults—insecure default configurations in agent frameworks
ASI07Insecure Inter-Agent Communication—spoofed messages between coding, review, and deploy agents
ASI08Cascading Failures—false signals propagating through automated pipelines
ASI09Human-Agent Trust Exploitation—polished AI explanations misleading human reviewers
ASI10Rogue Agents—compromised agents persisting across sessions

The framework introduces “least agency” as the governing principle—grant agents only the minimum autonomy required to perform safe, bounded tasks. This is the Zero Trust equivalent for agentic systems, and it should become a foundational principle in any security architecture supporting agentic capability.

4.2 NIST SP 800-218A (July 2024)

NIST’s Secure Software Development Framework extension for AI/GenAI mandates organizations verify the integrity, provenance, and security of AI models and AI-generated artifacts throughout their lifecycles [28]. Notably, this standard has a gap: it addresses the security of developing AI models but does not yet address the security of code produced by AI agents. That gap is where individual organizations must define their own posture.

4.3 CISA SBOM 2025 Minimum Elements

CISA’s 2025 update to Software Bill of Materials minimum elements explicitly includes a “generation context” field—tracking which agent, model version, and toolchain produced a given component [29]. The AI-BOM (AI Bill of Materials) concept extends this further to include the models, datasets, frameworks, and AI tooling used throughout development. Cycode’s November 2025 report found that 81% of security teams lack visibility into AI-generated code is the direct consequence of organizations not yet implementing AI-BOM practices [6].

4.4 MAESTRO (CSA, February 2025)

The Cloud Security Alliance’s MAESTRO framework provides layer-by-layer threat modeling specifically for agentic AI systems [30]. It has since been updated with CI/CD integration guidance and aligned to the OWASP Agentic Top 10. For any system that involves autonomous agents—including security review platforms themselves—MAESTRO is the right threat modeling framework, not STRIDE applied naively.

4.5 What Is Missing

The most significant gap in the current standards landscape is OWASP SAMM itself: SAMM has not yet introduced agentic-AI-specific practice streams. The January 2026 SAMM podcast “Navigating the AI Frontier” applies existing SAMM domains to AI-powered applications rather than introducing new agentic-native streams [31]. This matters because SAMM is the maturity model framework most security programs use to measure and improve. The concept of “Maturity Inflation”—in which a security program’s effective maturity score drops when agents generate 10x the code volume because review and validation processes have not scaled proportionally—is real and undocumented in any current maturity model. Most organizations are operating at lower effective maturity than their SAMM scores suggest.

5. The Meta-Security Problem: Validating Our Own AI Controls

An honest treatment of this topic requires confronting the recursive trust problem. When we deploy AI to perform security validation, we must ask: how do we know the AI security tools are working?

The data is less comfortable than vendor marketing suggests:

  • GPT-4o correctly classifies code correctness only 68.5% of the time [34]
  • DeepSeek-R1 achieves 67% accuracy on vulnerability detection, with F1 exceeding 70% only on structurally consistent categories [35]
  • The best models on professional-grade CTF security tasks (Cybench) reach only ~44% on subtask-guided tasks; Claude 3.5 Sonnet scores 43.9% subtask-guided and 17.5% on unguided tasks [36]
  • On Microsoft’s ExCyTIn-Bench for cybersecurity investigations, GPT-4o achieves ~29% average reward, GPT-4.1 achieves ~34%; GPT-5 High Reasoning achieves ~56% [37]

The adversarial robustness picture is mixed: one February 2026 study found that adversarial code comments had no statistically significant impact on AI detection performance (only ~5% to +4% change) [38]—which is encouraging. But structural blind spots persist regardless of adversarial manipulation: TOCTOU race conditions, timing-based authentication bypasses, and complex authorization logic remain systematically outside what current AI security tools can reason about [38].

The governance frameworks for validating AI security tools are nascent but available:

  • OWASP AISVS (AI Security Verification Standard): Testable, verifiable security requirements for AI-enabled systems, modeled after ASVS [39]
  • CSA Agentic AI Red Teaming Guide (May 2025): The most comprehensive hands-on guide for adversarially testing autonomous AI systems, covering agent authorization hijacking, hallucination exploitation, memory manipulation, and multi-agent exploitation [40]
  • NIST AI 600-1: GenAI risk profile within the AI RMF, emphasizing Test-Evaluation-Validation-Verification (TEVV) processes and drift detection [41]

The operational implication: AI security tools should be treated as force multipliers for human security judgment, not replacements for it. High-stakes decisions—production release authorization, exception granting, security architecture approval—should retain human validation even when AI agents have done the upstream work. The recursive trust problem does not have a clean technical solution yet. The human remains in the loop for final accountability, even as the human moves earlier in the process (requirements and design) rather than later (manual code review).

6. The AI Supply Chain: A New Attack Surface

I would be remiss not to address the attack surface that did not exist eighteen months ago. AI coding agents introduce novel supply chain risks that current SSDLCs do not address:

  • Dependency hallucination: AI agents invent nonexistent library names that attackers pre-register as malicious packages. USENIX research has documented this systematically, and it is not fixable by scanning known-bad packages—the package did not exist when the policy was written [42].
  • MCP server compromise: Trend Micro found over 8,000 MCP servers on the public internet, 492 with zero authentication and zero encryption [43]. Any coding agent connecting to an unauthenticated MCP server is a prompt injection risk. Socket detected active attacks using prompt injection via poisoned MCP servers targeting AI coding assistants in 2025 [44].
  • Malicious models: JFrog’s 2025 Software Supply Chain Report documented a 6.5× increase in malicious models on Hugging Face in 2024, with over 100 LLMs found containing hidden backdoors capable of executing malicious code [45]. Any AI tool in a development pipeline that uses third-party models is a supply chain risk.
  • Agent configuration poisoning: As documented in Section 3.1, the agent instruction files that define agent behavior are themselves attackable. A compromised .cursorrules or system prompt file has the same effect as a compromised dependency: everything produced by that agent is suspect.

Simon Willison’s “lethal trifecta” framework is the right mental model for evaluating any agentic system [46]. When three conditions co-occur—access to private data, exposure to untrusted content, and the ability to externally communicate—the system becomes a high-value target for prompt injection. As Bruce Schneier puts it plainly: “We have zero specific AI systems that are secure against these attacks” [47]. Practical mitigations exist—minimizing each trifecta element, sandboxing, allowlists, and human oversight [48]—but they remain compensating controls around an architectural vulnerability the research community has not yet fundamentally solved.

For any security orchestration platform: as agentic capabilities embed into security review infrastructure, every MCP connection, every third-party model dependency, and every agent instruction file is part of the attack surface and should be scoped, governed, and monitored accordingly.

7. What Needs to Change

7.1 The SSDLC Policy Needs an Agentic Annex

Most current SSDLC policies are well-structured for human-centric development. They need an annex—or a replacement section—that addresses agentic development explicitly. The key additions:

  • AI-BOM requirements: Any application that uses AI coding agents or AI-generated components must maintain an AI Bill of Materials documenting the agents, models, and tool configurations involved. This is now a CISA-aligned requirement, not an optional practice.
  • Agent identity and permission governance: AI coding agents authorized to commit code, create PRs, or interact with production systems must be registered as principals with defined permissions, credential scopes, and access expiration. Agents are not tools; they are principals.
  • Iterative validation requirements: For development workflows involving multi-agent sessions, security re-validation is required at minimum every five iterations, not only at commit boundaries—based on the IEEE-ISTAS 2025 degradation data [5].
  • Agent configuration integrity controls: Files that define AI agent behavior (system prompts, rules files, MCP configurations) must be version-controlled, require security review on change, and be subject to integrity verification in CI/CD.
  • Agentic threat modeling coverage: MAESTRO threat modeling is required for any system that includes autonomous agents with internet connectivity, access to sensitive data, or tool invocation capabilities.

7.2 Security Review Platforms Should Orchestrate Agents, Not Just Track Humans

Unified security review platforms should be designed to unify security review activities and track progress toward production readiness. That vision is correct. But the execution model embedded in most current thinking—routing work to human security domain specialists, collecting their findings, synthesizing a release decision—is already at risk of being obsoleted by the same agentic development practices the platform is meant to govern.

The reframe: a platform’s control validation engine should orchestrate security agents to continuously validate posture, not collect artifacts from humans to prove controls were performed.

Concretely:

  • Instead of “submit threat model for review” → an AI threat modeling capability generates and continuously updates the threat model from code and architecture artifacts; the platform tracks its current finding state
  • Instead of “architecture review engagement” → an AI architecture-evaluation capability runs at intake and updates as the design evolves; the platform surfaces open security requirements as a live posture indicator
  • Instead of “code scanning completed” → agent-assisted fix workflows are embedded in CI/CD; the platform tracks unresolved findings and fix acceptance rates
  • Instead of “penetration test completed” → Autonomous Attack Simulation (AAS) agents run continuously in pre-production; the platform tracks the live attack surface

The human security team’s role shifts from reviewers who perform controls to architects and exception handlers who set policy, validate high-stakes decisions, and govern the agents doing the work.

7.3 AI Threat Modeling Should Become Ambient

The highest-value evolution of AI threat modeling is moving it from an engagement-triggered tool to an ambient service that runs continuously in the development flow. The specific integrations that matter:

  • MCP exposure: AI threat modeling as an MCP resource that coding agents (Cursor, Claude Code, Copilot) can query during code generation—“does this design decision introduce threats?” asked and answered in the generation loop, not weeks later
  • CI/CD pipeline step: AI threat modeling as a CI/CD action that runs on every PR, compares current architecture against the threat model, and flags drift as a blocking finding
  • Intake integration: AI threat modeling consuming PRD and architecture analysis as input context, so threat models are seeded from the security requirements identified at intake

7.4 AI Intake Evaluation Should Produce Machine-Readable Security Policy

AI-powered PRD and architecture evaluation today typically produces human-readable feedback. Its highest-value evolution is producing machine-readable security policy that downstream agents and pipelines can consume programmatically. When the intake evaluator identifies a security requirement, that requirement should become a structured artifact that the CI/CD pipeline enforces, the embedded coding agents validate against, and the security review platform tracks as an open finding until resolution.

7.5 The Controls That Should Go Away

Not everything in the current SSDLC needs to evolve. Some of it should be retired:

  • Manual threat modeling as a pre-code gate: Replaced by continuous AI threat modeling
  • Sequential security domain handoffs: Replaced by parallel, orchestrated control validation
  • Architecture review as a separate human engagement for standard architectures: Replaced by AI intake evaluation and continuous AI threat modeling; human architecture review reserved for novel patterns and high-risk exceptions
  • Point-in-time penetration testing as a gate for systems with continuous AAS coverage: Replaced by continuous autonomous attack simulation; human pentesting reserved for novel threat surfaces and regulatory requirements
  • Requesting the same information from developers multiple times across security domains: Developer-provided context should be ingested once at intake and routed to all required security functions—eliminating the redundant handoffs that have long been the primary friction point in the review process

8. Conclusion

The SDLC as we have known it is not dead. The ceremonies of the SDLC—the sequential phase gates, the human-gated reviews, the siloed domain engagements—are being compressed out of existence by agentic development velocity. The functions those ceremonies served—understanding what to build, evaluating risk, validating correctness—are being redistributed to autonomous agents operating continuously throughout the development flow.

Security has to make the same transition. The practitioners and researchers who claim “AppSec is dead” are wrong about the discipline; they are right about the ceremonies. Vulnerability detection, threat analysis, runtime validation, and defense in depth are not going away. The episodic, gate-based, human-bottlenecked model for performing them is.

The organizations that will navigate this transition best are the ones that already have AI-powered evaluation operating at intake and AI-powered threat modeling operating continuously—and that recognize the work ahead is to connect those capabilities into a unified, agent-orchestrated security posture, with the orchestration layer that ties them together.

The research is unambiguous about the direction. The question is whether we move toward it intentionally, designing the agentic security architecture we want, or reactively, trying to adapt our existing model after it has already failed. I believe we are capable of the former, and this paper is my argument for why the discipline should commit to it now.

References

  1. Gartner. “Gartner Predicts 40 Percent of Enterprise Apps Will Feature Task-Specific AI Agents by 2026.” August 2025.
  2. Checkmarx. “AI is Writing Your Code—Who’s Keeping It Secure? (2025 CISO Guide to Securing AI-Generated Code).” 2025.
  3. Zhao, Songwen et al. “Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks.” arXiv:2512.03282. 2025.
  4. Endor Labs. “State of Dependency Management 2025.” 2025.
  5. IEEE-ISTAS. “Security Degradation in Iterative AI Code Generation.” arXiv:2506.11022. 2025.
  6. Cycode. “Shadow AI Crisis Looms as 100% of Companies Have AI-Generated Code But 81% of Security Teams Lack Visibility.” BusinessWire. November 2025.
  7. Arnica. “2026 AppSec Predictions: The Year We Confront AI Reality.” 2026.
  8. Semgrep. “Announcing AI Noise Filtering and Triage Memories.” January 2025.
  9. Snyk. “The Next Era of AppSec: Why AI-Generated Code Needs Offensive Dynamic Testing.” 2026.
  10. Sifting the Noise: LLM Agents in Vulnerability False Positive Filtering. arXiv:2601.22952. January 2026.
  11. Shostack, Adam. “Threat Modeling Intensive With AI” (training description). OWASP Global AppSec USA 2025. November 3–5, 2025. https://owaspglobalappsecusa2025.sched.com/event/27cXe
  12. Escape.tech. Referenced in “Awesome Agents AI, Vibe Coding: 69 Vulnerabilities Found.” 2026.
  13. IBM. “Beyond Shift Left: How ‘Shifting Everywhere’ With AI Agents Can Improve DevOps.” 2025.
  14. GitGuardian. “Shifting Security Left for AI Agents: Enforcing AI-Generated Code Security with GitGuardian MCP.” 2026.
  15. Security Compass. “Announcing a New Era for Security Compass” (SD Elements MCP integration). 2026.
  16. Cycode. “Cycode Unveils Agentic Development Security Platform.” GlobeNewsWire. March 2026.
  17. Pillar Security. “New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents.” 2026.
  18. Arnica. “Bypassing Cursor Agents Guardrails Through a Script Inspection Design Flaw.” 2026.
  19. GitHub. “Secure Code More Than Three Times Faster with Copilot Autofix.” 2025.
  20. Snyk. “DeepCode AI Platform.” 2025.
  21. Agrawal, Vaibhav and Klarash Ahi. “LLM-Driven SAST-Genius: A Hybrid Static Analysis Framework for Comprehensive and Actionable Security.” arXiv:2509.15433. 2025.
  22. Checkmarx. “Checkmarx Enables Real-Time Code Security with Launch of Developer Assist Agent for AI-Native IDEs.” 2026.
  23. Finzi, Yair. “AI Agents Are Turning Security Inside-Out.” Help Net Security. January 2026.
  24. Red Hat. “Zero Trust for Autonomous Agentic AI Systems: Building More Secure Foundations.” February 2026.
  25. Microsoft. “Secure Agentic AI End-to-End.” March 2026.
  26. CrowdStrike. “Securing AI-Generated Code with Multiple Self-Learning AI Agents.” 2026.
  27. OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications 2026.” December 2025.
  28. NIST. “Secure Software Development Practices for Generative AI and Dual-Use Foundation Models (SP 800-218A).” July 2024.
  29. CISA. “2025 Minimum Elements for a Software Bill of Materials (SBOM).” August 2025. https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
  30. Cloud Security Alliance. “MAESTRO: Agentic AI Threat Modeling Framework.” February 2025.
  31. OWASP SAMM. “Navigating the AI Frontier: How OWASP SAMM Secures the Next Generation of Software.” January 2026.
  32. Fortune. “Invictus / ThreatModeler Acquires IriusRisk.” January 2026.
  33. Apiiro. “Apiiro Redefines Design Phase Security with AI Threat Modeling Built for the AI Coding Agent Era.” GlobeNewsWire. March 2026.
  34. arXiv. “Evaluating LLMs for Code Review.” arXiv:2505.20208. 2025.
  35. ACM. “LLMs in Software Security: A Survey.” 2025.
  36. Zhang, Andy et al. “Cybench: A Framework for Evaluating Cybersecurity Capabilities and Risks of Language Models.” UC Berkeley / Stanford RegLab et al. arXiv:2408.08926. ICLR 2025.
  37. Microsoft Security Blog. “Microsoft Raises the Bar: A Smarter Way to Measure AI for Cybersecurity.” October 2025.
  38. arXiv. “Can Adversarial Code Comments Fool AI Security Reviewers?” arXiv:2602.16741. February 2026. https://arxiv.org/pdf/2602.16741
  39. OWASP. “OWASP AI Security Verification Standard (AISVS).” 2025.
  40. Cloud Security Alliance. “Agentic AI Red Teaming Guide.” May 2025.
  41. NIST. “AI Risk Management Framework: Generative AI Profile (AI 600-1).” July 2024. https://doi.org/10.6028/NIST.AI.600-1
  42. Spracklen, Joseph et al. “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs.” USENIX Security Symposium 2025. arXiv:2406.10279.
  43. Trend Micro. “MCP Security: Network-Exposed Servers Are Backdoors to Your Private Data.” 2025.
  44. Invariant Labs. “MCP Security Notification: Tool Poisoning Attacks.” 2025.
  45. JFrog. “JFrog Enables Trusted AI: Uncovers Critical Security Threats Emerging from AI’s Expansion in the Software Supply Chain” (press release on Software Supply Chain State of the Union 2025). April 2025.
  46. Willison, Simon. “The lethal trifecta for AI agents: private data, untrusted content, and external communication.” June 16, 2025.
  47. Schneier, Bruce. “We Are Still Unable to Secure LLMs from Malicious Inputs.” Schneier on Security. August 27, 2025.
  48. Saetsma, Korny. “Agentic AI and Security.” martinfowler.com. October 28, 2025.

All URLs verified as of April 28, 2026.