What Is Agentic Development Security? The Stages, Starting Before the Code

Written by:

Pixee

Published on:

Nov 6, 2026

On This Page

TOC Element

Updated November 2026

Agentic development security (ADS) is Forrester's term for protecting AI-powered software development from end to end. It spans prevention, detection, prioritization and remediation, and it treats security decisions as policy-driven actions rather than alerts handed to a team. In practice the work runs in stages, from the design an agent builds from to the fix a developer merges.

If your engineers now hand whole tickets to coding agents, you've probably heard the term this year from an analyst and from several vendors, each using it a little differently. The definitions agree on the middle of the work, finding and fixing flaws in code. They say little about the two ends, the design the agent builds from and the person who approves what it changes.

What is agentic development security?

Janet Worthington, a senior analyst at Forrester, introduced the term in a blog post published April 2, 2026. She describes ADS as "a new security paradigm focused on protecting AI-powered software development from end to end," covering code, dependencies, workflows and running applications. Her starting point is that application security testing has reached an inflection point, where "detection alone is no longer a source of durable differentiation."

Forrester names three forces behind the shift. First, in Forrester's words, "Detection is becoming commoditized; context is not." Second, large language models are changing how security tools reason about risk. Third, software development itself is becoming agentic and "generating insecure code at scale."

The post then lists eight capability themes an ADS program needs:

1. AI-driven code and dependency analysis

2. Guardrails for AI-assisted coding

3. Intelligent triage and prioritization

4. Automated remediation

5. Dynamic testing of live applications and APIs

6. Policy-driven software development lifecycle quality gates

7. Supply chain and toolchain protection

8. Governance, reporting, and risk analytics

Two more points matter to a buyer. Forrester says no single vendor delivers the full ADS vision today, and it describes what's missing as an operating model that treats security as "an autonomous, continuous function." It also promised a landscape report and a Wave evaluation.

The landscape arrived on May 27, 2026, as The Agentic Development Security Tools Landscape, Q2 2026, and several vendors have announced their inclusion. We haven't found a published ADS Wave as of this update.

Vendors have since taken the term in their own directions. Snyk's June 2026 post on the agentic development lifecycle says traditional AppSec "secures the artifact" while ADS "secures the process that creates it," and it places agent risk in three spots: what agents use, what they do and what they generate. Augment Code's ADS guide credits Forrester and builds its explainer on her post. Cycode now titles its homepage "Agentic Development Security Platform," calls itself "the leader in agentic development security" and extends the label to citizen developers in marketing, finance and ops.

None of Forrester's eight themes names the design. A coding agent starts there, from a ticket, a PRD or a design doc, and it builds what the document says. If the spec never says the export file must be encrypted, the agent has no reason to encrypt it, and no scanner will flag a requirement nobody wrote down. Design review was hard to staff before agents arrived, and it rarely survives past the first ticket.

What is agentic coding security?

Agentic coding security is the narrower job of securing the agent session itself, meaning what the agent can reach, run, connect to and remember. It covers the credentials the agent holds, the tools and MCP servers it can call, the sandbox it runs in and the memory it carries between sessions. The OWASP Secure Coding with AI Cheat Sheet applies least privilege to agents, noting that "a coding agent does not need access to email, payment, or administrative tools," and recommends ephemeral credentials scoped to the current task.

ADS includes agentic coding security as one of its stages and extends past it, to the design, the findings and the fixes. Traditional AppSec covers the code but assumes a person wrote it and a person will fix it. The table sets the three side by side.

	Traditional AppSec	Agentic coding security	Agentic development security
What's protected	The application and its code	The agent session: credentials, tools, MCP servers, sandbox, memory	The development process, from the spec to the merged fix
Who acts	Scanners find; people triage and fix	The agent, inside limits a platform or security team sets	Agents across the lifecycle, with people approving the decisions that change code
Where it starts	When code is committed or built	When an agent session starts	In Forrester's themes, at the agent and the code; we'd start at the design
Who approves	Security reviews findings; developers write and merge fixes	The team that sets agent permissions; developers review agent pull requests	Forrester's definition doesn't say; we'd have a developer approve each merge, with policy deciding what reaches them
What's measured	Findings, coverage, time to fix	Permission scope, blocked actions, sandbox boundaries	Findings resolved end to end, false positives removed, time from finding to merged fix

The agent-side controls get their own treatment in how to secure AI coding agents and the best tools for securing AI coding agents in 2026.

The stages of agentic development security

Mapping ADS to the work an agent actually does gives seven stages. Forrester's themes cover the middle stages well. The table adds the stage before the code and names who approves at each step, since agents now act at most of them.

Stage	What goes wrong when an agent is doing it	Control that helps	Who approves	Forrester theme	Tool category (Pixee where GA)
1. Design: the PRD or ticket the agent builds from	The spec is silent on auth, encryption or audit logging, so the agent builds without them	Security review of the spec before code: extract its security promises, model the threats, flag what it leaves out	The spec owner, with AppSec	No direct match among the eight	Design review. Pixee Foresight reviews the spec before code exists, extracts its security promises and flags the gaps; Pixee's triage and fix handles what later reaches code (stages 4 and 5)
2. Agent session: what the agent can reach, run and connect to	Broad credentials, unvetted MCP servers, auto-accepted commands, sub-agents inheriting the parent's permissions	Least privilege, sandboxing, short-lived scoped credentials, MCP allowlists or gateways	The platform or security team that sets agent permissions	Guardrails for AI-assisted coding; Supply chain and toolchain protection	Agent platforms, sandboxes and MCP gateways. Not a Pixee capability
3. Code: what the agent writes	Insecure patterns at volume; vulnerable dependencies pulled in without review	SAST, SCA and secrets scanning on every change, plus a look at each repository from an attacker's side	No approval yet; everything here is a candidate finding	AI-driven code and dependency analysis	Your scanners, plus Pixee Beacon, which builds a threat model of the repository, maps its attack surface, studies it the way an attacker would and hands what it verifies to triage
4. Triage: which findings are real	Volume buries the few exploitable findings, and teams stop reading alerts	Exploitability analysis with written reasoning, across every tool you run	AppSec sets the policy; each verdict carries reasoning anyone can audit	Intelligent triage and prioritization	Pixee: an exploitability verdict with its reasoning for each finding, across the tools you already run, with up to 95% fewer false positives
5. Fix: the change that closes it	Fixes that break builds or ignore house style get closed unread	Fixes written in the repository's own conventions and checked before a person sees them	The developer who owns the code	Automated remediation	Pixee: merge-ready fixes that match your conventions, each checked by a separate Fix Evaluation Agent before it opens as a pull request
6. Merge: who approves	An agent deletes a failing test to turn CI green, or edits files outside its task	Pull-request-only changes, branch protection, CI and rollback	A developer, every time	Policy-driven software development lifecycle quality gates	Your code host and CI. Pixee opens pull requests only and never commits directly
7. Over time: does the code still match the design	A promise in the spec never reaches the code, gets built differently, or a feature appears that the design never authorized	Compare each landed PR with the design's promises and threat model	The spec owner decides whether the code or the design changes	No direct match; dynamic testing of live applications covers the running app, a separate job	Pixee Foresight flags drift when a PR lands, in those three forms, alongside Pixee's triage and fix (stages 4 and 5)

Stage 1 is the one Forrester's themes don't name. It's also where an agent's instructions come from, so a control missing from the spec goes missing from every implementation the agent writes. Spec-driven development makes that dependency explicit, and securing spec-driven development covers the practice.

Stage 2 belongs to whoever runs your agent platform, and the policy side of it is laid out in our governance framework for agentic AI.

Stages 4 and 5 hold Forrester's triage and remediation themes, and they're where most teams lose time today. Forrester describes the remediation it wants as "validated fixes that preserve functionality," a higher bar than a suggestion in a code comment. A fix that a separate check has already tested against the original finding reaches the developer as a small diff to read and approve.

Is there one platform that covers security from design review to the fixed code?

Not completely. Forrester's April post said no single vendor delivers the full ADS vision, and the agent session and dynamic testing still sit with separate tools. One platform can work across most of the rest: the design review in stage 1, an attacker's view of the code in stage 3 alongside your scanners, triage and fixes in stages 4 and 5, and the drift check in stage 7. The merge in stage 6 stays with your code host and your developers.

Pixee is one example. Pixee reviews the spec before code exists (Pixee Foresight), and it decides which findings from every tool are real and opens merge-ready fixes that developers approve (Triage & Fix). Both run on one context graph, so design review and triage work from the same picture of your applications.

Across triage and fix, Pixee reaches a 94% end-to-end resolution rate, measured from scanner finding to handled decision (Pixee customer cohort, 2025). Pixee Beacon studies each repository the way an attacker would and hands what it verifies to the same triage and fix. The Pixee platform overview shows how design review connects to triage and fix, and Pixee as your purple team covers the attacker's-eye half.

Here is how that maps to Forrester's eight themes, gaps included.

Forrester ADS theme	Pixee (GA)	Coverage
AI-driven code and dependency analysis	Pixee Beacon studies the code; dependency findings come from your SCA tool, and Pixee triages and fixes them	Partial
Guardrails for AI-assisted coding	Not covered	No
Intelligent triage and prioritization	Exploitability verdicts with reasoning, up to 95% fewer false positives	Yes
Automated remediation	Merge-ready pull requests for code and dependency findings	Yes
Dynamic testing of live applications and APIs	Pixee works the findings your DAST tool produces; it doesn't run dynamic tests	No
Policy-driven software development lifecycle quality gates	Pixee doesn't enforce gates; it opens pull requests and developers approve every merge	No
Supply chain and toolchain protection	Not covered (MCP servers, agent skills, build toolchain)	No
Governance, reporting, and risk analytics	Every triage verdict and fix is recorded with its reasoning	Partial

If you're asking because you want fewer tools, our guide to consolidating security tools covers how teams decide what to retire.

What should an application security strategy look like when AI writes most of the code?

A strategy for agent-written code gives every stage an owner and measures what gets resolved at the end of the line. In order:

1. Review the spec before an agent builds from it. Pull out the security promises in each PRD or ticket, such as encryption, authentication and audit logging, and flag what the spec leaves out, so the agent's instructions include the controls.

2. Govern what the agent can reach and run. Give agents least-privilege credentials scoped to the task, run them in a sandbox and keep an allowlist for MCP servers. How to secure AI coding agents covers the controls.

3. Keep your scanners, and add an attacker's view of each repository. Rule-based tools catch known bad patterns. A threat model of the repository shows which entry points reach which sensitive assets, which is where an attacker starts.

4. Triage every finding in one place, with reasoning you can audit. Give each finding one exploitability verdict, whatever tool raised it, so the queue shows what is reachable and real.

5. Fix through pull requests your developers approve. Generated fixes should match the repository's conventions and pass an independent check before a person reviews them.

6. Measure resolution. Track the share of findings that reach a handled decision (fixed, or closed with a recorded reason) and the time from finding to merged fix. Finding counts rise with every agent you add and say little about risk.

7. Check what ships against what the design promised. Compare landed changes with the spec's security promises, and send drift back to the spec owner.

Who approves the merge?

Forrester's definition treats security decisions as "autonomous, policy-driven actions, not just alerts handed to overburdened teams," and describes quality gates "enforced by autonomous agents rather than manual review." Neither line says who signs off when an agent changes production code. OWASP's cheat sheet is specific about why someone should. It warns that "AI agents make CI green by deleting failing tests, weakening assertions," notes that agents routinely touch files beyond the requested scope, and tells teams to "Require explicit developer approval before merging any AI-generated code."

Our position on approval follows OWASP's. Automation proposes the change and a developer approves it, through the same pull request review, CI checks, branch protection and rollback the team already uses. Agents can take the triage and the drafting off a developer's plate, and the merge stays a human decision.

Does that make security review the bottleneck when agents write most of the code? Only if review still starts from raw findings. When findings arrive already triaged with their reasoning, and fixes arrive already checked against the original issue, the reviewer reads a small diff and decides whether to merge it. Our AppSec Weekly briefing on agents that ran actions nobody approved shows what happens without an approver.

Where does that leave Forrester's definition?

Forrester's definition asks a program to prevent, detect, prioritize and remediate, and to treat security decisions as actions rather than alerts. None of its eight themes names the design the agent builds from, and the step most definitions skip is a developer approving the fix. A program that covers both ends, and measures the middle by what gets resolved, covers what Forrester described and the work an agent actually does.

FAQ

Who coined the term agentic development security?

Forrester senior analyst Janet Worthington introduced it in a blog post on April 2, 2026. Forrester followed with The Agentic Development Security Tools Landscape, Q2 2026, published May 27, 2026. Vendors including Snyk and Cycode now use the term on their own sites.

Does agentic development security replace DevSecOps?

It extends DevSecOps to a lifecycle where agents write and change code. Scanning in CI, code review and branch protection all stay, and ADS adds controls for the agent session, the spec the agent works from and the decisions agents now take on their own.

Is threat modeling part of agentic development security?

Forrester's eight themes don't name threat modeling, but it fits two stages. A threat model of the design shows what the spec must promise before an agent builds it. A threat model of the code shows which entry points reach sensitive assets once the code exists.

Can AI agents fix vulnerabilities without human review?

Agents can write the fix, and OWASP recommends a developer approve the merge. Keep agent-written fixes on the pull request path, with a separate automated check of each fix before a developer reviews it and your existing CI and rollback behind it.

How do you measure an agentic development security program?

Measure what happens at the end of the stages, starting with the share of findings that reach a handled decision. Add the false positives removed before a person reads them and the time from finding to merged fix. Finding counts alone grow with every agent you add.

What's the difference between agentic development security and AI security posture management?

AI security posture management (AI-SPM) inventories the AI models, agents and data an organization runs and checks how they're configured. ADS covers how software gets built when agents write it, from the spec to the merged fix. A company running coding agents usually needs both, owned by different teams.

Weekly Intel

AppSec Weekly

The briefing security leaders actually read. CVEs, tooling shifts, and remediation trends — every week in 5 minutes.

Weekly only. No spam. Unsubscribe anytime.