Agentic Development Security Tools

The problem this category exists to solve is not that AI writes bad code. It writes code that works.

It writes code that passes the tests, satisfies the ticket, and is exploitable by default. Forrester's own phrasing is close to that: functionally correct, exploitable by default, because the agent is optimising for correctness and brevity rather than for risk.

And because the optimisation is systematic rather than random, the mistakes are too. A human developer makes idiosyncratic errors that vary by person and by day. An agent applies the same reasoning to every problem it sees, which means the same weakness appears in ten thousand places rather than one. Application security was built for the first pattern and is now facing the second.

What agents get wrong, specifically

Forrester's research names the failure modes concretely, and the list is worth reading closely because it is not what most people assume.

Agents commonly ship endpoints that are unauthenticated, or authenticated but improperly authorised. They trust data supplied by the client for decisions that should never depend on it, including prices, user roles, and application state. They omit basic controls: input validation, rate limiting, server-side checks. And they reuse insecure patterns readily, including string-built queries, unsafe file handling, and eval or exec constructions.

Every one of those produces software that demonstrably functions. A price that comes from the client works perfectly until somebody edits it. An endpoint with no authorisation check serves the right data to the right user for as long as only the right user calls it.

This is why the traditional review model fails here in a way people underestimate. A reviewer looking at agent-generated code sees plausible, idiomatic, well-structured work. The absence of a server-side check is invisible unless you go looking for it, and the volume means nobody has time to go looking for it in every diff.

Detection stopped being the product

The other half of the category's rationale is about the application security market itself, and Forrester is blunt about it.

Static analysis, dynamic analysis, software composition analysis, secrets scanning, infrastructure-as-code scanning, and container image scanning are all table stakes now. The market is crowded, capabilities overlap heavily, and finding issues is no longer a durable differentiator. Most tools can find problems. Far fewer can say which ones matter or how to fix them.

What separates the field is context: whether a finding is actually exploitable, whether the vulnerable path is reachable, whether the component is exposed at runtime, and what the business impact would be. Prioritisation, validation, and remediation have become the competitive ground.

Large language models turn out to be genuinely good at exactly this correlation problem, pulling together code repositories, dependency heuristics, scanner output, runtime signals, and workflow context into something coherent. Applied well, that means fewer false positives and fixes that reflect how the software is actually built and deployed.

Forrester adds a caveat that buyers should hold onto. New entrants can use those strengths to address long-standing complaints about legacy tooling, but they typically do not replicate the depth or breadth of coverage the incumbents built over a decade. A tool with excellent reasoning over shallow detection is a different proposition from one with deep detection and poor prioritisation, and both exist in this market.

Two problems in one category

The vendor Cycode framed the scope neatly in its own commentary on the report, describing ADS as solving two problems simultaneously: security for AI, meaning governing the AI layer of the development lifecycle including tools, models, agents, MCP servers, and generated code, and AI for security, meaning deploying agents to automate the security work itself.

That is a vendor's framing rather than Forrester's, but it captures something real about why this category is awkward to evaluate. A platform can be excellent at one half and absent from the other, and both halves are legitimately in scope.

Forrester's own definition leans toward the first while assuming the second. ADS is described not as a product category or a rebranding of existing tools but as a security paradigm covering AI-powered development end to end, spanning prevention, detection, prioritisation, and remediation, with continuous intelligence across code, dependencies, workflows, and running applications. The line that matters most: it treats security decisions as autonomous, policy-driven actions rather than alerts handed to teams who are already overwhelmed.

Alerts do not scale against machine-speed generation. That is the whole argument.

Inside The Agentic Development Security Tools Landscape, Q2 2026

The first mapping of this market published in Q2 2026 as The Agentic Development Security Tools Landscape, Q2 2026, authored by Janet Worthington with Amy DeMartine and Caroline Provost, covering thirty five vendors.

It is a Landscape, so nobody is scored or ranked. A Forrester Wave evaluation of this category has been signalled but not yet published, which means any vendor claiming analyst validation here is pointing at inclusion in a market map.

Publicly confirmed inclusions so far include Apiiro, Cycode, Endor Labs, ReversingLabs, and NSFOCUS. Thirty of the thirty five have not yet announced, so treat that as a sample rather than a shortlist.

The vendors that have announced come from noticeably different origins, which is characteristic of a new category assembled from adjacent markets. Software supply chain security, application security posture management, dependency analysis, and threat intelligence are all represented, and what each firm did before ADS existed still describes what it is best at.

The eight capability themes

Forrester groups the capabilities that define an ADS platform into eight areas. They are worth listing because they function as a usable evaluation checklist, which is unusual for a category this young.

AI-driven code and dependency analysis that goes past pattern matching to assess exploitability, logic flaws, and real risk in context.

Guardrails for AI-assisted coding that steer agents and developers toward secure outcomes and stop unsafe instructions from executing in the first place.

Intelligent triage and prioritisation that continuously ranks findings by exposure and business impact rather than by severity score.

Automated remediation for both code and dependencies, producing validated fixes that preserve functionality.

Dynamic testing of live applications and APIs, adapting to application behaviour and modern architectures, including detection of flaws from the OWASP Top 10 for Large Language Model Applications.

Policy-driven quality gates in the development lifecycle, enforced by autonomous agents rather than by manual review.

Supply chain and toolchain protection covering AI coding agents, extensions, Model Context Protocol servers, agent skills, pipelines, and artefacts.

Governance, reporting, and risk analytics producing durable insight over time rather than point-in-time snapshots.

Notice that the second item, guardrails, is the one that breaks with everything AppSec has done historically. Every other capability on that list is a variant of finding, ranking, or fixing problems after they exist. Guardrails shape what gets generated. That is the genuinely new idea in this category, and it is only possible because the code is being written by something that can be instructed.

The supply chain nobody has inventoried

The seventh capability theme deserves its own attention, because it describes an attack surface most organisations have not enumerated.

An AI coding agent does not just write code. It pulls in extensions, connects to Model Context Protocol servers, loads agent skills, invokes tools, and selects third-party dependencies autonomously. Each of those is a component with a supplier, an update cadence, and a trust relationship, and almost none of them go through the procurement or review process that governs conventional software dependencies.

Forrester's framing points at exactly this: AI components including models, MCP servers, agent skills, IDE extensions, and plug-ins are entering the software supply chain faster than human review capacity can absorb.

There is a specific and nasty variant worth understanding. Agents sometimes select dependencies that do not exist, hallucinating plausible package names based on patterns in their training data. If a developer accepts that suggestion, the install fails and somebody notices. If an attacker has registered that package name first, having observed which names models tend to invent, the install succeeds and the attacker is now executing code inside your build pipeline.

That failure mode has no analogue in human development, because humans do not systematically invent the same wrong package name.

Nobody does all of it

The most useful sentence in Forrester's framing is also the most inconvenient for vendors. Today, no single vendor delivers the full ADS vision.

Some are strong at code analysis. Others at supply chain. Others at runtime intelligence or governance. What is missing across the market is a unified operating model that treats security as an autonomous, continuous function aligned to how agentic development actually works.

Forrester attributes that fragmentation to the paradigm still forming rather than to vendor failure, and frames it as both risk and opportunity.

For a buyer the practical translation is straightforward. Do not run a procurement process designed to select one winner in a category where no winner exists. Work out which of the eight capability themes matter most given how your teams actually build, accept that you will either combine tools or accept gaps, and structure contracts on the assumption that this market will look substantially different in eighteen months.

It also means the vendor claiming full coverage is the one to probe hardest, because Forrester has said in public that nobody has it.

The category next door

This sits directly opposite Forrester's agentic development platforms category, and the pairing is worth understanding as a single system.

Agentic development platforms are where agents write software. Agentic development security is what governs the output. Forrester's ADP research talks about the market maturing from clever assistants into trusted software delivery infrastructure, and trusted is the word that hands the problem to this category.

There is a sequencing implication. Organisations tend to adopt the generation tooling first, because it produces visible productivity, and reach for the security tooling after the volume becomes uncomfortable. That order is understandable and expensive, because the guardrails capability only helps with code written after it is in place. Everything generated before is a remediation backlog.

If your organisation is already running coding agents at scale without any of this, the useful first step is not a procurement exercise. It is finding out how much agent-generated code is in production and whether anyone reviewed it.

What to test

Ask for the failure list, not the feature list. Take Forrester's specific examples, unauthenticated endpoints, client-trusted authorisation data, missing rate limiting, string-built queries, and ask the vendor to demonstrate catching each one in agent-generated code. These are the documented failure modes. A platform that cannot show them is selling something else.

Test guardrails separately from detection. Prevention and detection are different products bundled under one label. Ask specifically what happens at the moment an agent is about to generate something unsafe, and whether the intervention is a block, a warning, or a finding raised afterwards.

Demand an inventory of your AI toolchain as a proof of value. Ask the vendor to enumerate which coding agents, extensions, MCP servers, and skills are in use across your development organisation. The result will be uncomfortable and it is the single most useful artefact you can get out of an evaluation.

Check the remediation claim carefully. Automated fixes that preserve functionality is the promise. Ask what proportion of generated fixes are accepted without modification by your own engineers, and ask to see the validation step rather than the fix.

And ask about false positives with real numbers. The reason detection got commoditised is that everyone can find things. The reason teams ignore security tooling is that most of what it finds does not matter. In a category built on machine-speed volume, a tool with a poor signal-to-noise ratio does not create work, it creates a backlog nobody opens.

Forrester does not endorse any vendor named here, and inclusion in a Landscape report is not a rating or a recommendation to buy.