What Is Agentic Development Security (ADS)? Forrester's New AppSec Framework

Agentic Development Security (ADS) is a security paradigm defined by Forrester that protects AI-powered software development end to end, spanning prevention, detection, prioritization, and remediation of vulnerabilities introduced by autonomous AI coding agents operating at machine speed.

Why AppSec Needs a New Operating Model for AI Agents

Engineering teams adopting AI coding agents face an uncomfortable arithmetic problem. As agents generate larger volumes of pull requests, and empirical research shows documented flaw rates in AI-generated code, the security review pipeline comes under increasing strain.

The security tooling built for human developers who write, review, and commit code at human speed was never designed for this volume. SAST scanners miss context-dependent flaws, SCA tools cannot detect hallucinated dependencies, and code review processes bottleneck at the first reviewer. As one practitioner framed the problem to Checkmarx: "If you're generating code ten times faster and your security team isn't getting ten times faster, then you're going to have to make difficult decisions, and that's where risk emerges."

Forrester Senior Analyst Janet Worthington highlighted this gap in April 2026 when she published a post arguing that AppSec needs a new model. ADS rejects incremental fixes to legacy AppSec and instead defines an operating model where security is autonomous, continuous, and architected for the speed at which agents generate code.

This guide covers why traditional AppSec breaks under agentic development, what each ADS pillar involves, the vulnerability patterns agents actually introduce, the unresolved runtime accountability problem, and how to build an ADS practice from the ground up.

Why Traditional AppSec Breaks with AI Agents

Traditional application security assumes code moves through a sequential pipeline at human speed: a developer writes code, commits it, a scanner runs, a reviewer triages findings, and a fix is deployed. AI coding agents violate every assumption in that model simultaneously.

Scale Mismatch Overwhelms Review Capacity

The volume problem is measurable. AI-generated code now accounts for roughly 27% of all production code, according to DX's Q1 2026 analysis of 500+ organizations, up from 22% the prior quarter, with daily AI users merging approximately 60% more pull requests than light users. The downstream effect is equally documented: Faros AI analyzed data from over 10,000 developers and found that teams with high AI adoption merge 98% more pull requests, but PR review time increased 91%. Traditional security approaches designed for human-paced development cannot absorb a near-doubling of review volume without either degrading review quality or creating bottlenecks that negate the speed gains agents provide.

SAST Tools Cannot Evaluate Architectural Correctness

Static analysis operates on a foundational assumption AI-generated code systematically violates: that security properties can be determined by examining code as text, independently of runtime context. Checkmarx's analysis of DevSecOps practices in the age of AI highlights that limitations arising from AI-generated code stem from design assumptions: "that code is deterministic, flows are reproducible, and the primary risks lie in traditional vulnerabilities. In AI, these assumptions no longer hold."

When an agent generates a correctly formed authentication call placed in an incorrect execution path, static analysis remains blind. The code is syntactically valid, but the vulnerability is contextual: the flaw exists in placement, not in syntax.

SCA Tools Miss Hallucinated Dependencies

Research presented in a USENIX study on package hallucinations found that package recommendations from AI models sometimes point to packages that do not exist: about 5.2% for commercial models and 21.7% for open-source models. Traditional SCA tools scan manifests for known-vulnerable packages. They cannot intercept a hallucinated dependency at the point of AI recommendation because the hallucinated name does not appear in any manifest until a developer has already acted on the suggestion.

AI Agents Operate as Privileged Insider Actors

AI coding agents are privileged actors within development environments, operating with access scopes that create insider-threat-class risks. GitLab's CISO, writing in a Dark Reading analysis of agentic AI chaos, frames the problem through the insider threat lens: an entity already inside the organization with privileged access that no existing AppSec tool category was designed to address.

The following table summarizes how each traditional tool category fails against agentic development patterns:

Addressing agentic risk at this scale requires coordinated agent orchestration where every workspace is isolated and every output is verified before it reaches production. Intent gives each agent its own git worktree, preventing one agent's changes from affecting another's work, while the Verifier agent validates that implementations satisfy the original intent before changes surface to the developer.

ADS Defined: Forrester's New Category from RSAC 2026

Janet Worthington, Senior Analyst at Forrester, introduced Agentic Development Security in a blog post published in April 2026, shortly after RSAC 2026 in San Francisco. Forrester analysts also presented on their AEGIS framework for securing agentic architectures as part of the main conference program.

Forrester's Formal Definition

Under the heading "Introducing Agentic Development Security (ADS)," Worthington defines ADS as "a new security paradigm focused on protecting AI-powered software development from end to end." Forrester explicitly forecloses incremental rebranding, stating that ADS spans prevention, detection, prioritization, and remediation while providing continuous intelligence across code, dependencies, workflows, and running applications. Crucially, it treats security decisions as autonomous, policy-driven actions rather than alerts handed to overburdened teams.

Three Converging Forces Behind ADS

Worthington identifies three forces that made ADS necessary:

1. Detection commoditization. SAST, DAST, SCA, secrets scanning, infrastructure-as-code scanning, and container image scanning are now table stakes. What separates leaders from laggards is the ability to correlate findings with real-world context: exploitability, reachability, runtime exposure, and business impact.
2. LLMs reshaping security reasoning. LLMs excel at correlating disparate data sources (code repositories, dependency heuristics, security scanners, runtime signals, and workflows) into coherent insights. The value shifts from detection volume to understanding and action.
3. Agentic development generating insecure code at scale. AI coding agents commonly ship unauthenticated or improperly authorized endpoints, trust client-supplied data for security-critical decisions (prices, roles, states), and omit basic controls such as input validation, rate limiting, and server-side checks.

ADS vs. Traditional AppSec

The paradigm shift from traditional AppSec to ADS affects every operational dimension. Forrester enumerates eight capability clusters that compose the full ADS vision, mapped below alongside the traditional AppSec equivalent and current industry maturity:

As of RSAC 2026, no single vendor delivers across all eight capability areas. Supply chain protection against AI-specific vectors (slopsquatting, hallucinated dependencies) and agent-aware quality gates remain the least mature capabilities, while AI-augmented code analysis is the furthest along.

The Four ADS Pillars: Prevent, Detect, Prioritize, Remediate

Forrester's ADS definition centers on four operational pillars: prevention, detection, prioritization, and remediation. Each pillar shifts from manual, human-gated processes to autonomous, policy-driven operations. The specific controls within each pillar draw from NIST, OWASP, and AWS guidance for securing AI-generated code.

Pillar 1: Prevent

Prevention in ADS means stopping insecure AI-generated code from entering the codebase, with controls operating at or before the point of code generation.

The NIST SP 1800-44A practice guide states directly: "AI-based suggestions may inadvertently be accepted by human actors without sufficient scrutiny. There is a real need to employ oversight necessary to prevent insecure and non-functional code from being inserted into the software development process."

Key prevention controls include:

• Provenance tracking of AI-generated code: Mandate tracking of which code was AI-generated, which model produced it, and with what parameters
• Real-time IDE/editor scanning integrated with AI coding tools, identifying insecure patterns and recommending secure alternatives before code reaches staging or production environments
• Security review gates on agent-suggested PRs for critical code areas
• Model, modification, and annotation traceability throughout the development process

These controls operate at different points in the development workflow: provenance tracking and traceability apply at commit time, IDE scanning applies during code generation, and review gates apply at PR submission. Implementing all four creates defense-in-depth for the prevention pillar.

Pillar 2: Detect

Detection in ADS identifies vulnerabilities and anomalous behaviors in AI-generated code at both the code level and runtime, including AI-specific vulnerability classes that traditional scanning misses entirely.

SAST, DAST, API Security, and SCA remain necessary as a baseline. Checkmarx notes in their analysis of AI code security that these tools "are not enough on their own to secure AI-generated code" but "remain essential as a baseline layer of protection." ADS-specific detection adds:

• AI-aware dependency scanning capable of detecting hallucinated and slopsquatted packages not yet in manifests
• Runtime behavioral monitoring of agent actions across the development environment
• Continuous visibility into code execution paths and material changes across the SDLC
• OWASP AIVSS scoring for AI agent-specific risk quantification
• Prompt injection and excessive agency detection per the OWASP agentic risks taxonomy

Forrester's AEGIS framework extends this detection surface further, highlighting prompt injection, agent trust boundaries, and AI-specific detection engineering as attack vectors that traditional DevSecOps practices do not address.

Pillar 3: Prioritize

Prioritization in ADS means risk-ranking vulnerabilities so security teams focus on findings that are exploitable and material, given the volume AI-scale code generation produces.

• OWASP AIVSS v0.8 enables organizations to quickly identify risks associated with AI agent deployments, quantify those risks, and prioritize mitigations
• ASPM platforms correlate findings across SAST, SCA, DAST, and runtime data
• Execution authority analysis determines what code runs, why it runs, and how execution authority is applied
• Context-aware risk scoring distinguishes AI-generated code from human-authored code

A critical dependency limits this pillar's near-term viability. Context-aware risk scoring requires reliable provenance metadata that identifies which code was AI-generated and which was human-authored. As discussed in the Runtime Accountability section below, the infrastructure for binding agent identity to code output is still emerging. Until provenance tracking matures, prioritization in mixed human/AI codebases requires explicit tagging policies enforced at commit time rather than automated classification after the fact.

Pillar 4: Remediate

Remediation in ADS replaces manual developer effort with autonomous agentic fix generation that includes self-validation loops.

• Autonomous agentic fix generation with static analysis and integration checks validating the fix itself
• Agent-as-reviewer loops where a second agent evaluates the first agent's output against the original finding, catching regressions before the fix merges
• Human escalation points at defined risk thresholds, as a required architectural control
• Near-real-time identify-fix-test-deploy loops in AI-native environments
• Traceability of model, modifications, and annotations to enable review of AI-assisted remediation

The following table compares how traditional DevSecOps and ADS handle each operational dimension:

Agent-Introduced Vulnerability Patterns: Empirical Rates and Taxonomies

AI coding agents do not introduce random bugs. They introduce specific, measurable vulnerability patterns that multiple independent studies have documented with CWE-level precision. Understanding these patterns is the foundation for any ADS implementation.

Measured Vulnerability Rates Across Studies

The empirical data spans a wide range depending on study methodology. No single rate generalizes to all AI-generated code in production, but multiple studies converge on the finding that AI-generated code contains measurable security weaknesses. At scale, even the most conservative rate becomes an operational burden: an engineering organization generating 1,000 PRs per week at a 12.1% flaw rate faces over 120 security-relevant files weekly, each requiring triage, assessment, and remediation. At 45%, the same organization produces hundreds of flawed outputs per week, a volume that exceeds most security teams' review capacity.

The following table summarizes the key findings. The Veracode report tested AI code security across 80 tasks on 100+ LLMs and found 45% of AI-generated code contains security flaws, with Java worst at 72%. A GitHub analysis by Schreiber and Tippe scanned 7,703 files from public repositories using CodeQL with CWE mapping and found 12.1% of AI-generated files contain at least one vulnerability. Earlier Copilot security research by Pearce et al. found roughly 40% vulnerable output in security-relevant scenarios, while Liu et al. analyzed 31,132 AI agent skills and found 26.1% contain at least one security vulnerability.

Dominant Vulnerability Patterns by CWE

The highest-severity vulnerabilities appearing consistently across multiple studies cluster into specific patterns:

Injection Flaws (CWE-89, CWE-78, CWE-94, CWE-79)

In at least one large AI-generated code study, injection vulnerabilities carried the highest average CVSS scores among reported CWEs. SQL injection (CWE-89), OS command injection (CWE-78), and code injection (CWE-94) appear repeatedly. Snyk's analysis found that Copilot draws on insecure context from the surrounding codebase as signal during generation. Existing insecure patterns in a repository get replicated and amplified across new code as a result.

Hardcoded Secrets (CWE-259, CWE-798, CWE-532)

AI-assisted code leaked secrets at roughly double the GitHub-wide baseline throughout 2025, according to GitGuardian's State of Secrets Sprawl 2026 report. Claude Code-assisted commits specifically showed a 3.2% secret-leak rate versus the 1.5% baseline across all public GitHub commits. The same report found 28.65 million new hardcoded secrets pushed to public GitHub in 2025, a 34% year-over-year increase, with AI service credential leaks specifically reaching 1.28 million (up 81% in a single year). The mechanism is structural: LLMs learned from millions of public repositories where developers hardcoded secrets, and the models reproduce the pattern because inline credentials represent the fastest path to functional output. An ACM Transactions on Software Engineering and Methodology study of 733 real-world AI-generated snippets found security weaknesses in 29.5% of Python and 24.2% of JavaScript output, with insufficient randomness (CWE-330) among the most prevalent.

Missing Security Controls (CWE-307, CWE-306, CWE-400)

AI agents often omit defensive controls. CWE-307 (improper restriction of authentication attempts) appeared in 5.91% of ChatGPT JavaScript output. CWE-400 (uncontrolled resource consumption) appeared in 7.00% of ChatGPT JavaScript findings. A separate Tenzai analysis of 15 production applications built using five major AI coding tools found that every application lacked CSRF protection, had no security headers configured, and contained SSRF vulnerabilities: a clean sweep of missing basic controls across the entire sample.

The False Confidence Multiplier

Snyk's AI Code Security Report found that more than half (56.4%) of developers frequently encounter security issues in AI-generated code, yet 80% still bypass their organizations' AI code security policies to use these tools. Separately, Snyk's 2024 Open Source Security Report found that nearly 80% of respondents believe AI tools generate more secure code, directly contradicting the empirical findings. ADS treats this confidence gap as a first-order risk: developers accept AI suggestions with less scrutiny than they apply to human-authored code.

Agentic AI-Specific CVEs: A Growing Attack Surface

Beyond code vulnerabilities, agentic AI infrastructure itself carries documented CVEs. A Trend Micro report documents that agentic AI CVEs rose from 74 to 263 between 2024 and 2025. MCP, a specification that launched in late November 2024, accumulated numerous CVEs affecting MCP servers and implementations within its first year.

A real-world example: the cai cybersecurity AI agent framework (v0.5.9) contained a command injection vulnerability (CVE-2025-67511) disclosed by Checkmarx, with no patch available at disclosure.

Runtime Accountability: Binding Code to Agent Identity

Accountability for AI-generated code changes remains an unresolved problem in ADS.

Why Accountability Requires Agent Identity

The NCCoE concept paper on software and AI agent identity highlights the need for access management systems to distinguish between agent and human identities and to manage actions ranging from human-in-the-loop approval to autonomous responses. The goal is linking specific AI agent and software system actions to the identity of the non-human entity and enabling effective visibility into actions taken, data generated, and outcomes of automated activities.

Runtime accountability requires three interlocking components:

1. Agent identity: Treating AI agents as distinct, first-class identity principals with their own credentials, permissions, and audit trails, separate from the human users who invoke them
2. Code attribution: Binding every commit, PR, or artifact to the agent that produced it with cryptographic verifiability
3. Provenance tracking: A tamper-evident record of who did what, when, and why across the entire software supply chain including AI-generated steps

The Emerging Technical Stack

Four layers of standards and tools form the emerging infrastructure for agent accountability:

Layer 4: Policy Enforcement      → in-toto layout policies, SLSA levels
Layer 3: Provenance Attestation  → in-toto Attestation Framework, SLSA provenance schema
Layer 2: Cryptographic Signing   → Sigstore (Cosign + Rekor transparency log)
Layer 1: Agent Identity          → SPIFFE/SPIRE, OIDC tokens, OpenID Foundation spec
Layer 0: Regulatory Baseline     → NIST SSDF, NCCoE concept paper

Sigstore uses OIDC tokens to enable identity-based signing without managing long-lived keys. The OpenSSF annual report highlights continued advances in Sigstore and trusted publishing across major package ecosystems.

in-toto, a CNCF-graduated project, models the supply chain as a series of steps, generating signed link metadata for each step. The functionary concept maps directly to AI agent identity: an AI agent performing a code generation step can be registered as a functionary, with its outputs captured in signed link metadata. The gap for AI agents specifically is that current in-toto implementations assume functionaries are deterministic build tools, not probabilistic models that produce different output from the same input. Adapting the framework to handle non-deterministic agents requires policy definitions that validate output properties rather than exact reproducibility.

SLSA provides a graduated framework where its Source Track requires that every change in a revision's history have at least one strongly authenticated actor identity (such as an author, uploader, or reviewer) and a timestamp. The SLSA Source Track was introduced in SLSA v1.2 RC1. Current AI coding agents do not satisfy this requirement out of the box: most agents commit code under the invoking developer's identity rather than their own. Unless organizations implement dedicated agent service accounts, the SLSA authentication requirement remains unmet for AI-generated changes.

The Critical Gap at RSAC 2026

At RSAC 2026, five vendors shipped agent identity frameworks, but the frameworks focused on tracking agent identity rather than what the agent actually did. Identifying an agent is necessary but insufficient. Full runtime accountability requires binding identity to behavior: which agent generated which code, under which instructions, with what tool access, and whether the output matched the declared intent.

This identity-to-behavior gap is where living specs provide structural advantages. When every agent task originates from a living spec that records what was requested, what was planned, and what was produced, the audit trail binds agent identity to declared intent. Intent's Coordinator agent analyzes the codebase and generates tasks from the spec. Implementor agents execute in parallel. The Verifier agent then checks results against the spec and flags inconsistencies. This three-layer accountability chain makes each agent's role and output traceable back to the original specification.

How Intent Addresses ADS Concerns

ADS requires infrastructure that enforces isolation, verification, and traceability at machine speed. Intent provides architectural primitives that map directly to ADS requirements, even though Intent is a developer productivity tool rather than a security product.

Isolated Workspaces: Containment at the Architecture Level

Intent organizes work into isolated workspaces, each backed by its own git worktree. Every workspace is a safe place to explore a change, run agents, and review results without affecting other work. This isolation model addresses the ADS prevention pillar by constraining agent blast radius: an agent operating in one workspace remains isolated from other workspaces, and changes to the main branch or CI/CD execution are typically gated by human-approved merges and automated verification.

This containment model contrasts with AI coding tools that allow agents to modify the working directory directly. Isolated workspaces create a structural boundary where agent outputs must cross a review gate before reaching shared infrastructure.

Verifier Agent: Automated Validation Against Declared Intent

Intent includes a Verifier agent that validates implementations before changes surface to the developer. The Verifier checks results against the spec and flags inconsistencies, bugs, or missing pieces. This operates within the development loop itself, catching discrepancies between what was specified and what was built, rather than relying on external scanners that run after code is committed.

The Verifier does not replace dedicated security scanning. SAST, SCA, and DAST remain necessary baselines for vulnerability detection. The Verifier adds a layer that security scanners cannot provide: validation that the code matches the developer's declared intent. This catches the "positionally wrong code" failure mode where individually correct code is placed in an incorrect execution context.

Living Specs: The Audit Trail from Intent to Implementation

Intent's spec-driven workflow centers on living specs that coordinate development. Specs auto-update as agents complete work, reflecting what was actually built. When requirements change, updates propagate to all active agents.

For ADS purposes, living specs create a continuous record of:

• What the developer intended (the original spec)
• What the Coordinator agent planned (the task breakdown)
• What the Implementor agents built (the code changes)
• What the Verifier agent validated (the consistency check)

This four-layer record satisfies NIST SP 1800-44A's requirement for mechanisms tracing models, modifications, and annotations. Living specs provide this traceability structurally rather than as a separate logging layer: every change is anchored to a declared specification.

Why Role Separation Matters for ADS

Intent's agent model separates responsibilities across distinct roles: a Coordinator plans, Implementors execute, and the Verifier validates. This separation is architecturally important for ADS because it creates auditability that single-agent systems cannot provide. When one agent both generates and validates code, no independent check exists; the same reasoning process that introduced a flaw is responsible for detecting it. Role separation means the Verifier operates with a different objective (spec conformance) than the Implementor (code generation). This creates an adversarial dynamic where inconsistencies surface rather than compound.

Users can stop the Coordinator at any time to manually edit the spec, maintaining a human-in-the-loop checkpoint. The multi-agent architecture means each agent understands the broader codebase before generating code. This reduces the cascading-failure risk that arises when agents operate with independent prompts and partial information.

Limitations and Tradeoffs

Intent's ADS-relevant capabilities have boundaries that teams should understand before relying on them for security governance:

• Spec quality determines audit quality. Living specs only capture what the developer declared. If the spec is underspecified, ambiguous, or wrong, the entire audit trail validates the wrong thing. The Verifier checks implementations against the spec, so a spec that omits a security requirement (such as rate limiting or input validation) will produce a passing verification on code that is insecure. Teams need security-aware spec templates and review processes for the specs themselves.
• Verifier coverage is not security scanning. The Verifier validates spec conformance, not vulnerability detection. It catches "did the code do what we asked?" rather than "is what we asked safe?" Classes of issues like injection flaws, hardcoded secrets, and missing authentication controls require dedicated SAST/SCA/DAST tooling. The Verifier and security scanners address different failure modes and should be treated as complementary layers.
• Workspace isolation adds operational friction. Each isolated workspace is a separate git worktree. For teams running many parallel agent tasks, workspace proliferation creates merge complexity, disk usage, and coordination overhead. The isolation boundary is valuable for containment, but teams should plan for workspace lifecycle management (creation, cleanup, conflict resolution) as part of their ADS workflow.
• Audit trails are development-scoped. Living specs record intent, plan, implementation, and verification within the development workflow. They do not extend to runtime behavior, deployment, or production monitoring. Full ADS accountability requires integrating Intent's development-phase audit trail with runtime observability and agent identity infrastructure described in the Runtime Accountability section.

Mapping Intent Features to ADS Pillars

The following table maps each ADS pillar to the corresponding Intent feature and mechanism:

Supply Chain Risks from Agent Dependencies

AI coding agents introduce supply chain attack vectors that differ from traditional dependency risks. Three categories demand specific ADS attention.

Slopsquatting: Hallucinated Package Exploitation

Slopsquatting, a term coined by Seth Larson, describes a supply chain attack where adversaries register package names that LLMs predictably hallucinate. Unlike typosquatting, which exploits probabilistic human typing errors, slopsquatting exploits model-specific errors that are predictable and repeatable. This makes them reliable attack targets rather than opportunistic ones.

The USENIX Security 2025 study found 45% of hallucinated package names are consistently regenerated every time the model is queried with the same prompt, with about 60% reappearing at least once across 10 subsequent queries. Attackers can identify which fictitious names a given model reliably suggests, register those names, and position malicious packages for auto-installation.

A documented incident in January 2025: Google's AI Overview recommended a package called @async-mutex/mutex, which typosquatted the legitimate async-mutex library. The package contained code to steal Solana private keys and exfiltrate them via Gmail's SMTP servers.

MCP Server Compromise

The MCP ecosystem resembles the npm ecosystem in 2015: rapidly growing, predominantly built by individual developers, and minimally governed. An Endor Labs report on the state of dependency management found that about 75% of MCP servers are built by individual developers, roughly 40% lack license information, and 82% interact with sensitive APIs requiring careful access controls.

The first documented malicious MCP server in the wild appeared in September 2025: an npm package called postmark-mcp impersonated Postmark, operated as a functional email MCP server through its first 15 versions, then added a one-line backdoor in version 1.0.16 that secretly BCCed every message to an attacker-controlled address.

Rules File Backdoor

Attackers embed malicious instructions into AI coding tool configuration files such as .cursorrules. Agents that consume these configuration files inject the embedded malware into projects automatically. The same technique can steer an agent's dependency selection toward attacker-controlled packages, compounding supply chain risk through a vector that no package manager or SCA tool inspects.

The following table summarizes how AI agent supply chain attacks differ from traditional supply chain risks:

Building an ADS Practice from Scratch

Building an ADS practice requires phased adoption aligned to organizational maturity. The following framework draws from NIST, OWASP, and Forrester's AEGIS.

Phase 0: Current State Assessment (Weeks 1-4)

Step 1: Agent discovery. Conduct a full inventory of all AI agents operating in the development environment. Governance rules must be specific and applied from a single centralized place. Capture which agents exist, what credentials they run with, what tools and APIs they can call, and who owns them.

Step 2: Threat model against OWASP Agentic Risks. Map each discovered agent against the OWASP AIVSS framework. Prioritize immediate actions such as tool scoping, credential isolation, and verifying audit trail existence.

Step 3: SSDF gap analysis. Use NIST SP 800-218A as a checklist against current secure development practices in alignment with the Secure Software Development Framework (SSDF).

Phase 1: Policy Development (Weeks 4-8)

Five policies form the minimum viable ADS governance layer:

1. Least agency / minimum permissions. Forrester's AEGIS framework centers on least agency as a core control: agents should receive only the minimum permissions, capabilities, tools, and decision-making authority necessary for a specific task. A documented governance failure illustrates why: Amazon's internal AI coding tool Kiro caused a 13-hour production outage by deleting and recreating a production environment.
2. Human-in-the-loop checkpoints. Define which agent actions require human approval. A practical classification: routine changes (formatting, docs, tests) can be auto-approved with logging; refactoring and isolated bug fixes can be AI-approved with logging; new features and business logic require human review; security and infrastructure changes require mandatory human review before execution.
3. Agent identity policy. Each agent receives a non-human identity, typically a dedicated service account. Credentials are not shared with human accounts. Agent identity is captured in all audit trails.
4. MCP and tool integration policy. Research found MCP security flaws across many tested server implementations. Any MCP server or external tool integration must pass a security review before agents are permitted to use it.
5. AI SBOM policy. Adopt SPDX 3.0 for AI-aware Software Bills of Materials. Forrester recommends using SBOMs for transparency and compliance in software supply chain security, while discussing agentic AI governance separately through frameworks such as AEGIS.

Phase 2: Tooling Selection (Weeks 6-12)

ADS tooling spans six categories, and no single vendor covers all of them. For teams with limited budgets, prioritize in this order: (1) agent identity and access management, because unscoped credentials represent the highest-severity, lowest-effort risk; (2) SAST with AI awareness, because detection is a prerequisite for prioritization; (3) observability and audit logging, because you cannot govern what you cannot see. Categories 4-6 can be deferred until Phases 1-3 are operationally stable.

The selection criteria for any tool in these categories: Does it distinguish between AI-generated and human-authored code? Does it integrate with your existing CI/CD pipeline without requiring workflow redesign? Does it provide API-level audit logging that captures agent identity? Tools that cannot answer yes to at least two of these three questions will create governance gaps.

Phase 3: Workflow Integration (Weeks 10-16)

Three integration steps establish ADS as an operational capability:

• Centralize agent configuration so one security engineer can disable a tool in one place and have it automatically disabled across all agents. This centralized revocation capability is a prerequisite for expanding agent autonomy.
• Integrate agentic security into threat modeling using the OWASP agentic guide as a required checklist for any PR introducing or modifying agent capabilities.
• Adopt spec-driven development for agent tasks. The migration path starts with requiring written specifications for any agent task that touches security-critical code paths (authentication, authorization, payment processing, PII handling). Expand to all agent tasks once the team has established spec review discipline. GitHub's spec-driven approach and Intent's living specs both emphasize specifications as a central artifact; Intent's advantage is that the spec auto-updates as agents work. This creates a continuously accurate record rather than a static document that drifts from implementation. Teams that skip spec-driven workflows for agent tasks lose the audit trail connecting intent to output. Post-incident attribution becomes harder without that chain.

ADS Maturity Model

The following model maps the progression from ad hoc agent usage to autonomous-safe governance. Note that maturity is not always linear: a single incident (such as the Kiro production outage) can force regression from Managed to Defined if the incident reveals policy gaps. Organizations should also expect different maturity levels across different agent deployments; a team's CI/CD agents may be at Managed while their IDE coding agents remain at Ad Hoc. Assess maturity per agent category rather than organization-wide.

Enforce Agent Isolation and Verification Before Scaling Autonomy

The structural tension in ADS is speed vs. accountability. AI agents generate code at machine speed, but security tooling, identity standards, and governance frameworks are still catching up. Forrester's core insight holds: incremental improvements to legacy AppSec will not bridge this gap.

The practical starting point is containment. Isolate agent execution environments, verify outputs against declared intent, and establish audit trails before expanding agent autonomy. Organizations that build this infrastructure now, while NIST and OWASP are still finalizing standards, will have the governance foundation in place when compliance mandates follow.

Intent's isolated workspaces, Verifier agent, and living specs provide a practical implementation of these ADS principles: every agent works in a contained environment, every output is validated against a specification, and every change carries an auditable trail from intent through execution.

FAQ

Related

• 6 Best Spec-Driven Development Tools for AI Coding in 2026
• 5 Best AI Coding Agent Desktop Apps Compared for 2026
• 5 Best Agentic Development Environments for Enterprise Teams in 2026
• 8 Best AI Tools for Spec-Driven Development
• Intent vs Claude Code: Terminal Power Meets Multi-Agent Orchestration