Best-in-class deepfake detectors claim 94–96% accuracy in controlled lab conditions. Independent research shows real-world accuracy against novel generation models falls below 50% — statistically equivalent to a coin flip. That gap is why satisfying the EU AI Act Article 50 compliance deadline for AI content disclosure is more complicated than the headline numbers suggest. This article is part of our comprehensive AI content authenticity and watermarking mandate series, where we examine both the regulatory requirements and the technical limits of compliance.
The gap comes down to how detection classifiers are built — and every new generation architecture makes it worse.
Microsoft Research’s MNW benchmark, published in IEEE Intelligent Systems in early 2026, is the largest collaborative benchmark assembled to date trying to document and close that gap. It’s worth understanding before you evaluate vendors, buy detection tooling, or build a compliance strategy around detection alone.
Detection has genuine value. But it has hard limits. And those limits have a second-order consequence that makes detection-only strategies self-defeating even if accuracy improves. That consequence is the liar’s dividend. We’ll get to that.
The 94–96% accuracy figures in vendor marketing are real — under specific conditions. Those conditions matter enormously.
Lab accuracy is measured against generation models the detector was trained on, using test sets drawn from the same distribution as training data. When Resemble AI’s DETECT-3B claims top ranking on the Podonos Audio DFD benchmark — image detection above 99% on StyleGAN and 98% on DALL-E 3 — those figures are meaningful within that benchmark’s scope. Reality Defender similarly positions itself as the enterprise standard for multi-format synthetic media detection.
The 80–90% figure you see in cross-vendor industry summaries is a more conservative average across diverse test conditions. The Deepfake-Eval-2024 benchmark, built on “in the wild” deepfakes, documents AUC drops of 50% for video, 48% for audio, and 45% for images compared to prior benchmarks.
iProov’s research puts human deepfake detection accuracy at 0.1%. Automated detectors at 80–90% are a genuine improvement over unaided human review. But what vendor accuracy claims actually mean in practice requires a lot more scrutiny than headline figures provide.
Any accuracy figure needs to be evaluated against its test-set assumptions. What generation models were in the training data? A 96% accuracy figure against 2023 GAN-generated faces says almost nothing about performance against 2026 diffusion-model video synthesis.
Deepfake classifiers learn statistical artefacts specific to the generation architecture they were trained on — not the abstract concept of “fakeness.” GAN-generated content leaves characteristic frequency-domain patterns. Diffusion models produce outputs with different statistical signatures, or none of the signatures a GAN-trained detector was built to find.
When a detector encounters deepfakes produced with tools it was not trained against, performance drops below 50% — the binary classifier collapses toward chance. A system achieving 94% accuracy against 2023 GAN outputs can perform near-randomly against 2026 diffusion-model outputs from Sora equivalents, HeyGen, or Synthesia.
Research from the University of Edinburgh (2025) and MIT Media Lab corroborates this independently. Deepfakes produced with HeyGen, Synthesia, and ElevenLabs are indistinguishable from genuine content in 70–85% of cases even for experienced viewers. A MIT Media Lab study of 2,215 participants found that state-of-the-art text-to-speech audio deepfakes are already harder to distinguish than audio produced by a voice actor.
GAN architecture pits a generator against a discriminator. The same adversarial logic applies to detection: every published detector becomes the next discriminator the next generation model trains to defeat. Diffusion models — Stable Diffusion, DALL-E 3, Sora 2, Runway Gen-3 — produce outputs with a fundamentally different statistical profile. Less face-swap artefact, fewer of the frequency-domain signatures GAN detectors were trained on.
The International AI Safety Report 2026 confirms detection benchmarks perform about 50% worse on real-world deepfakes than on the evaluation datasets used to assess them. That’s a structural consequence of how classifiers generalise — not a vendor-specific data quality issue.
The Microsoft-Northwestern-WITNESS (MNW) deepfake detection benchmark, published in IEEE Intelligent Systems (vol. 41, no. 02, pp. 15–23), is the largest collaborative deepfake benchmark assembled to date. The dataset contains more than 50,000 artefacts — images, videos, and audio files — generated by the research team plus real-world examples collected by journalists and human rights defenders globally.
The MNW paper’s premise says more about the state of detection than any vendor benchmark. Its GitHub repository states: “Previous approaches to detection are now obsolete and the detection scene must re-invent itself.” Earlier GAN-era datasets from Meta (2020) and the UK government (2024) “had a lot of depth but almost no breadth” and are “not up to the challenge brought by the new generative AI landscape.”
Microsoft Research, Northwestern University (V. S. Subrahmanian), and Witness (Sam Gregory, Shirin Anlen) built MNW to address training-data breadth — collecting diverse samples across multiple generators to improve generalisation. The dataset is periodically updated and includes adversarial examples created with state-of-the-art attack methods.
Microsoft is making a substantial detection investment while publishing research that documents why detection cannot be the complete solution. IEEE Spectrum’s coverage (May 2026) confirmed MNW is intended to reflect “the current AI-generation landscape as much as possible.” Microsoft also recommends that organisations evaluating commercial detection tools avoid using MNW for vendor evaluations — it’s a reference standard, not a procurement instrument.
For context on how governments are responding to the accuracy ceiling, the MNW architecture is central to understanding what is technically feasible at national scale.
Adversarial attacks are small, deliberate modifications to deepfake content that cause detection classifiers to output the wrong prediction. They don’t require access to the detector’s model weights. Black-box attacks work by querying only the detector’s inputs and outputs — the attacker needs nothing more than the ability to submit content and observe the result.
A 2024 study on adversarial attacks against deepfake detectors demonstrated that lightweight attacks based on simple 2D convolutional filters are sufficient to bypass state-of-the-art facial detection systems. Adversarial training defences reach 94.1% accuracy and randomised smoothing reaches 92.8% — but only against attack types known at training time. Novel attack patterns arriving after training defeat those defences at normal rates.
A 2025 University of Edinburgh study found that AI fingerprints — the statistical traces left by generative models — can be removed with adversarial post-processing. Worse, those fingerprints can be transplanted onto authentic content to misclassify real material as synthetic.
Multi-engine detection reduces false-negative rates compared to a single classifier. It doesn’t solve the structural problem. A deepfake produced with a generation tool not represented in any of the ensemble’s training sets escapes all engines simultaneously. The WEF’s 2025 detection analysis concluded that “the race between deepfake creation and detection systematically favours attackers” — not as a temporary setback, but as a property of the problem.
The asymmetry is the core issue. Generating an adversarial attack is computationally cheap; retraining a detection classifier against it is expensive and slow. Stable Diffusion released five major versions in 24 months. Sora went from v1 to v2 in nine months. Detectors train on cycles measured in months — and by the time they reach production, the generation side is already a version ahead. Evaluating vendor adversarial robustness claims requires understanding that iteration gap.
The Microsoft-Northwestern-WITNESS collaboration is the training-data hypothesis applied at scale: if classifiers fail against novel generation models because training data was insufficiently diverse, a large and continuously updated dataset should improve generalisation across architectures.
MNW’s 50,000+ artefacts are drawn from multiple generators and include content collected by Witness, a nonprofit that supports human rights defenders and journalists who encounter AI-manipulated media in the field. A browsable dataset navigator launched in a spring 2026 V 2.0 update at microsoft.github.io/MNW — a signal of ongoing iteration rather than a fixed benchmark.
Why is MNW still insufficient despite all that? Because training-data improvements reduce the generalisation gap but cannot eliminate it. New generation models not represented in the training corpus will still cause accuracy to degrade. The classifier-generalisation problem is not purely empirical — it’s mathematically bounded. Better data is necessary, but it is not sufficient.
When a research team that has invested at this scale simultaneously publishes findings acknowledging detection’s structural limits, that is the clearest available signal that provenance cannot be optional. The UK national detection system architecture illustrates what that looks like at government scale.
Bobby Chesney and Danielle Citron coined the term “liar’s dividend” in their 2019 paper “Deep Fakes: A Looming Challenge for Privacy, Democracy, and National Security” in the California Law Review. The concept describes a second-order consequence of widespread deepfake awareness: once the public knows deepfakes exist, any genuine recording can be dismissed as “probably AI-generated.”
This isn’t a hypothetical future problem. In 2018, a real video of Gabonese President Ali Bongo was publicly accused of being a deepfake during a political health crisis. January 6 defendants in Washington challenged authentic audio recordings as “AI generated.” Detection tools return probabilistic results — and a probability does not eliminate reasonable doubt in a legal proceeding.
85% of Americans say they are “very concerned” or “somewhat concerned” about misleading deepfakes (YouGov, August 2023). That level of public awareness is precisely what enables the liar’s dividend. The more successfully detection raises awareness, the more it arms bad actors with a plausible deniability script for real evidence.
The only technical countermeasure is source certification: a cryptographic seal applied at the moment of capture, before distribution, establishing a provable chain of custody. That chain makes the claim “it could be a deepfake” demonstrably false for certified content — not probabilistically unlikely, but cryptographically falsifiable.
Detection-only compliance strategies fail the liar’s dividend test even at 90%+ accuracy. The EU mandate that drove this urgency reaches the same conclusion from the legislative side.
Detection has genuine value. It catches unsophisticated deepfakes. It raises the cost of circulating unmodified AI-generated content undetected. It scales to contexts where provenance infrastructure is not yet present. None of that disappears because of an accuracy ceiling.
Provenance-first approaches — C2PA, perceptual watermarking, source certification — answer a different question: where did this content come from, and was it tampered with after capture? Those are different architectural problems with different architectural answers.
The complementary model is straightforward. Provenance establishes the chain of custody for legitimate content; detection catches content where provenance is absent or was not applied. Neither approach is complete without the other. For a full overview of how these approaches fit together against the regulatory backdrop, see the complete guide to AI watermarking compliance.
C2PA is gaining hardware-level adoption — Samsung Galaxy S25 and Google Pixel 10 now sign content natively through C2PA at the moment of capture. Platforms including LinkedIn, TikTok, and Cloudflare support or preserve credentials at scale. That infrastructure has a documented limitation: metadata can be stripped on re-encoding. Being honest about both sides is how you build a durable architecture rather than a compliance checkbox.
The International AI Safety Report 2026 confirms this directly: a combination of mitigations — watermarking, provenance, and detection — within a broader ecosystem of standards can compensate for their respective limitations. No single approach suffices.
EU AI Act Article 50(2) requires that providers of systems generating synthetic content mark that content in a machine-readable format, with enforcement beginning August 2026. The regulation doesn’t mandate detection as the compliance mechanism — it mandates the provenance approach. The penalty for non-compliance is €15 million or 3% of global annual turnover.
The implication is architectural. If you are generating synthetic content, implement provenance — C2PA, watermarking, or source certification — at generation time rather than relying on detection tooling alone. Purchasing detection as your only compliance mechanism doesn’t satisfy the regulation and doesn’t solve the structural problem. The watermarking mandate and detection challenge — including the technical approaches, vendor landscape, and implementation timeline — is covered in full across this series.
No. The 80–90% figure represents a cross-vendor average under lab conditions; real-world performance against novel generation models drops below 50%. EU AI Act Article 50 compliance requires machine-readable provenance disclosures — detection is not the mandated mechanism. An 80% detection rate also means 1 in 5 deepfakes pass undetected, which is not a defensible compliance posture.
An adversarial attack adds imperceptible modifications to a deepfake — pixel-level noise, targeted compression artefacts, resampling at specific frequencies — that disrupt the statistical signals a classifier relies on, causing it to label fake content as real. Black-box attacks work without access to the model’s weights. The attacker only needs the ability to submit content and observe the output.
Multi-engine detection reduces false-negative rates relative to a single classifier but does not eliminate the structural accuracy ceiling. Adversarial attacks can be tuned against combined systems. Distribution shift from novel generation models affects all classifiers trained on the same historical data, regardless of how many are combined.
No detection method is fully adversarially robust. Source certification — cryptographic sealing at point of capture — is not a detection method; it is a provenance method. It defeats adversarial manipulation differently: by proving content was unmodified before distribution, rather than detecting modification after the fact. For content that was never authenticity-certified at source, no detection approach provides adversarial guarantees.
MNW (Microsoft-Northwestern-WITNESS) is a collaborative deepfake detection dataset assembled by Microsoft Research, Northwestern University, and Witness. It contains more than 50,000 artefacts and is published in IEEE Intelligent Systems (2026). The dataset is intentionally built from multiple generators and is periodically updated to cover emerging generation models — the most diverse training corpus of its kind assembled to date.
The liar’s dividend is a social consequence, not a technical one. Even at 99% detection accuracy, widespread awareness that deepfakes exist allows anyone to deny authentic recordings as “probably AI-generated.” Detection answers “is this fake?” — it cannot prove “this real content was never manipulated” with chain-of-custody guarantees. Only source certification provides that.
EU AI Act Article 50 Watermarking — What the August and December 2026 Deadlines Actually RequireArticle 50 of the EU AI Act sets out transparency and disclosure obligations for AI systems serving EU users, with a primary enforcement date of August 2, 2026. Most coverage treats this as a single watermarking requirement that either has or hasn’t been pushed back by the Digital Omnibus.
It’s more complicated than that. The Digital Omnibus provisional agreement, reached on 7 May 2026, moved Article 50(2) machine-readable marking — and only that obligation — to December 2, 2026. Article 50(1), 50(3), and 50(4) are still on August 2. Annex III high-risk AI systems are on a completely separate track: December 2, 2027.
So in this article we’re going to cover what Article 50 actually requires, which deadline applies to which obligation, what the Digital Omnibus really changed, who is in scope, and how California SB 942 fits if you’re a US-based company. This guide is part of our comprehensive AI content authenticity and watermarking mandate series, where we explore the full regulatory, technical, and implementation landscape.
Let’s get into it.
Article 50 creates four separate obligations. Different actors carry different ones — and they cover different types of AI interactions.
Article 50(1) applies to providers of interactive AI systems — chatbots, voice assistants, agentic AI. The obligation is to tell users they’re dealing with an AI at the point of interaction. Not buried in terms of service. There’s an exception where it’s obvious from context, but a natural-language customer service chatbot doesn’t automatically qualify.
Article 50(2) applies to providers of AI systems generating synthetic audio, images, video, or text. The obligation is to implement machine-readable marking — embedded provenance data that downstream systems can detect as AI-generated. The regulation is specific: the marking must be interoperable, detectable, and robust. A visible “AI-generated” label doesn’t satisfy Article 50(2).
Article 50(3) applies to deployers of emotion recognition or biometric categorisation systems. They need to tell individuals when such a system is processing them.
Article 50(4) applies to deployers who publish deepfakes or AI-generated text on matters of public interest. The obligation is disclosure of the artificial origin at publication. The Act defines deepfakes broadly under Article 3(60): AI-generated or AI-manipulated image, audio, or video depicting existing or non-existing persons, places, or events that would falsely appear authentic. A synthetic video of a non-existent person can trigger Article 50(4).
One thing worth getting straight: “watermarking” gets used loosely in most coverage. The legal obligation in Article 50(2) is machine-readable marking. Watermarking is one technical method among several — alongside metadata embedding (XMP/IPTC) and cryptographic provenance via C2PA.
Three of the four Article 50 obligations land on August 2, 2026: Article 50(1) interactive AI disclosure, Article 50(3) emotion recognition transparency, and Article 50(4) deepfake and public-interest text disclosure. That date has not changed. The Digital Omnibus didn’t touch it.
Article 50(2) — machine-readable marking — is the one obligation that got transitional relief. Under the Digital Omnibus provisional agreement, the planning date moves to December 2, 2026.
There’s a planning risk here worth flagging. The Digital Omnibus is a provisional political agreement as of June 2026 — not formally adopted, not yet published in the Official Journal. Gibson Dunn reports formal adoption is expected before August 2, but it isn’t done. If adoption is delayed past August 2, Article 50(2) reverts to the August 2 baseline. Keep an eye on formal adoption status if you’re relying on the December date.
The Annex III high-risk AI deadline — December 2, 2027 — is a completely separate track. A system can trigger Article 50 obligations without being an Annex III high-risk system, and vice versa.
Here’s the deadline split in plain terms:
Trilogue negotiations wrapped up on 7 May 2026, with Council confirmation on 13 May. Formal adoption and publication in the Official Journal are still pending as of June 2026.
What changed: targeted transitional relief for Article 50(2) machine-readable marking specifically. The planning date moves from August 2 to December 2, 2026, provided formal adoption happens in time.
What didn’t change: Article 50(1), 50(3), and 50(4) remain on August 2, 2026. Chatbot identification, emotion recognition transparency, and deepfake disclosure are not deferred. Business press has widely reported the Digital Omnibus as a general AI Act extension — that framing is incorrect. The majority of Article 50 obligations are unaffected.
The Annex III high-risk AI changes are also part of the Digital Omnibus — enforcement is pushed back to December 2, 2027, a 16-month delay. Significant for many organisations. But again, it’s a separate track from Article 50.
Two things drove the Article 50(2) change. No harmonised technical standards existed for machine-readable marking, and pressure from member states — Germany cited as a key driver — pushed for workable timelines before enforcement kicked in.
The practical takeaway: keep Article 50 readiness work moving for August 2 obligations while tracking the December date separately for Article 50(2). For a structured implementation approach, see the 12-week implementation timeline for organisations in scope.
Scope comes down to two things: whether you’re a provider or deployer under the Act, and whether your AI systems generate or process the content types each sub-obligation covers.
The EU AI Act has extraterritorial reach. Article 2(1) covers providers placing AI systems on the EU market regardless of where they’re headquartered, deployers within the EU, and providers or deployers in third countries where AI system output is used in the EU. Where your customers are located matters as much as where you’re based.
A provider develops or places an AI system on the market under its own name or trademark. Providers carry Article 50(1) and Article 50(2) obligations — chatbot disclosure and machine-readable marking.
A deployer uses an AI system built by someone else, under its own authority, to serve users. Deployers carry Article 50(3) and Article 50(4) obligations — emotion recognition transparency and deepfake disclosure at publication. A business can be both simultaneously.
The common blind spot is API integrators. If you’re building on GPT-4, Claude, or Gemini, you’re typically a deployer. You can’t assume the GPAI provider’s capabilities satisfy your deployer obligations. If you control the user experience and decide how AI outputs are presented, you carry deployer obligations — full stop.
The quick scope check: Does your system generate synthetic audio, image, video, or text for EU users? Does it interact with EU users as a chatbot or voice assistant? Does it publish AI-generated content on public interest matters? Does it process emotion recognition or biometric categorisation data? If yes to any of these, you’re in scope. For the broader compliance picture, see our watermarking mandate overview.
These are different obligations for different actors, and both can apply to the same organisation.
Article 50(2) is a provider obligation: build machine-readable marking into the AI system itself. The regulation doesn’t prescribe a specific technical standard, but the marking must be “effective, interoperable, robust, and reliable.”
Three main technical approaches can satisfy this. Metadata embedding (XMP, IPTC formats) is the most mature, already widely deployed in photography and publishing. Invisible watermarks are imperceptible to humans but detectable by specialised tools. Cryptographic provenance via C2PA creates a tamper-evident chain of custody — adoption is accelerating at the hardware level, with Samsung Galaxy S25 and Google Pixel 10 signing content natively at capture.
For a technical comparison, see which technical approach satisfies Article 50(2). And it’s worth understanding first why detection alone cannot satisfy the mandate.
Article 50(4) is a deployer obligation. When you publish deepfakes or AI-generated text on matters of public interest, you disclose the artificial origin at publication — a clearly visible label. The “public interest” scope is broader than most assume: it covers public administration, fundamental rights, health, the environment, and economic, political, scientific, or cultural developments.
There’s an editorial review exception: if AI-generated public interest text has undergone genuine, substantive human editorial review with clearly attributable editorial responsibility, disclosure isn’t required. But the exception is narrow. A cursory check before publishing doesn’t qualify. Marketing copy gets no exception.
Most organisations subject to both obligations need both: a machine-readable provenance mechanism for Article 50(2), and a user-facing disclosure for Article 50(4).
If your company is headquartered in the US and serves EU users, you’re dealing with two separate frameworks.
California SB 942 (AI Transparency Act), as amended by AB 853, became operative on August 2, 2026 — deliberately aligned with the EU AI Act’s enforcement date. SB 942 applies to “covered providers” with more than one million monthly users in California. It requires a free publicly accessible AI detection tool, visible labelling options, and latent disclosure in all AI-generated image, video, or audio.
The key difference is scope. SB 942 targets providers only — it doesn’t impose independent obligations on deployers. The EU AI Act targets both providers and deployers independently.
As one analysis puts it: “Where California focuses on consumer-facing transparency as a rights mechanism, the EU AI Act focuses on technical transparency as a compliance mechanism.” SB 942 compliance doesn’t satisfy Article 50. The obligation holders differ, the technical forms differ, and the standards differ.
SB 942 penalties are $5,000 per violation per day. EU AI Act Article 50 violations sit at EUR 15 million or 3% of global annual turnover, whichever is higher.
One common planning mistake worth calling out: treating SB 942 as the full picture of California AI transparency. It covers only large GenAI providers — it doesn’t govern automated decision-making, employment AI, or CPPA ADMT obligations. Audit each framework separately.
Article 99(4)(g) puts Article 50 transparency violations in the maximum fine tier: EUR 15 million or 3% of total worldwide annual turnover, whichever is higher. Same tier as GDPR maximum fines.
Enforcement sits with national market surveillance authorities in EU member states. Beyond fines, they can order non-compliant systems withdrawn from the market.
There’s also a documentation risk. If your organisation can’t demonstrate when and how it implemented disclosure mechanisms, regulators default to the assumption of non-compliance. The practical mitigation is a Transparency Decisions Register: record for each AI system the disclosure mechanism, implementation date, approver, and rationale for any exception claims. Start that now.
The Article 50 Code of Practice on marking and labelling is voluntary — second draft published March 5, 2026. Adherence doesn’t substitute for legal compliance, but signatories get a recognised compliance pathway and a lighter evidentiary burden.
If you haven’t started Article 50 preparation, here are the priorities: determine whether you’re a provider, deployer, or both; identify which AI systems generate synthetic content for EU users or interact with EU users; confirm which August 2 obligations apply. For a structured implementation approach, see the 12-week implementation timeline for organisations in scope.
Partially. The Digital Omnibus provisional agreement targets only Article 50(2) machine-readable marking — moving its planning date to December 2, 2026. Article 50(1), 50(3), and 50(4) remain on August 2, 2026. The Digital Omnibus is a provisional political agreement as of June 2026 — not yet formally enacted. If adoption is delayed past August 2, Article 50(2) reverts to the August 2 baseline.
Yes. The EU AI Act has extraterritorial reach. Any provider or deployer placing AI systems on the EU market or operating AI systems for EU users must comply regardless of where the company is incorporated. Even free-tier SaaS products accessible to EU residents trigger obligations.
GPAI model providers (OpenAI, Anthropic) carry their own Article 50(2) obligation to build marking support into their API outputs. Companies integrating GPAI APIs are typically deployers — they carry Article 50(4) obligations independently. Deployers cannot assume their GPAI provider’s compliance satisfies their own obligations.
Both obligations exist. Article 50(4) requires disclosure at publication — a visible label can satisfy this. Article 50(2) requires machine-readable marking embedded in the content — a visible label alone does not satisfy it. Most organisations subject to both need both.
Article 50 transparency: August 2, 2026 for most obligations; December 2, 2026 for Article 50(2) under the Digital Omnibus. Annex III high-risk AI: December 2, 2027 — a completely separate track. A system can trigger Article 50 obligations without being an Annex III high-risk system.
Article 3(60) defines deepfakes as AI-generated or AI-manipulated image, audio, or video depicting existing or non-existing persons, places, objects, or events that would falsely appear authentic. The definition is broader than common usage — a synthetic video of a non-existent person could trigger Article 50(4). Content that is clearly unrealistic falls outside the definition.
Only in narrow circumstances. The exception requires genuine, substantive human editorial review with clearly attributable editorial responsibility. Cursory review or automated quality checks don’t qualify. Marketing copy and product descriptions get no exception.
Provider: you develop the AI system or place it on the market under your own name or trademark. Deployer: you use an AI system built by someone else, under your own authority, to serve users. API integrators building on GPAI models are typically deployers. If you control the user experience and decide how AI outputs are presented to end users, you carry deployer obligations.
The Code of Practice is a voluntary multi-stakeholder instrument facilitated by the EU AI Office. Adherence does not substitute for legal compliance — but signatories benefit from a recognised compliance pathway and lighter evidentiary burden.
GDPR and Article 50 are independent obligations. Compliance with one does not satisfy the other. Both may apply simultaneously if your AI system processes personal data of EU users. Coordinate Article 50 disclosures with GDPR transparency notices to avoid inconsistency.
Three priorities: determine whether you’re a provider, deployer, or both; identify which AI systems generate synthetic content for EU users or interact with EU users; confirm which August 2 obligations apply. For Article 50(2), you have until December 2, 2026 under the Digital Omnibus — but monitor formal adoption. Start a Transparency Decisions Register now. See the 12-week implementation timeline for organisations in scope for a structured approach.
No. SB 942 requires large GenAI providers to make watermarking tools available. Article 50(2) requires actual implementation of machine-readable marking. SB 942 compliance does not cover your independent obligations as a deployer under Article 50.
For a complete overview of the regulatory, technical, and vendor landscape — including how the detection accuracy ceiling affects compliance strategy and how to evaluate technical approaches against Article 50(2) requirements — see the complete guide to AI watermarking compliance.
OWASP AI Testing Guide: What the Standard RequiresSearch for “OWASP AI testing guide” and you land on a sprawling family of documents, not a single PDF. It’s worth clearing that up before your team implements controls from the wrong publication — or misses the one that actually applies to what you’re building.
The OWASP GenAI Security Project is home to all current AI security guidance from OWASP. And for teams with EU exposure, the EU AI Act’s enforcement of high-risk AI provisions starting August 2026 turns this guidance from advisory into something auditors will be checking for. This article maps what each publication requires, what’s new in the agentic list, and how it translates to an audit checklist. It is part of a broader series on the AI code security requirements engineering teams now face.
There’s no single document with that title. The OWASP AI Security and Privacy Guide is where searches often land, but it’s a foundational overview page, not testing guidance. The actual testing guidance lives across the OWASP GenAI Security Project’s publications at genai.owasp.org.
What the project publishes includes the OWASP Top 10 for LLM Applications, the OWASP Top 10 for Agentic Applications 2026, the Secure MCP Server Development Guide, the AIBOM Generator, and the Q2 2026 Red Teaming Landscape. Which ones apply depends on what you’re building. Standalone LLM integrations follow the LLM Top 10. Agentic systems follow the Agentic Top 10. MCP integrations need the MCP guide on top of that.
The OWASP AI Use Case Framework AIUC-1 (May 2026) is the decision-tree crosswalk that maps your AI use case to the applicable control sets. Start there.
The project publishes across four document categories. Risk catalogues (LLM Top 10, Agentic Top 10) define what can go wrong. Implementation guides (Secure MCP Server Development Guide) define how to prevent it. Tooling documentation (AIBOM Generator) defines how to produce compliance artefacts. Testing guidance (Red Teaming Landscape) defines how to verify your controls are actually working.
The LLM Top 10 and Agentic Top 10 are not version increments of each other — they address categorically different threat models. Teams building agentic systems need both. The OWASP AI Agent Security Cheat Sheet supplements the Agentic Top 10 with concise developer-level controls — handy when you need something to hand directly to your developers. Treat the Q1–Q2 2026 publications as the current baseline. OWASP ran four dedicated GenAI sessions at RSAC 2026 — for context on OWASP’s four GenAI sessions at RSAC 2026 and the standards community’s response, see the conference analysis.
So that’s the map. Now for the part that changes what your team actually needs to do.
The OWASP Top 10 for LLM Applications covers risks at the model interface: prompt injection, sensitive information disclosure, supply chain issues, data and model poisoning, improper output handling.
The OWASP Top 10 for Agentic Applications 2026 uses ASI risk codes and addresses what emerges when a system can plan, use tools, and act on its own. In an agentic system, a prompt injection doesn’t just produce a bad output — it hijacks the agent’s planning process, selects different tools, runs them with inherited user privileges, persists malicious instructions in memory, and propagates tainted instructions to peer agents.
Two new categories your team needs to understand: Excessive Agency (agents granted more authority than their task requires) and Goal Hijacking (ASI01) — an attacker tricking the agent into changing its objective via malicious content in tool outputs or retrieved documents. The mitigation for both is OWASP’s Least Agency Principle: agents get only the minimum scope of authority, tool access, and data access needed for their specific task. Short-lived tokens, per-task scoping, per-agent identity.
The practical question is whether your current threat model covers what your agents can now do. According to industry analysis, only 11% of organisations are running agentic AI in full production, and security governance gaps are the primary barrier.
The Model Context Protocol (MCP) was introduced by Anthropic in November 2024. It standardises how AI applications connect to external tools, data sources, and services — a universal interface layer that replaces fragmented custom integrations.
MCP servers are a new attack surface because, unlike traditional APIs where developers control every call, MCP lets the LLM decide which tools to invoke, when, and with what parameters. The OWASP Practical Guide for Secure MCP Server Development (February 2026) covers the four controls that matter: authentication on every server (no anonymous access), network isolation, permission scoping per tool, and logging of every tool invocation.
The attack scenario OWASP is most concerned about: a malicious MCP server or compromised tool response causes the agent to take unauthorised actions. Malicious tool descriptions can achieve attack success rates up to 72.8% against production agents. Any team using Claude, Cursor, or building custom MCP integrations needs this guide alongside the Agentic Top 10.
The OWASP AI Security Solutions Landscape for AI and Agentic Red Teaming Q2 2026 (April 2026) pushes back on treating red teaming as a pre-release gate. By the time you finish a testing cycle on an agentic system, a tool it relies on has updated its behaviour, a new MCP server has been added, or a downstream agent has been modified. A static eval suite run quarterly is red teaming a version of the agent that no longer exists.
The Q2 2026 guidance covers agentic-specific scenarios the LLM-era playbooks don’t: multi-step goal hijacking, tool misuse chains, privilege escalation across agent handoffs, and persistent state manipulation. For teams without a dedicated red team, the message is simple — AI security testing needs to become a repeatable automated step in your release process, not a manual review. The guide provides the scenario library to build those automated tests from.
An AI Bill of Materials (AI-BOM — also written AIBOM, AI SBOM, or ML-BOM) is a structured inventory of all components in an AI system: base models, fine-tuned weights, training datasets, third-party API dependencies, and inference infrastructure. OWASP treats AI-BOM generation as a compliance requirement, not an optional transparency measure.
The OWASP AIBOM Generator (December 2025) produces output in CycloneDX format — the machine-readable standard formalised as ECMA-424. EU AI Act Article 53 requires high-risk AI system providers to maintain technical documentation covering component provenance, training methodologies, and distribution channels. CycloneDX AIBOM output satisfies this. Generate it during CI/CD and publish one machine-readable AIBOM per release.
An EU AI Act conformity assessment auditor reviewing a high-risk AI system looks for evidence across six control domains: system documentation (AI-BOM, architecture records), access control (Least Agency Principle applied), adversarial testing records, supply chain verification (model provenance), monitoring (anomaly detection for agent behaviour), and incident response procedures.
OWASP Agentic Top 10 controls map to EU AI Act Article 9, Article 53, and Article 72, but the mapping isn’t something OWASP publishes directly. Your team needs to construct it. The OWASP guide also grounds the DevSecEng lifecycle this standard requires — mapping controls to your development process is the first step before building audit evidence.
Excessive Agency (AC-1) — tool scope definitions and authorisation records.
Agentic Prompt Injection (PI-1) — input validation logs and tool response sanitisation records.
Goal Hijacking (GH-1) — agent behaviour monitoring logs and anomaly detection alerts.
Supply Chain Security (SC-1) — AI-BOM in CycloneDX format with model provenance records (direct Article 53 evidence).
MCP Server Security (MCP-1) — authentication logs and authorisation scope records for every MCP connection.
Red Teaming (RT-1) — continuous red teaming logs and a test scenario library.
Tools like Apiiro provide OWASP-aligned scanning that can generate audit-ready artefacts for some of these control areas. For a full evaluation of OWASP-aligned vendor tools and how they map to the control domains above, see the vendor comparison. EU AI Act high-risk provisions take effect August 2, 2026, with penalties reaching €15 million or 3% of global annual turnover. Q2 2026 is the practical deadline for your conformity assessment documentation. For the full picture of the AI code security requirements engineering teams now face — covering scanning gaps, organisational change, autonomous pipelines, and vendor selection — see the series overview.
No. “OWASP AI Testing Guide” resolves to the OWASP GenAI Security Project’s publication family: the Top 10 for LLM Applications, the Top 10 for Agentic Applications, the Secure MCP Server Development Guide, and the Red Teaming Landscape. The OWASP AI Security and Privacy Guide is often the search landing page but is not the same as testing guidance.
The OWASP Top 10 for Agentic Applications 2026 is published at genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ as a PDF and versioned GitHub repository.
The LLM Top 10 (LLMxx risk IDs) addresses model-interface risks. The Agentic Top 10 (ASIxx risk IDs) addresses risks that only emerge when an AI system acts autonomously: Excessive Agency, Goal Hijacking, tool misuse, privilege escalation across multi-step agent chains. Teams building agentic systems need both.
For high-risk AI systems under EU AI Act Article 53, technical documentation including component provenance is required. An AI-BOM in CycloneDX format is the practical mechanism for satisfying this — OWASP treats it as a compliance requirement, not an optional best practice.
Security requirements for implementing Model Context Protocol servers — the interface layer allowing AI agents to call external tools and data sources. Any team using Claude, Cursor, or building custom MCP integrations needs this guide alongside the Agentic Top 10.
OWASP’s design mandate for agentic AI systems: agents get only the minimum scope of authority, tool access, and data access needed for their specific task. The agentic equivalent of least privilege, and the primary control for preventing Excessive Agency.
Excessive Agency is when an AI agent is granted more authority, tool access, or data scope than it needs. Analogous to an over-privileged service account. OWASP’s mitigation is the Least Agency Principle: define and enforce minimum required scope for each agent at design time.
No. It’s a foundational overview page. The actual testing guidance lives across the OWASP GenAI Security Project publications, particularly the Agentic Top 10 and the Red Teaming Landscape.
Traditional pre-release testing is a point-in-time gate. Continuous red teaming integrates adversarial testing into deployment pipelines and production monitoring. Agentic systems require this because their attack surface evolves at runtime — tool outputs, retrieved documents, and inter-agent communications introduce new adversarial inputs after deployment.
AIUC-1 is the OWASP AI Use Case Framework crosswalk (May 2026). It maps AI use cases by system type, deployment context, and risk level to applicable OWASP control sets — the recommended starting point for teams overwhelmed by the volume of OWASP AI publications.
Yes. OWASP Agentic Top 10 controls map to EU AI Act Article 9, Article 53, and Article 72. OWASP alignment doesn’t guarantee conformity assessment approval, but it provides a widely-recognised control framework that auditors are increasingly citing as a reference standard.
The OWASP AIBOM Generator produces AI Bill of Materials output in CycloneDX format, capturing model provenance, dataset lineage, fine-tuning history, and dependency chains. It supports supply chain security review under the Agentic Top 10 and satisfies EU AI Act documentation requirements for high-risk AI system components.
When Agents Commit Code: Securing Autonomous CI/CD PipelinesYour pipeline now has a non-human committer, and that changes everything you thought you knew about your security model. The EU AI Act’s enforcement deadline is 2 August 2026, and if your pipeline includes autonomous agents with deployment permissions and your product touches FinTech, HealthTech, or any regulated space, you may be looking at a high-risk AI system under Articles 8–15. The application security blind spot that autonomous agents amplify starts here — where agents with write access move faster than any review process was designed to handle.
Getting this right isn’t about rejecting AI coding agents. It’s about recognising that bolting your existing DevSecOps controls onto this new reality isn’t enough. You need new controls.
A human committer is constrained by working hours, fatigue, and social accountability. An autonomous agent has none of those.
The ADLC (Agentic Development Lifecycle) is a new development paradigm: agents generate code, the “author” is a model, the IDE may be bypassed entirely, and pull requests are auto-generated or skipped altogether. Three things break when the committer is non-human. Agents operate on behalf of identities they don’t own, which blurs accountability. They can be manipulated through issue comments and PR descriptions that a human would immediately recognise as adversarial but an agent parses as instructions. And they interact with the same logging infrastructure that’s supposed to audit them. Legacy identity governance was built for humans in sanctioned workflows — not for non-human identities running thousands of actions per minute on inherited credentials.
Human-in-the-loop checkpoints are the primary mechanism for preserving accountability in a non-human system. Those three structural breaks are exactly where the five specific threats emerge — and they’re the reason your existing tooling won’t catch them.
The OWASP Top 10 for Agentic Applications identifies Excessive Agency as the primary failure mode — with three root causes: excessive functionality (agents reach tools beyond their task scope), excessive permissions (those tools operate with broader privileges than necessary), and excessive autonomy (high-impact actions proceed without human review).
In pipeline terms, this means: an agent with write access to all repositories when it only needs one. An agent that can approve its own pull requests. Credentials set up for convenience and never revisited. Multi-agent pipelines make this worse — when agent A delegates to agent B, agent B often inherits agent A’s full permission scope. That’s a chain-of-trust escalation traditional RBAC simply wasn’t designed to handle.
The answer is task-scoped permissions, per-session and per-task, revoked after task completion. The how of that is covered in the identity management section below.
These threats don’t exist in pipelines without autonomous agents. Your existing DevSecOps tooling doesn’t detect them.
Prompt-injected commits. A malicious instruction embedded in a GitHub or GitLab issue comment causes the agent to execute unintended actions using its legitimate access. The attack doesn’t bypass infrastructure controls — it steers the agent to commit the attack itself. The Clinejection attack is a documented example: prompt injection in an issue title, chained into GitHub Actions cache poisoning, into credential theft, into a supply chain attack.
MCP server compromise. A compromised Model Context Protocol server gives an agent false context or out-of-scope access. In January 2026, researchers found 1,862 MCP servers exposed to the internet without authentication. MCP compromise and prompt injection frequently co-occur.
Slopsquatting (hallucinated dependencies). An agent hallucinates a non-existent package name; an attacker pre-registers it on npm or PyPI with malicious code. A USENIX study of 576,000 code samples found nearly 20% of LLM-recommended packages did not exist. In January 2026, a hallucinated npm package called react-codeshift spread through 237 repositories with nobody deliberately planting it.
Agent identity confusion. Without unique cryptographic identities per agent, establishing a forensic chain of custody for any commit is structurally difficult. Half of enterprises have experienced a breach due to unmanaged non-human identities.
Audit log forgery. An agent can interact with the logging infrastructure used to audit it — creating the possibility it omits or falsifies its own trail. Plain text logs cannot provide tamper-evidence guarantees; a compromised host can delete or alter log entries without detection.
These map directly to the vulnerability classes that autonomous commits introduce.
The identity confusion threat above leads directly here. Stop treating agents as generic service accounts with long-lived tokens.
Non-Human Identity (NHI) is the industry term for this discipline. AI agents are dynamic — they decide what actions to take based on context, operate across multiple systems, and request different access levels per task. There are three components to get right: dedicated service accounts per agent role (not one shared “ci-agent” account); short-lived credentials — time-limited tokens issued per task or session, not persistent environment variables; and commit signing with agent-specific keys, creating a verifiable record of which agent did what.
Watch for orphaned agents too: if the account that owns an agent’s credentials is disabled, those credentials often remain active. Tools like AWS IAM Roles Anywhere, HashiCorp Vault, and GitLab CI OIDC tokens exist specifically for managing this kind of non-human identity lifecycle at the scale most engineering teams actually operate at.
A specification gate is a mandatory pre-commit checkpoint where an agent’s proposed action is validated against a written specification — by a human approver, a policy engine, or both — before the agent may proceed. It’s different from a pull request review, which is human judgement after the commit. A specification gate is policy enforcement before the action.
Three patterns, ordered by where your team currently sits. Low maturity: every agent commit opens a pull request requiring human approval before merge. Medium maturity: a policy engine — OPA/Rego is the obvious choice — validates the proposed diff against pre-defined rules before the agent may proceed. High maturity: the policy engine handles routine commits automatically, and anything outside defined parameters escalates to human review with a logged reason for the escalation.
Specification gates directly address two OWASP Top 10 for Agentic Applications risks: Insufficient Authorisation Checks and Unconstrained Resource Access. They also satisfy the human oversight documentation requirement under EU AI Act Articles 9–17.
An AI-BOM (AI Bill of Materials) extends the traditional SBOM to attribute which code was generated, modified, or selected by an AI agent. An SBOM records what components are in your software. An AI-BOM adds who introduced them, whether they were verified, and whether a human reviewed the decision. You need both — SBOM is the compliance baseline; AI-BOM makes agent-generated code auditable.
The AI-BOM adds three fields an SBOM doesn’t have: agent attribution, confidence provenance (verified registry or agent suggestion?), and review status. The confidence provenance field is where slopsquatting becomes detectable — packages with no human review flag trigger automated registry verification.
GitLab integrates SBOM generation in CycloneDX format throughout its DevSecOps workflows — that’s your baseline, with AI-BOM attribution layered on top as agent usage grows in your pipeline.
Audit logs for autonomous pipelines have to answer a question human-commit logs never had to: did the agent accurately record what it did?
There are five required properties. Write-once, append-only storage — a separate aggregation service, not the same system the agent writes code to. Agent identity in every entry — cryptographic identity, task ID, credential, not just “ci-agent”. Action-level granularity — file read, API call, commit hash, not run-level outcomes. Out-of-band alerting for log gaps, because absence of output for a defined interval is itself an alert condition. And retention of at least six months for EU AI Act high-risk systems.
Audit log forgery is prevented architecturally — write-once log destinations the agent cannot modify, not policies trusting the agent to log accurately. Note that Article 12 of the EU AI Act requires automatic logging with traceability but does not mandate cryptographic immutability — tamper-evidence is best practice, not the minimum legal bar.
These controls don’t exist in isolation — they map directly to the authoritative threat taxonomy for the space. The OWASP Top 10 for Agentic Applications 2026 was developed with more than 100 industry experts. That mapping gives you a defensible answer when your board or an auditor asks how your controls cover the known risks.
Six of the ten risks are directly addressed by the architecture in this article. ASI01 (Excessive Agency): least-privilege service accounts, short-lived credentials, specification gates. ASI02 (Prompt Injection / Tool Misuse): input validation, sandboxed execution, specification gate review. ASI03 (Identity Abuse): agent identity management, task-scoped RBAC. ASI04 (Supply Chain Vulnerabilities): AI-BOM generation, hallucinated dependency detection, registry verification. ASI05 (Insecure Output Handling): specification gates, human-in-the-loop review before commit. ASI08 (Repudiation and Untraceability): write-once audit logs, agent identity isolation, MCP access controls.
Four remaining risks — Overreliance, Data Poisoning, Denial of Service, Uncontrolled Self-Replication — are partially addressed and require additional controls.
The full control stack: dedicated agent identities, short-lived credentials, specification gates, write-once audit logs, AI-BOM generation. Achievable without a dedicated security engineer using GitLab CI policies, AWS IAM Roles Anywhere, Vault, and OPA. For the DevSecEng process context for agentic risk and tooling that enforces autonomous pipeline controls, see those articles. This article is part of the broader application security blind spot that autonomous agents amplify — the series overview covers the full landscape from problem diagnosis to compliance readiness.
Excessive agency is the OWASP Top 10 for Agentic Applications’ primary failure mode: an agent with permissions beyond what its task requires. The fix is task-scoped permissions, per session, revoked after task completion.
Prompt-injected commits, MCP server compromise, slopsquatting (hallucinated dependencies), agent identity confusion, and audit log forgery. Each is structurally new — they don’t exist in pipelines without autonomous agents, and standard DevSecOps tooling doesn’t detect them.
An AI agent hallucinates a non-existent package name; attackers pre-register it on npm or PyPI with malicious code. Unlike typosquatting, the agent invented the name. Mitigation: AI-BOM confidence provenance tracking combined with automated registry verification before installation.
An SBOM records what components are in your software. An AI-BOM adds who introduced them, whether they were verified, and whether a human reviewed the decision. You need both — SBOM is the compliance baseline; AI-BOM makes agent-generated code auditable.
Dedicated service accounts per agent role. Short-lived credentials per task, not long-lived environment variables. Commits signed with agent-specific keys. Tooling options in this space include AWS IAM Roles Anywhere, HashiCorp Vault, and GitLab CI OIDC tokens.
A specification gate validates an agent’s proposed action against a written specification before the agent proceeds. A PR review is human judgement after the commit. The gate is pre-commit; the review is post-commit.
Yes, if the agent has direct commit access and no specification gate is in place. Via prompt injection through a GitHub issue comment, an adversary can instruct the agent to commit code using its own legitimate credentials.
Your agent parses the comment as instructions and executes them — committing code, changing pipeline config, or modifying access controls. Controls: input validation on all data channels the agent reads, sandboxed execution, and a specification gate before any commit.
The 2 August 2026 deadline activates Articles 8–15. For teams in FinTech, HealthTech, or sectors under Annex III, autonomous deployment pipelines may qualify as high-risk AI systems, requiring documented risk management, human oversight, and audit trail retention.
Authentication on every MCP server (no anonymous access), network isolation, permission scoping per tool, and logging of every invocation. Only connect to verified, pinned sources. Monitor MCP server logs separately from agent logs.
Yes. SBOM is the compliance baseline; AI-BOM adds attribution and provenance for agent-generated code. Start with SBOM; layer in AI-BOM attribution as agent usage grows.
Logs to a write-once destination the agent cannot modify. Every entry must include agent identity, task ID, and action-level detail. Absence of output for a defined interval is an alert condition. Retain for at least six months for EU AI Act high-risk systems.
The Vendor Race: Checkmarx, Cycode, OX Security, and the New AppSec StackAccording to DX Research’s Q1 2026 analysis of 500+ organisations, AI-generated code now accounts for roughly 27% of all production code. Veracode’s Spring 2026 testing found that 45% of AI coding tasks introduce a known security flaw — and the Java failure rate exceeds 70%. The scan-after-commit model was built for code that humans write at human speed. It was not built for the vulnerability patterns that AI output produces.
RSAC 2026 made the vendor response concrete. Checkmarx picked up a Global InfoSec Award for AI-generated code security. OX Security ran live DAST demonstrations against AI output on the conference floor. Forrester formally introduced the Agentic Development Security (ADS) framework — eight capability pillars for evaluating platforms that protect AI-powered development end to end. No single vendor covers all eight. That is your real constraint when evaluating this market.
This article maps the landscape using the ADS framework as a vendor-neutral scaffold, covering Checkmarx One, Cycode, OX Security, Apiiro, and Wiz, then maps each to common team profiles. This guide is part of our comprehensive AI-generated code security overview, which covers the full AppSec shift in detail.
The core problem is velocity. Teams with high AI adoption are merging 98% more pull requests, but PR review time is up 91%. Scan-after-commit breaks down when code is generated faster than humans can review it. That is a structural problem, not a tooling gap.
Three distinct product layers have emerged from this. AI-aware SAST enhances static analysis to detect vulnerability patterns common in AI output — hallucinated import chains, authentication logic dropped into the wrong execution paths. ASPM (Application Security Posture Management) sits above your existing scanners, correlating SAST, SCA, DAST, IaC, and secrets findings with exploitability context so you can actually answer “which of these findings matters?” Prompt-layer security is the newest layer — it intercepts developer prompts before AI coding assistants generate code at all.
RSAC 2026 marked the shift from awareness to product — the ADS framework is now the benchmark vendors are being measured against.
Forrester Senior Analyst Janet Worthington introduced ADS in April 2026, shortly after RSAC. The eight pillars:
No single vendor covers all eight. That is not a weakness of any particular vendor — it is just the state of the market right now, and your starting point for any procurement decision.
Use this as a coverage-gap analysis, not a feature checklist. Which pillars does your current tooling already cover? For a 50–500 person team, three pillars are the minimum viable baseline: code and dependency analysis, triage and prioritisation, and at least one supply chain protection capability. If your team is using Cursor or Copilot heavily, weight pillar 2 heavily — that is where Apiiro and OX Security differentiate.
Reachability analysis is what separates useful ASPM triage from simple severity-scoring. It filters findings to those actually exploitable from real execution paths. For the restructured DevSecEng lifecycle these tools must serve, we cover the workflow implications in detail there.
Checkmarx One is a unified ASPM platform with native SAST, SCA, DAST, and API testing under one roof, serving 40% of the Fortune 100 across 75+ programming languages. The Global InfoSec Award at RSAC 2026 reflects real investment in AI-generated code security — new AI security agents for prioritisation and remediation, expanded AI Supply Chain Security, and better analysis across code and runtime environments.
AI-aware SAST here means the engine has been specifically tuned to flag AI output patterns — the kind of vulnerability classes legacy rule-based engines miss, where authentication logic is technically well-formed but placed in the wrong execution path. Developer Assist handles pre-commit IDE scanning; Triage Assist applies AI-driven prioritisation post-commit, with IDE support across Cursor, Windsurf, VS Code, and AWS Kiro.
ADS pillar coverage: strong on pillars 1, 3, 5, and 7. Emerging on pillar 2 — no prompt-layer prevention yet. Best fit: existing Checkmarx investment, compliance-heavy environments (FinTech, HealthTech), large polyglot codebases that need language breadth.
Where Checkmarx One leads on scanning breadth, Cycode‘s main differentiator is its graph architecture. Cycode is a full-lifecycle ASPM platform built natively as a management layer. The 2024 Bearer acquisition added native SAST; ConnectorX supports 120+ integrations — making it the strongest consolidation play when you’re dealing with scanner sprawl.
The key architectural differentiator is the Risk Intelligence Graph — also called the Context Intelligence Graph (CIG) in current Cycode documentation. Rather than aggregating scanner scores, this graph model maps relationships between code, infrastructure, identities, and runtime environments. When a vulnerability surfaces, it answers: who owns this repository, how does it connect to other systems, what is the blast radius? Cycode’s AI Exploitability Agent cuts noise by 94% on the OWASP Benchmark.
Material Change Detection identifies which code changes actually shift your risk profile. Unlike traditional SAST, it understands code behaviour and flags changes with high-risk behavioural implications even when no specific vulnerability pattern matches — which is particularly useful for surfacing risk in high-velocity AI commits. ADS pillar coverage: strong on pillars 1, 3, 7, and 8. Moderate on pillar 5. Best fit: scanner sprawl, developer-first workflows, supply chain governance.
OX Security has moved furthest into prevention-first territory via VibeSec — a product that embeds security rules and organisational policies directly into AI coding editors (Cursor, Copilot, Windsurf, VS Code) so code is generated secure-by-design from the start. At RSAC 2026, OX demonstrated DAST failures against AI-produced output, describing LLMs as “junior developers” with consistent susceptibility to path traversal, XSS, command injection, SSRF, and open redirect flaws. It is an independent validator of the problem, not just a vendor with something to sell.
The PBOM (Pipeline Bill of Materials) is OX’s proprietary model that extends the SBOM concept beyond “what libraries am I using?” to cover everything that touches your code from design to deployment. OX’s MCP vulnerability research identified 150M+ downloads across 7,000+ exposed MCP servers; VibeSec now flags improper STDIO MCP configurations in AI-generated code as actionable findings. The OX Agentic Pentester runs AI-driven penetration testing against running applications.
ADS pillar coverage: strong on pillars 2, 3, 5, and 7. The PBOM maps a wider range of supply chain artefacts than any other vendor in this comparison. Best fit: Cursor or Copilot-heavy teams; organisations with scanner noise problems; supply chain transparency as a primary concern.
Apiiro‘s Guardian Agent is the most upstream security control in this comparison. It intercepts developer prompts before they reach AI coding assistants, injecting security context, threat models, and compliance policies via Secure Prompts (patent-pending). Vulnerable code is prevented at source rather than caught after the fact.
Every other vendor here operates post-generation. Checkmarx, Cycode, and Wiz all work after code has been written. OX Security’s VibeSec embeds in the editor at generation time. Guardian Agent operates at the prompt layer, before generation begins — a different intervention point, not just a faster version of the same control. The Apiiro CLI, released April 2026, exposes six agent skills directly inside CI pipelines: query risks, scan code, validate changes, apply policies, fetch threat models, and surface Secure Prompt context.
Deep Code Analysis (DCA) traces data flows across function and service boundaries and flags behavioural changes even when diffs look minor. The AutoFix Agent handles automated remediation for vulnerabilities that slip through.
ADS pillar coverage: uniquely strong on pillar 2 — the only prompt-level prevention tool in this comparison. Strong on pillars 1, 3, and 4. Moderate on pillars 5 and 7. Best fit: developer-first organisations with SDLC discipline; Cursor-heavy teams; security-by-design as a cultural goal rather than a compliance checkbox.
Wiz enters AppSec from the cloud security direction. Its Security Graph extends from cloud infrastructure findings into application code, enabling code-to-runtime risk analysis for teams already running Wiz for cloud security. Wiz Research found 20% of real-world apps built with AI coding tools contain significant security issues. Three agents cover different angles: Red Agent for offensive testing, Green Agent for root cause identification and automated fix deployment, Blue Agent for investigating AI-enabled attacks at speed.
That MCP server exposure rate matters beyond Wiz’s own research — when 80% of organisations have MCP servers in their environment, the supply chain attack surface has shifted faster than most AppSec tooling was designed to track.
Wiz approaches code-to-runtime from the cloud side; Apiiro approaches it from the code side. For teams already on Wiz for cloud security, extending it into AppSec is lower-effort than adopting a separate ASPM platform — but Wiz’s code analysis depth is lower than Checkmarx, Cycode, or OX Security.
ZeroPath represents the AI-native SAST challenger archetype — using AI to find AI-generated code vulnerabilities. Its analysis of CVE-2026-24120, a vm2 sandbox escape, demonstrated the ability to identify AI-generated vulnerability patterns that traditional static analysis misses. Snyk AppRisk layers posture management over Snyk’s developer-first scanners; Legit Security offers developer-centric ASPM for large-enterprise estates. Both compete primarily with Cycode on consolidation.
ADS pillar coverage for Wiz: strongest on autonomous-agent attack surface, IaC scanning, and runtime risk. Best fit: cloud-native teams already on Wiz; autonomous CI/CD pipeline controls are covered in detail for teams building out that architecture.
These profiles map the primary use cases for each vendor to the most common team configurations in the 50–500 person range.
50-200 person team, Cursor-heavy, human-review CI/CD. OX Security VibeSec or Apiiro Guardian Agent as your primary investment. Prevention-first tools deliver the highest ROI when engineering velocity is the constraint and dedicated AppSec staff are limited. Pair with GitHub Advanced Security for baseline SAST if it is already in your GitHub contract.
50-200 person team, Copilot-heavy, regulated (FinTech/HealthTech). Checkmarx One or Cycode as the ASPM layer — compliance-grade audit trails and DAST coverage satisfy regulatory requirements. Add Guardian Agent at the next budget cycle if you want prompt-layer coverage.
200-500 person team with scanner sprawl. Cycode’s Risk Intelligence Graph with 120+ integrations directly addresses “too many tools, not enough signal.” OX Security’s PBOM is the alternative if supply chain transparency is the primary concern.
200-500 person team, cloud-native, running agentic CI/CD. Wiz for the cloud-to-code risk graph plus a code-first ASPM (OX Security or Apiiro) for the development lifecycle.
Team inheriting an existing Checkmarx investment. Upgrade to Checkmarx One before evaluating alternatives — the ASPM layer adds triage and risk prioritisation value without requiring rip-and-replace.
The vendor scepticism counter-argument. If your current baseline is GitHub Advanced Security plus Snyk, evaluate whether AI-generated code is causing measurable production security incidents before committing to new ASPM spend. GHAS plus Snyk covers ADS pillars 1, 3, and partial 7. Prevention-first tools become more valuable as AI code share crosses 30–40% of the codebase. The ADS framework helps identify real gaps versus theoretical ones.
For RSAC 2026, which crystallised vendor differentiation, that article covers the conference context in full. For the complete AI-generated code security landscape — covering the problem diagnosis, organisational shift, autonomous pipeline threats, and compliance requirements — the pillar overview ties all these threads together.
ASPM aggregates findings from multiple scanners — SAST, SCA, DAST, IaC — and correlates them with exploitability context to answer “which of these findings actually matters today?” SAST flags code patterns; ASPM ranks them by whether they’re actually exploitable in your specific environment. A low-severity finding touching a public API surface via a privileged service account looks very different once you have that context.
Yes. Checkmarx One’s AI-aware SAST enhancements address the AI-output vulnerability patterns that legacy rules-based SAST missed, and the RSAC 2026 Global InfoSec Award validated the pivot. Teams wanting prompt-layer prevention (ADS pillar 2) should evaluate Apiiro alongside it.
Guardian Agent intercepts the prompt a developer sends to an AI coding assistant before code is generated, inserting Secure Prompts — pre-defined security rules, threat models, and compliance policies — so the AI generates compliant code from the start. The Apiiro CLI exposes six agent skills directly inside CI pipelines: query risks, scan code, validate changes, apply policies, fetch threat models, and surface Secure Prompt context.
PBOM (Pipeline Bill of Materials) extends the SBOM concept from “what libraries am I using?” to “what is everything that touches my code from design to deployment, and what is its risk state?” — inventorying components, dependencies, configurations, and risk signals across the full delivery pipeline, including AI-generated code patterns like improper STDIO MCP configurations.
Forrester Senior Analyst Janet Worthington introduced Agentic Development Security in April 2026 after RSAC, defining eight pillars: code and dependency analysis, coding guardrails, triage and prioritisation, remediation, dynamic testing, quality gates, supply chain protection, and governance analytics. No current vendor covers all eight.
Both prevent AI-generated code vulnerabilities, but at different points. VibeSec embeds security rules into AI coding editors and acts at code generation time; Guardian Agent intercepts at the prompt layer before generation begins, making it the earlier control in the pipeline. VibeSec is an editor integration; Guardian Agent operates upstream of the editor.
Wiz functions as an ASPM extension of your cloud platform, not a standalone AppSec-first solution. Its code analysis depth is lower than Checkmarx, Cycode, or OX Security — best deployment is Wiz for cloud-to-runtime plus a code-first ASPM for the development lifecycle.
Cycode’s Risk Intelligence Graph — also called the Context Intelligence Graph in current documentation — maps relationships between code, infrastructure, identities, and runtime environments, answering “is this vulnerability reachable in the production deployment path, and what is the blast radius?” rather than ranking by CVSS score alone.
If your current baseline (GHAS plus Snyk) covers ADS pillars 1, 3, and partial 7, and AI-generated code isn’t yet causing measurable production security incidents, defer the spend. A 50-person team without dedicated AppSec staff will get more value from running reachability analysis on existing findings than from adding another management layer.
For Cursor-heavy teams, OX VibeSec and Apiiro Guardian Agent both support Cursor as an integration target. For teams using Claude Code, prompt-interception is the more relevant control since Claude Code operates outside traditional IDE integrations; Wiz also announced remediation Skills running natively inside Claude Code at Google Cloud Next 2026.
Reachability analysis traces whether a vulnerability is actually reachable from a real execution path in the deployed application, surfacing only findings that can be triggered in production. OX Security, Cycode, and Apiiro all implement it; Cycode’s implementation achieves 94% noise reduction on the OWASP Benchmark.
From DevSecOps to DevSecEng: Restructuring the Security LifecycleAccording to DX Research Q1 2026, AI-generated code now accounts for roughly 27% of all production code — up from 22% the previous quarter. That code is being committed at machine speed, often with no human reviewer anywhere near it. DevSecOps was built around human review cycles: a developer reads the diff, a reviewer approves it, SAST scans deterministic patterns. All three of those assumptions fall apart when AI agents are writing and committing autonomously.
Security leaders are restructuring where in the lifecycle security actually operates. The emerging label for that restructuring is DevSecEng — Development Security Engineering — which moves the primary security control upstream to the specification and prompt layer, before code generation begins. This article maps the control-point differences, explains what that shift means in practice, and gives you a 90-day path to get there. It is part of our broader coverage of the application security blind spot created by AI-generated code. If you want the technical diagnosis first, start with why traditional DevSecOps tooling misses AI code vulnerabilities.
Volume and velocity broke the model.
Faros AI found that teams with high AI adoption merge 98% more pull requests while PR review time increased 91%. AI doubled throughput without growing the human review queue. A December 2025 CodeRabbit study found AI-authored PRs generated 2.74 times more security issues. AI commits expose secrets at 3.2% of commits versus 1.5% for human-only commits — double the rate, at double the volume.
Veracode’s Spring 2026 GenAI Code Security Report found AI-generated code introduces vulnerabilities in 45% of development tasks. Security pass rates are stuck at around 55% — virtually unchanged from two years ago. And traditional SAST compounds the problem: it relies on deterministic patterns, and AI code introduces inconsistent access control implementations and hallucinated dependency chains that rule-based scanners simply miss.
RSAC 2026 was when this became industry-wide acknowledgment — Forrester introduced the Agentic Development Security (ADS) framework, Checkmarx received the Global InfoSec Award for agentic security. The data and the frameworks now align. For a detailed account of the industry consensus emerging from RSAC 2026, see our conference synthesis.
DevSecEng (Development Security Engineering) is the organisational label for a shift in when security operates. Where DevSecOps places primary controls at code review, merge, and deploy, DevSecEng places them at prompt authoring, context injection, and specification review — before code generation begins.
The nearest official framework is Forrester’s ADS framework, spanning eight capability areas: code and dependency analysis, coding guardrails, triage, remediation, dynamic testing, quality gates, supply chain protection, and governance analytics. DevSecEng is the organisational label; ADS is the technical structure underneath it.
Two concepts define DevSecEng. Prompt Layer Security is the practice of reviewing what gets submitted to AI coding tools — checking whether prompts are scoping into security-sensitive areas without the right constraints. The Specification Gate is the formalised control point: a mandatory security review before code generation begins. Neither of those exists in conventional DevSecOps. That is the structural difference.
DevSecOps moved security from deploy-time to commit-time. DevSecEng extends that to prompt-time, because by the time AI-generated code reaches review it may already have been committed by an autonomous agent.
The clearest way to see the shift is to put them side by side.
DevSecOps primary control points: code review, PR approval, SAST advisory scan, pre-deploy gate.
DevSecEng primary control points: specification gate, prompt layer injection, pre-commit secrets detection, SAST as a blocking gate, human-in-the-loop checkpoint, AI code provenance log.
Cycode puts it directly: “AI agents generate code on their own, pull dependencies, call external tools, and commit changes without a developer ever opening a traditional IDE.” Some controls are additive — provenance tracking, prompt interception. Others are policy changes on tools you probably already have: SAST moving from advisory to blocking, secrets detection extended to AI service credential patterns, branch protection requiring human approval tokens rather than just a passing test suite. For the full autonomous pipeline control architecture, see the autonomous pipeline that makes DevSecEng non-negotiable.
Advisory SAST means a report gets generated. Blocking SAST means the CI build fails. For AI-contributed code, advisory is unworkable — reports pile up faster than anyone can action them.
Tag AI-origin commits, route them to a dedicated pipeline stage, and configure SAST to fail the build on high or critical findings — keep it separate from your existing pipeline so you can build a baseline without disrupting the team.
CSA recommends a phased rollout: advisory mode for 30 days, blocking for high and critical in month two, blocking for medium by month three. Moving straight to blocking everything creates false positives that breed bypass habits. And your existing SAST config was written for human-authored code — tuning it for AI output patterns like credential embedding and excessive privilege assignments is a separate task worth doing properly.
GitGuardian’s 2026 report documented 28.65 million new hardcoded secrets in public GitHub commits in 2025. AI-service credentials increased 81% year-on-year. Most detection tools were written to catch AWS, GitHub, and Stripe formats. AI-generated code pulls in credentials for OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex AI, Cohere, and Hugging Face. Your detection signatures need to be a living list, not a set-and-forget config from 2024.
MCP configuration files are an attack surface most teams have missed entirely — GitGuardian found 24,008 unique secrets in MCP-related config files on public GitHub. If your team uses MCP-enabled AI tools, those files need to be in scan scope.
Tune your reject rules before you enforce them. A developer who learns to override a false positive block will override it when it is a real secret too.
Autonomous agents do not observe conventions. A cultural norm like “developers should review security-sensitive changes” is unenforceable when the committer is not human. The checkpoint policy has to be a CI/CD rule, full stop.
OWASP’s Top 10 for Agentic Applications identifies “Excessive Agency” as a primary risk. The tiered structure that has emerged: low-risk changes (documentation, tests) proceed autonomously; medium-risk changes (feature code, dependencies) require async human approval; high-risk changes (infra, auth, secrets) require synchronous human review before the pipeline proceeds. Encode this with branch protection rules and a CI step requiring an explicit human approval token — not just a passing test suite.
Provenance tracking answers three questions: which code was AI-generated, by which model, and from which prompt. That gives you targeted SAST re-runs, audit attribution when AI code introduces a CVE, and compliance evidence for regulated environments.
Start with a commit metadata convention — a standardised tag identifying AI-origin commits. This lets the pipeline route them to the blocking SAST gate without needing a dedicated platform. The more comprehensive approach is an AI-BOM (AI Bill of Materials) inventorying models, prompts, and dependencies. Per-line authorship attribution and full prompt history storage are overkill for most teams.
For FinTech and HealthTech operators: EU AI Act enforcement begins August 2026, requiring AI code provenance records and audit trails for high-risk AI systems. The OWASP AI Testing Guide provides a practical control mapping for teams working toward audit readiness.
You do not need to adopt the DevSecEng label. The practical question is whether you have the five control points that distinguish it from DevSecOps: a specification gate, prompt layer security, SAST as a blocking gate for AI-contributed code, pre-commit secrets detection tuned for AI credential patterns, and a human-in-the-loop checkpoint policy encoded as a CI/CD rule. 63% of organisations lack AI governance policies. If you have all five, the label does not matter. If you are missing three of them, the label is the least of your concerns.
Here is a sequenced 90-day path:
Month 1: Implement a commit metadata convention to tag AI-originated commits. Enable pre-commit secrets detection with AI service credential signatures — OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex AI, plus MCP config files in scope. Put SAST in advisory mode for AI-origin code to build a baseline.
Month 2: Escalate SAST to blocking on high and critical findings. Write the human-in-the-loop checkpoint policy in tiered form. Configure branch protection rules for production-bound commits. The month one baseline is what lets you distinguish real findings from false positives before you start blocking anything.
Month 3: Enforce checkpoints technically, not just as policy. Begin provenance tracking beyond commit tags. Review coverage against the ADS Framework pillars.
The AI code security challenge is structural: tools and processes designed around the exception now need to handle the plurality. You get to decide what you call the response — but you do have to respond. For the full context on the application security blind spot created by AI-generated code — including the vendor landscape and compliance requirements — see the series overview.
What does DevSecEng stand for? Development Security Engineering. An emerging successor label to DevSecOps, signalling that security must operate at the specification and prompt layer before AI code is generated — not primarily at code review and deploy gates.
Is DevSecEng an official standard or framework? No. It is not a certified framework or vendor product. The nearest official framework is Forrester’s Agentic Development Security (ADS) framework, which provides the technical structure DevSecEng describes organisationally.
How is the ADS Framework different from DevSecEng? ADS is Forrester’s eight-pillar technical framework covering code analysis, guardrails, triage, remediation, dynamic testing, quality gates, supply chain protection, and governance analytics. DevSecEng is the organisational label for the shift ADS requires. ADS is the what; DevSecEng is the how-we-work.
What is a Specification Gate? A mandatory security review before AI code generation begins — checking requirements and prompts for authentication scope, data access patterns, and credential handling. It is the defining upstream control of the DevSecEng approach.
Which AI-service credential patterns should pre-commit secrets detection cover? At minimum: OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex AI, Cohere, and Hugging Face — in addition to standard AWS, GitHub, and Stripe patterns. MCP configuration files also need to be in scope. Static rulesets from 2024 will miss 2026 credential formats.
What is AI code provenance tracking and do I need it? It records which code was AI-generated, by which model, from which prompt context. A commit tagging convention is the minimum viable approach. Full AI-BOM is more comprehensive but only necessary for regulated organisations facing EU AI Act compliance requirements from August 2026.
How do I know if an autonomous CI/CD agent is operating with excessive agency? When it performs actions outside its intended scope — modifying infrastructure when scoped to application code, or self-approving pull requests. Controls include least-privilege agent identity, human-in-the-loop checkpoints for high-risk changes, and audit log review. OWASP Top 10 for Agentic Applications covers this in detail.
Does DevSecEng apply to teams using AI coding assistants, not fully autonomous agents? Yes. Teams using GitHub Copilot, Cursor, or Claude Code still benefit from SAST as a blocking gate, pre-commit secrets detection tuned for AI credential patterns, and Prompt Layer Security. The human-in-the-loop checkpoint policy is primarily relevant when agents operate autonomously.
What is the difference between DevSecOps and DevSecEng in one sentence? DevSecOps integrates security into the human-authored code review and CI/CD pipeline; DevSecEng extends that to the specification and prompt layer, because by the time AI-generated code reaches review it may already have been committed by an autonomous agent.
How does GitGuardian relate to pre-commit secrets detection? GitGuardian is a secrets detection vendor whose State of Secrets Sprawl 2026 report documented 28.65 million new hardcoded secrets on public GitHub in 2025 and an 81% year-on-year increase in AI-service credential leaks. It represents the category of tooling that needs to be deployed and tuned for AI credential patterns.
What does the EU AI Act require from engineering teams regarding AI-generated code? Documentation of training data, model decisions, and system outputs — translating for engineering teams to AI code provenance records, audit trails for autonomous agent actions, and evidence that security controls were applied. The OWASP AI Testing Guide provides a practical control mapping for audit readiness.
Where does DevSecEng fit within the Forrester ADS framework? DevSecEng maps primarily to three ADS pillars: Coding Guardrails (prompt layer and specification gate controls), Quality Gates (SAST as blocking gate, pre-commit detection), and Governance Analytics (provenance tracking, audit logs). The remaining five pillars require additional tooling covered in the vendor comparison article.
RSAC 2026: The Turning Point for Application SecurityAI-generated code now accounts for roughly 27% of all production code, up from 22% the prior quarter — faster than most security teams can update a planning document. RSAC 2026 in San Francisco wasn’t another “AI is coming” conference. It was the one where independent analysts, a standards body, award judges, and a live demo all landed on the same conclusion at the same time: legacy AppSec cannot secure AI-generated code at scale.
In this piece we look at the four most significant signals from RSAC 2026 — Forrester’s ADS framework, Checkmarx’s Global InfoSec Award, OX Security’s DAST live demonstration, and OWASP’s four GenAI sessions — and why together they mark a genuine category shift rather than another vendor marketing cycle. This article is part of our comprehensive series on the AI code security blind spot. If you want the technical detail on why existing scanners fail, start with the underlying SAST failure problem. If you’re already at the vendor evaluation stage, jump straight to the vendors who differentiated at the conference.
Let’s get into it.
Previous RSAC conferences raised the AI code security question. RSAC 2026 answered it — and the answer came from four independent parties at once, each with a completely different incentive structure.
Mitiga’s post-conference analysis — an independent research firm, not a vendor — called agentic AI security the defining theme and found roughly 60% of organisations now run AI-augmented automation, up from under 20% in 2023. The trajectory across three years is the framing: 2024 identified the threat surface, 2025 was early tooling, 2026 was the industry committing to a new category and a governance model.
The four signals: a formal analyst category (Forrester ADS), an industry award (Global InfoSec), a live proof-of-failure (OX Security‘s DAST demo), and a standards body commitment (OWASP’s four sessions). When those four validators converge on the same argument, it’s hard to write off as marketing.
Agentic Development Security (ADS) is a security paradigm defined by Forrester Senior Analyst Janet Worthington that protects AI-powered software development end to end — prevention, detection, prioritisation, and remediation of vulnerabilities introduced by autonomous AI coding agents. Worthington introduced the formal ADS category in April 2026, co-authoring Forrester’s post-RSAC recap.
So why a new category? Because no existing label — DevSecOps, AppSec, ASPM — actually describes the threat surface created when AI agents generate, commit, and deploy code without human review loops. The ADS framework covers eight capability areas: code and dependency analysis, coding guardrails, triage and prioritisation, remediation, dynamic testing, quality gates, supply chain protection, and governance analytics. As of RSAC 2026, no single vendor delivers across all eight. That gap is the category-formation signal.
ADS isn’t just an incremental fix. It defines an operating model where security decisions are autonomous and policy-driven. The companion framework is AEGIS, which Forrester introduced as the enterprise governance layer. Its core principle is “least agency” — the AI equivalent of least privilege, where agents only get the capabilities they need for a specific task. AugmentCode published the most accessible public explanation of the ADS framework post-RSAC if you want a plain-English walkthrough.
The SDLC was built for human-paced, sequential development. AI agents break every assumption in that model simultaneously. The ADLC is what you get when agents stop assisting developers and start automating development steps. Code generation, dependency resolution, testing, and deployment can happen without a developer writing a single line. Faros AI’s analysis of over 10,000 developers found that teams with high AI adoption merge 98% more pull requests — but PR review time increased 91%. Security review compresses to near zero.
Here’s the key difference in risk class. The SDLC assumed developers made mistakes at human pace. The ADLC means AI agents make consistent, model-specific mistakes at scale. The same hallucinated dependency can appear across hundreds of files in a single session. The control points in ADS sit at agent instruction, context injection, and autonomous commit — much earlier in the lifecycle than the code review and static scan stages where DevSecOps concentrates.
Checkmarx won Market Leader Application Security from Cyber Defense Magazine at the 14th Annual Global InfoSec Awards. The award is judge-selected, not vendor self-reported — that distinction matters. When award committees recognise an AI code security entrant, it means the category has moved into mainstream enterprise buying consideration.
What Checkmarx announced alongside the award: Triage Assist and Remediation Assist (agents for the post-commit phase), AI Supply Chain Security providing a centralised AI-BOM inventory covering MCP servers, LLMs, AI agents and SDKs, and an enhanced DAST engine built for AI-driven and vibe-coding workflows. Use the award as a starting reference for your vendor shortlist, not a final purchasing decision.
OX Security’s live demo at RSAC 2026 showed an application built primarily with AI-generated code that was vulnerable to an unauthenticated remote code execution attack via a crafted PDF input — a vulnerability the project’s existing SAST scanning had completely missed.
The methodology is what matters here. The demo used DAST — runtime testing against a live application — proving the vulnerability was exploitable behaviour, not a theoretical code pattern. The gap is a context failure: AI-generated code can be locally correct at the function level while being architecturally broken at the application level. DAST tests the running application rather than individual code functions, which is why it catches what SAST misses.
This is a direct answer to the “my linters didn’t flag anything” objection. As Checkmarx puts it, “text-based analysis cannot evaluate architectural correctness”. A correctly formed authentication call placed in the wrong execution path is syntactically valid and contextually broken — it only becomes apparent when the application runs under real-world conditions. For the technical depth on why SAST misses these patterns, see the underlying SAST failure problem.
OWASP ran four dedicated GenAI security sessions at RSAC 2026. The project has grown to 25,000+ members, and four main-floor conference sessions reflects AI security moving from niche track to mainstream concern.
The Q2 2026 publication roadmap covers: the OWASP Top 10 for Agentic Applications 2026 developed with 100+ industry experts, the Guide for Secure MCP Server Development (published February 2026), the SBOM/AIBOM Generator, and the AI Security Solutions Landscape for Agentic Red Teaming (April 2026). OWASP AIVSS v0.8 is also in development — extending CVSS concepts to AI-specific risk quantification.
For FinTech and HealthTech teams, the compliance signal is real. EU AI Act enforcement for high-risk AI was set for August 2026, with fines up to €15 million or 3% of global turnover. A November 2025 Omnibus revision proposes pushing some obligations out to December 2027, so the deadline has some uncertainty. The guidance does not. For organisations moving from awareness to action, the DevSecEng organisational shift explains what the structural response looks like. For the full standards breakdown, check the OWASP AI Testing Guide article.
The scepticism is fair. The RSAC 2026 vendor floor had both genuine category innovators and repackaged incumbents.
The test that separates them: whether the vendor’s detection logic is AI-code-aware at the analysis level, not just at the reporting level. Veracode’s Spring 2026 GenAI Code Security Report — 80 development tasks, 150+ LLMs, no security-specific prompting — found AI-generated code introduced vulnerabilities in 45% of tasks. CodeRabbit’s analysis found AI-authored PRs produced 2.74× more XSS vulnerabilities. Neither of those are vendor numbers.
The ADS eight pillars are a more reliable evaluation framework than any vendor positioning statement. Ask each vendor which capability areas they cover natively versus via integration, and which they don’t cover at all. The AI-native challengers — ZeroPath in SAST, OX Security’s evidence-based ASPM approach — differ structurally because their analysis engines were built for AI output patterns from the start. For a structured comparison, see the vendors who differentiated at the conference. For the full picture of the AI code security blind spot this conference addressed — covering diagnosis, organisational response, tooling, and compliance — see the series overview.
The ADLC is Forrester’s term for the lifecycle where AI coding agents generate, review, and ship code at machine speed. Humans set intent and guardrails; agents handle execution. Terminology variants exist: Cycode uses “ADLC” and “Agentic-SDLC” interchangeably; AWS uses “AI-DLC” for their open-source framework.
Janet Worthington is a Senior Analyst at Forrester Research and co-author of Forrester’s post-RSAC 2026 recap. As an independent analyst, her ADS category definition carries weight with enterprise buyers in a way vendor-produced frameworks simply don’t.
Least privilege limits what users can access. Least agency applies the same logic to AI agents: agents receive only the capabilities needed for a specific task. The distinction matters because AI agents can act across multiple systems simultaneously — least agency limits blast radius at the task level.
Slopsquatting is where adversaries pre-register package names that AI models predictably hallucinate. Analysis of 576,000 AI-generated code samples found 20% recommended non-existent package names, with 43% of those hallucinated names consistently recommended across ten separate queries — predictable enough to pre-register.
Yes. Veracode’s Spring 2026 GenAI Code Security Report — 80 tasks, 150+ LLMs, no security prompting — found 45% of tasks introduced a known security flaw. Forrester, CSA, and OWASP all reference this figure as a credibility anchor.
OWASP AIVSS v0.8 extends CVSS concepts to AI-specific risk, giving teams a standardised method for prioritising AI agent vulnerabilities. It gives security teams and compliance auditors a shared language for rating AI agent risks. Finalisation is expected alongside the Q2 2026 OWASP publications.
Forrester’s eight ADS capability areas give you the evaluation grid: code and dependency analysis, coding guardrails, triage and prioritisation, remediation, dynamic testing, quality gates, supply chain protection, governance analytics. Ask vendors to identify native coverage versus integration coverage for each area. No vendor currently covers all eight natively — anyone claiming otherwise should be asked to demonstrate it against AI-generated code samples, not human-authored test cases.
EU AI Act enforcement for high-risk AI was originally set for August 2026 with fines up to €15 million or 3% of global turnover. A November 2025 Omnibus revision proposes pushing some obligations to December 2027. For organisations in regulated sectors, OWASP’s GenAI sessions and publication roadmap are already being referenced by compliance teams as the practical controls framework — regardless of where the final deadline lands.
100% of surveyed organisations (Cycode 2026) confirmed they have AI-generated code in their codebase; 81% have no visibility into how it’s being used. AI-generated code jumped from 22% to 27% in a single quarter. The ADS framework starts with an inventory step — assess current AI tool usage, identify where AI output enters the codebase, measure existing scanning coverage against AI-specific vulnerability classes. If you haven’t started that inventory, start there.
An AI-BOM inventories every AI component in the software stack: LLMs, MCP servers, AI SDKs, coding agents, and the code they generated. It extends traditional SBOM concepts to the AI-specific supply chain. SPDX 3.0 has been extended with a dedicated AI profile supporting both NIST AI RMF and EU AI Act requirements.
The #1 AppSec Blind Spot: Why AI Code Defeats Traditional SASTAccording to DX Research’s Q1 2026 analysis of 500+ organisations, 27% of all production code is now AI-generated. More than one in four lines your team ships came out of GitHub Copilot, Cursor, or something similar. And your SAST tools were not built for any of it.
The problem is structural. Veracode’s GenAI Code Security Report found 45% of AI-generated code contains security vulnerabilities — and traditional scanning misses a big chunk of them. Not because the tools are misconfigured. Because the vulnerabilities don’t look like anything the tools were built to find.
What follows is a breakdown of the broader AppSec shift now underway — covered comprehensively in our securing the AI-generated code pipeline overview — the four SAST failure modes, three named attack patterns, the vibe coding problem, and a self-assessment checklist. The data is from Veracode, DX Research, ZeroPath, and RSAC 2026. No vendor pitches.
At 27% of production, AI-generated code has gone from novelty to a fact of life — and any systematic gap in how that code gets scanned is an organisation-wide exposure. Veracode tested over 100 LLMs and found 45% of AI-generated code contains at least one security flaw. CSA and Endor Labs arrived at 62% using a different methodology. CVEs formally attributed to AI-generated code jumped from 6 in January 2026 to 35 in March 2026. That’s not a blip.
The mismatch is structural. SAST was built around human coding conventions: consistent naming, traceable intent, coherent access control logic. AI output often has none of those things. Veracode calls the downstream consequence “vulnpocalypse” — as AI code volume scales, undetected vulnerabilities pile up faster than security teams can work through them. RSAC 2026 confirmed these findings as a genuine industry inflection point, not vendor-manufactured alarm.
SAST works by matching code against a library of known vulnerability signatures. AI-generated code breaks that in four specific ways.
Training data reproduction. LLMs reproduce insecure patterns from pre-2022 GitHub and Stack Overflow training data. The pattern looks syntactically valid, matches no known CVE signature, and still carries the same vulnerability logic.
Hallucinated dependency blindness. When an LLM invents a package name that doesn’t exist in any registry, SAST has no rule to flag it. The package name is novel, not malicious in form. The tool just moves on.
Context-dependent access control failures. AI models generate authorisation logic that looks locally correct but is inconsistent across a codebase. SAST analyses files in isolation — it can’t evaluate whether access control is enforced consistently at the application level.
Prompt-injection sinks. Code generated to handle user input may route that input to LLM calls without sanitisation. SAST rules exist for SQL injection and XSS sinks. Rules for LLM prompt-injection sinks largely don’t — and prompt injection has been the number one vulnerability on the OWASP Top 10 for LLM Applications since 2025.
ZeroPath’s vm2 CVE analysis demonstrates SAST miss rates in AI-generated code that simply don’t appear in human-written equivalents. DAST and SCA partially compensate, but they cover different ground — neither closes the full gap without deliberate toolchain design.
Hallucinated dependencies are non-existent packages that LLMs confidently recommend during code generation. A 2025 USENIX study analysed 576,000 code samples across 16 LLMs and found nearly 20% of recommended packages did not exist — and 43% of those hallucinated names repeat consistently across queries.
That repeatability is what makes slopsquatting tractable as an attack. Adversaries register the npm, PyPI, or other registry names that AI tools are known to hallucinate, then load those packages with malicious payloads. In January 2026, a hallucinated npm package called react-codeshift spread through 237 repositories via AI-generated agent skill files with nobody deliberately planting it.
SAST can’t detect this because the vulnerability sits at the dependency resolution layer. SCA is the right tool category — but only if SCA tools are updated to flag packages absent from known-good registries, not just known-bad ones. The risk compounds further when autonomous agents commit this code to CI/CD pipelines without human review, removing the last manual checkpoint that might catch an unfamiliar package name.
Veracode’s report found Java was the worst performer, with a 72% security failure rate. The Spring 2026 update confirms this: Java’s security pass rate sits at 29%, compared to Python at 62%, C# at 58%, and JavaScript at 57%.
Enterprise Java uses complex access control logic that AI models generate inconsistently. Java’s XML and serialisation handling has historically been one of the richest sources of injection and deserialisation vulnerabilities, and AI models reproduce those patterns with confidence. Scaling up the model doesn’t help either: security performance clusters around the same 55% mark whether you’re using 20B or 400B parameter models. Syntax pass rates have climbed to 95%, but security pass rates haven’t moved.
If your team is shipping AI-generated Java at scale, you’re operating with a higher undetected vulnerability exposure than the headline 45% figure suggests.
The Rules File Backdoor is an attack where adversarial instructions are embedded into AI coding assistant configuration files — Cursor’s .cursorrules files or GitHub Copilot instruction files. When a developer uses a compromised rules file, the AI tool silently introduces backdoors, weakens authentication logic, or adds covert data exfiltration paths — all while generating code that looks functionally correct to anyone reviewing it.
The bypass is clean. The malicious instruction is in the configuration file. The generated code looks fine. SAST scans the code, not the configuration layer sitting above it. Pillar Security researchers demonstrated this attack in practice. Cursor IDE CVE-2025-54135 allowed chaining an indirect prompt injection to trigger remote code execution with no user interaction at all.
This is not a code-layer problem. The response is toolchain governance: controlling which rules files developers can use, reviewing shared rules files, and treating AI coding tool configuration the same way you’d govern third-party plugins.
Vibe coding — coined by Andrej Karpathy in February 2025 — describes delegating most code writing to AI assistants with minimal manual review. It grew 340% year over year in enterprise environments, well beyond the rapid-ideation use case Karpathy had in mind.
The AppSec problem is that vibe coding removes the human review layer that has historically been a compensating control for SAST blind spots. More vulnerabilities enter the codebase. SAST alert volume goes up with a shifted true-positive ratio, because AI-generated code produces patterns SAST rules were never tuned for. AI-assisted commits expose secrets at more than twice the rate of human-only commits — 3.2% versus 1.5%. If vibe coding is the team norm, your AppSec tooling is operating out of specification.
Before making tooling decisions, assess where your current programme has coverage gaps specific to AI-generated code. Only 18% of organisations have established approved AI tool lists. You need your own numbers first.
Six dimensions to assess:
Code origin mapping. What percentage of production code is AI-generated? DX’s 27% is the industry benchmark. Which tools generate it?
SAST rule currency. When were your SAST rules last updated? Do they include rules for prompt-injection sinks and AI-specific vulnerability classes? Most commercial SAST tools haven’t shipped these yet.
Dependency verification coverage. Is SCA running on every pull request, flagging packages absent from known-good registry histories — not just known-bad lists? Catching vulnerabilities before code merges is cheaper than finding them in production.
Access control consistency testing. Does your testing programme include dynamic checks — DAST or manual testing — for authorisation logic across AI-generated API endpoints? SAST alone is not enough.
Rules file governance. Do you have a policy governing which AI coding assistant configuration files developers can use? These attack surfaces have no analogue in traditional SDLC guidance.
Vibe coding visibility. Do you have tooling or policy visibility into whether developers are reviewing AI-generated code before committing? Only 38% of organisations use AI to support code review in pull requests.
Identify the gaps before deciding where to invest. OWASP categories give you a useful framework for prioritising what you find. For a structured assessment of the tools now emerging to address these gaps — from AI-aware SAST platforms to ASPM consolidation — see our vendor comparison. For a complete picture of the broader AppSec shift, including the organisational and compliance dimensions, see our securing the AI-generated code pipeline overview.
Yes. Veracode’s GenAI Code Security Report found 45% of AI-generated code contains at least one vulnerability, with Java reaching 72%. CSA/Endor Labs arrived at 62% via a different methodology. AI-generated vulnerabilities also skew toward classes that SAST is poorly positioned to detect.
AI-assisted coding security is about securing the tools themselves. AI-generated code security is about the vulnerabilities in their output. Both need attention — toolchain governance for the former, upgraded scanning and testing for the latter.
Slopsquatting exploits AI hallucinations: attackers register package names that AI coding assistants commonly recommend but that don’t exist, then load them with malware. Typosquatting requires guessing developer typos. Slopsquatting is more tractable because AI tools hallucinate the same names reproducibly — 43% of hallucinated names repeat consistently.
Yes, but the updates go beyond adding rules. Hallucinated dependency risks require SCA integration and registry verification. Context-dependent access control failures require DAST. Rules File Backdoor attacks require toolchain governance. The four core failure modes need a layered toolset, not an upgraded single tool.
Adversarial instructions inserted into AI coding assistant configuration files — Cursor .cursorrules or GitHub Copilot instruction files — cause the AI tool to silently introduce backdoors or weaken security controls while producing code that looks correct to reviewers. Full explanation with specific CVEs is in the section above.
SAST uses pattern matching against known vulnerability signatures. AI-generated vulnerabilities don’t match those patterns — the code reproduces insecure training-data logic that never matched a CVE, invents package names SAST has no rule for, and produces prompt-injection sinks that SAST rules haven’t been written to detect.
Vibe coding removes the human compensating controls that catch SAST-evasive vulnerabilities. The risk is proportional to how much of the codebase is vibe-coded and whether rules file governance is in place. Without upgraded AppSec tooling, it’s a meaningful security gap.
DX Research’s Q1 2026 analysis reported that 27% of production code is now AI-generated, up from 22% the prior quarter. At that share — carrying the vulnerability characteristics documented by Veracode and CSA/Endor Labs — SAST coverage gaps become an organisation-wide risk.
AI-generated code introduces the hallucinated dependency vector. Supply chain risk traditionally centred on compromised known packages. AI adds packages that don’t exist yet, which attackers can pre-register once they know which names LLMs hallucinate. This expands the attack surface beyond what SCA tools calibrated for known-bad packages can handle.
All three address different failure modes — none is sufficient alone. SAST misses hallucinated dependencies and context-dependent access control failures. SCA is most important for slopsquatting risk. DAST covers context-dependent flaws requiring runtime evaluation. The correct posture is a layered AppSec programme.
A term from Veracode’s research describing the projected accumulation of AI-era security vulnerabilities as AI code scales without adequate detection tooling. A genuine risk trajectory for teams managing security debt.
Check for four capabilities: prompt-injection sink detection for LLM API calls; SCA integration and package registry verification; AI-specific vulnerability pattern libraries updated post-2024; and documentation of how the tool handles AI coding assistant output. If your vendor can’t answer to those four, assume the gap exists and layer in SCA and DAST coverage for AI-generated code sections of your codebase. This article is part of our AI code security overview, which covers the full landscape from tooling failures to compliance requirements.
AI-Generated Code Security: The Application Security Blind Spot ExplainedAccording to DX Research’s Q1 2026 analysis, 27% of all code shipped to production is now AI-generated. Veracode’s Spring 2026 benchmark, covering 150+ language models, found 45% of that code fails basic OWASP Top 10 security criteria. The security pass rate has plateaued at around 55% even as models improve at functional correctness. The gap is not narrowing on its own.
Your application security (AppSec) toolchain was designed for human-authored code reviewed at human pace — not for this volume, this velocity, or the novel vulnerability patterns AI coding assistants introduce. That’s the blind spot, and it’s already in your production environment.
This article is the hub for a six-article series on AI DevSecOps. Each section gives a short, direct answer to one piece of the problem, then points to the article that goes deeper:
Veracode’s 2026 benchmark found 45% of AI-generated code samples fail standard OWASP Top 10 security tests across 150+ language models. For Java specifically, the failure rate reaches 72%. A Cloud Security Alliance study found 62% of AI-generated applications contain design flaws or known vulnerabilities. The security pass rate has plateaued at around 55% despite AI models improving at functional correctness — because the training signal that drives security quality is not the same as the signal that drives compilation and test pass rates.
The numbers hold across independent studies. Georgia Tech’s SSLab Vibe Security Radar tracked 35 CVEs directly attributable to AI coding tools in March 2026 alone — up from 6 in January and 15 in February. Failure patterns cluster around CWE-89 (SQL Injection), CWE-80 (XSS), CWE-117 (Log Injection), and CWE-327 (Insecure Cryptographic Algorithms). The strategic point: adding more AI to the pipeline does not fix the security problem. It scales it.
For a detailed breakdown of which patterns appear most often and why the failure rate hasn’t budged, read why traditional SAST fails on AI-generated code.
The blind spot is the gap between the volume and velocity of AI-generated code reaching production and the capacity of traditional application security tooling to evaluate it. SAST tools were designed to pattern-match known vulnerability signatures in human-authored code. AI output introduces novel patterns — hallucinated dependencies, inconsistent access controls, prompt-injection vectors embedded in code logic — that existing rules do not reliably detect.
At a dominant share of production code, AI-generated output is no longer an edge case reviewers can catch manually. IBM’s X-Force research found 81% of security teams have no visibility into how AI coding tools are actually being used in their engineering organisations. Developers accept AI suggestions 70% of the time without modification, and 56% rarely review AI-generated code line by line. The governance assumptions your existing security programme was built on no longer hold.
The AppSec blind spot explained in depth covers the specific failure modes and what a realistic self-assessment of your coverage looks like.
Traditional static analysis (SAST) and dynamic analysis (DAST) tools rely on known-bad signatures trained on human coding patterns. AI-generated code creates vulnerabilities through architectural gaps and missing controls rather than recognisable bad syntax — a hallucinated package name, a missing authorisation check, a prompt-injection sink in input-handling code. These failure modes are invisible to rules that were never written to look for them.
Four failure modes explain most of the gap: scale mismatch (AI code volume grows faster than review capacity); SAST context blindness (syntactically correct code placed in the wrong execution path); the SCA (Software Composition Analysis) hallucination gap — a USENIX study of 576,000 AI-generated code samples found 20% recommended non-existent package names, making them predictable targets for slopsquatting attacks; and the Rules File Backdoor, where malicious instructions hidden in AI coding assistant configuration files silently alter what code the AI generates.
Read the AppSec blind spot explained for the full failure-mode breakdown.
RSAC 2026 in San Francisco was the moment the industry moved from warning to response. Forrester analyst Janet Worthington introduced the Agentic Development Security (ADS) framework as a formal new category. Checkmarx won the Global InfoSec Award for innovations in AI-generated code scanning. OX Security demonstrated DAST failures against AI-generated code in real time. Four OWASP GenAI sessions previewed new standards due in Q2 2026. The conference was not about awareness — it was about architecture.
The key concept formalised at RSAC 2026 was the Agentic Development Lifecycle (ADLC) — the successor to the traditional SDLC when autonomous agents generate and commit code without consistent human review loops. “Shift left” security assumes there is a “left” to shift to. When agents operate at all stages simultaneously, security has to be embedded everywhere.
Read what RSAC 2026 signalled for application security for the full conference breakdown and what each of those signals means for your planning.
The emerging model is DevSecEng — Development Security Engineering — which shifts security accountability from a pipeline gate to the specification and prompt layer. Rather than scanning code after it is generated, DevSecEng embeds security requirements in the instructions given to AI coding assistants, treats SAST as a blocking gate (not advisory) for AI-contributed code, and adds human-in-the-loop checkpoints for autonomous CI/CD agents.
The practical changes address credential leaks, known vulnerability patterns, and shadow AI before any platform decision. AI code provenance tracking is becoming a compliance expectation under the EU AI Act (enforcement August 2026), and only 12% of organisations currently apply consistent security testing to AI-generated code.
The before-and-after control comparison and a sequenced adoption path are in restructuring the security lifecycle for AI code.
The vendor landscape has reorganised around four capabilities: AI-aware SAST (Checkmarx One, Veracode, Semgrep), application security posture management (ASPM — Cycode, OX Security, Apiiro), prompt-layer interception (Apiiro’s Guardian Agent), and code-to-runtime risk graphs (Wiz). No single platform covers all four. Checkmarx won the RSAC 2026 Global InfoSec Award. Cycode entered the Gartner AST Magic Quadrant in 2025. The selection decision depends heavily on your team size and pipeline autonomy level.
OX Security demonstrated live DAST failures against AI-generated code at the conference. The vendor scepticism question is legitimate: most platforms have rebranded existing SAST with AI-specific detection rules — only a subset have genuinely retrained on AI code patterns. The selection decision depends on your team size, pipeline autonomy level, and current scanner sprawl.
The structured comparison with team-profile-based selection guidance is in the new AppSec vendor landscape.
When an AI agent is the committer rather than a human, five threats emerge that the traditional SDLC threat model does not address: prompt-injected commits, MCP server compromise, slopsquatting (hallucinated-dependency supply chain attacks), agent-identity confusion (agents acting with inherited human permissions), and audit-log forgery. Excessive agency — granting AI agents more permissions than they need — is the root failure mode behind most of these.
The AI-BOM (AI Bill of Materials) extends the SBOM concept to inventory AI model versions, training data provenance, agent plugins, and MCP servers — an emerging compliance requirement. Zero Trust principles now apply to AI agents, with scoped permissions and immutable audit logs as the minimum control architecture.
Read when AI agents commit code autonomously for the full threat model and a reference control architecture.
OWASP’s GenAI Security Project covers the OWASP Top 10 for LLM Applications (2025), the OWASP Top 10 for Agentic Applications (2026), the AI Agent Security Cheat Sheet, and the Secure MCP Server Development Guide. These establish prompt injection and excessive agency as the primary threat categories, and require AI-BOM generation, agent permission scoping, and red-team testing of agentic workflows as baseline controls.
EU AI Act enforcement begins August 2026. OWASP standards are the practical reference most engineering organisations will use to map controls to audit requirements. The full standards translation — what OWASP requires as testable controls — is in what OWASP now requires for AI code security.
The #1 AppSec Blind Spot: Why AI Code Defeats Traditional SAST — Technical diagnosis of why SAST and DAST miss AI-generated vulnerabilities; hallucinated dependencies, slopsquatting, vibe coding, and the Veracode 45%/72% data.
RSAC 2026: The Turning Point for Application Security — Event synthesis of the conference that formalised Agentic Development Security as a category; Forrester ADS framework, Checkmarx Global InfoSec Award, OX Security DAST demonstration.
From DevSecOps to DevSecEng: Restructuring the Security Lifecycle — Process guide for engineering teams; before/after control-point comparison, SAST as a blocking gate, pre-commit secrets detection, 90-day adoption sketch.
The Vendor Race: Checkmarx, Cycode, OX Security, and the New AppSec Stack — Vendor comparison using Forrester’s ADS eight-pillar framework; team-profile-based selection guidance for 50–500 person organisations.
When Agents Commit Code: Securing Autonomous CI/CD Pipelines — Threat model and control architecture for pipelines where AI agents operate without human checkpoints; agent identity management, AI-BOM, excessive agency, EU AI Act urgency.
OWASP AI Testing Guide: What the Standard Requires — Standards translation: OWASP Top 10 for Agentic Applications, Secure MCP Server Development Guide, AI-BOM compliance, audit checklist mapped to EU AI Act August 2026 enforcement.
It depends on the controls in place. Without automated scanning gates tuned specifically for AI code patterns, the risk is material: Veracode’s 2026 benchmark found 45% of AI-generated code fails OWASP Top 10 criteria. With AI-aware SAST as a blocking gate, mandatory secrets detection, and human-in-the-loop checkpoints for high-risk code areas (authentication, payment processing, encryption), AI-generated code is manageable. Deploying it without those controls is not a reasonable posture when 27% of production code is now AI-generated.
Navigation: The #1 AppSec Blind Spot covers which vulnerability patterns to scan for specifically.
AI models are trained primarily to produce code that compiles and passes functional tests. Security correctness — including missing authorisation checks, insecure cryptographic choices, and unsafe input handling — is a property that requires security-specific training signal or reinforcement learning from human security reviewers. The Veracode data shows the security pass rate has plateaued at roughly 55% even as functional benchmarks improve, because the feedback loops that drive security improvement are not present in standard model training pipelines.
Slopsquatting is a supply chain attack where threat actors register malicious packages under names that AI coding assistants hallucinate (invent) when generating dependency code. Unlike traditional typosquatting, which targets human typing errors, slopsquatting targets predictable AI hallucination patterns. Traditional SCA tools that scan against known CVE databases cannot detect these packages because the malicious packages are new and unlisted.
Navigation: When Agents Commit Code covers the full autonomous pipeline supply chain threat model.
Shadow AI refers to AI coding tools used by developers without organisational approval or IT visibility. IBM’s X-Force Threat Intelligence Index 2026 found that organisations with shadow AI exposure face a breach cost premium of $670K compared to those with governed AI use. Currently, 81% of security teams report having no visibility into how AI tools are being used in their engineering organisations.
Start with three controls before anything else: (1) a blocking SAST gate in CI/CD that treats AI-generated code contributions the same as externally-sourced code, (2) pre-commit secrets detection tuned for AI service credential patterns (API keys, tokens), and (3) an inventory of which AI tools your engineers are actually using. These three controls address the highest-probability failure modes — known vulnerability patterns, credential leaks, and shadow AI — without requiring a full platform purchase.
Navigation: From DevSecOps to DevSecEng provides a sequenced 90-day adoption path.
The OWASP GenAI Security Project (genai.owasp.org) hosts the OWASP Top 10 for LLM Applications (2025 edition), the OWASP Top 10 for Agentic Applications (2026), the AI Agent Security Cheat Sheet, and the Secure MCP Server Development Guide. The OWASP AI Exchange (owaspai.org) coordinates the broader AI security standards landscape.
Navigation: OWASP AI Testing Guide: What the Standard Requires translates these standards into engineering-actionable controls.