Agentic AST is closing the gap in application security testing

At a glance

What this is: This is an analysis of agentic application security testing and its key claim that structured AI-driven workflows can surface context-dependent vulnerabilities beyond traditional pattern matching.

Why it matters: It matters because AppSec, IAM, and platform teams increasingly need to govern code and access paths that only emerge through multi-step reasoning, especially as AI-generated software expands the risk surface.

By the numbers:

• By 2028, half of organizations with an application security testing program will integrate their traditional SAST with agentic AST as a complementary layer.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arnica's analysis of agentic application security testing and AI SAST

Context

Traditional application security testing is good at matching known patterns, but it struggles when the risk sits in business logic, authentication flows, or vulnerabilities that only appear across multiple files and execution paths. That gap matters in application security because the most damaging defects are often the ones that require context rather than signatures, and AI-generated code is increasing the volume of code that needs that kind of review.

In this article, the vendor positions agentic AST as a complementary layer rather than a replacement for deterministic scanning. The identity angle is indirect but real: when code governs authentication, authorization, secrets handling, or service-to-service trust, AppSec failures become identity failures as well. That makes the article relevant to both software security and the governance of privileged access patterns embedded in applications.

Key questions

Q: How should security teams use agentic AST alongside traditional SAST?

A: Use traditional SAST for deterministic pattern detection and agentic AST for context-heavy defects such as business-logic flaws, authentication bypasses, and cross-file exploit chains. The two controls are complementary, not interchangeable. The strongest programmes route each finding type to the tool best suited to prove whether it is real and reachable.

Q: Why do AI-generated code changes increase application security risk?

A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.

Q: What breaks when security testing focuses only on known vulnerability patterns?

A: Teams miss defects that depend on application intent, multi-step interactions, and cross-component behaviour. That is where business-logic flaws, authorization failures, and chained exploits usually live. Pattern-only testing creates a false sense of coverage because it finds obvious mistakes while leaving context-dependent attack paths untouched.

Q: How can teams tell whether an AppSec finding is truly actionable?

A: A finding is actionable when the application reaches the flaw in a real execution path and the issue creates meaningful impact if exploited. Teams should look for reproducibility, business reach, and exposure to sensitive workflows. If those signals are absent, the item may be noise, not a priority vulnerability.

Technical breakdown

Why pattern matching misses logic flaws in application code

Traditional SAST tools are designed to spot known vulnerability signatures, insecure APIs, and recognizable unsafe patterns. They work well when the defect is structurally obvious, but they struggle when a flaw depends on business intent, trust boundary movement, or the interaction between multiple components. Agentic AST attempts to compensate by using a structured workflow that can reason across code, identify relationships, and explore whether a path is actually exploitable. The important distinction is that reasoning is not just scanning with a different model. It is orchestration, context retention, and validation applied to code security problems that are not line-by-line in nature.

Practical implication: teams should reserve agentic AST for defects that depend on context, not as a blanket replacement for deterministic scanning.

How an agentic harness changes code discovery and validation

An agentic harness coordinates specialised agents so each one can focus on a narrower task, such as context mapping, discovery, validation, or prioritisation. That matters because security findings become more useful when they are independently confirmed and tied to runtime reachability rather than simply listed as possibilities. In practice, the architecture combines large language model reasoning with workflow controls that reduce false positives and separate candidate issues from exploitable ones. This is especially useful for complex authentication bypasses, broken access control, and logic flaws that span several files or services.

Practical implication: validate whether the tool can prove exploitability and reachability before adding another stream of unconfirmed findings.

Why AI-generated code expands the AppSec control problem

AI-generated code increases the amount of software that can ship quickly, but it does not reduce the number of trust decisions embedded in that code. If anything, it raises the pressure on review processes because more code is produced faster, with more opportunities for hidden assumptions around access control, secrets handling, and data flow. That creates a governance problem as much as a testing problem. Agentic AST is being positioned as one way to keep pace with that acceleration, but the underlying issue is still control coverage across code, pipelines, and runtime behaviour.

Practical implication: align code review, secrets governance, and runtime validation so AI-generated code does not bypass existing control expectations.

Threat narrative

Attacker objective: The attacker aims to exploit context-dependent application logic to bypass controls and reach sensitive functions or data that deterministic scanning may not have flagged.

1. Entry begins when vulnerable application logic, rather than a simple signature, allows an attacker to reach an unexpected code path through broken access control or authentication bypass.
2. Escalation follows when the flaw spans multiple components or trust boundaries, letting the attacker chain requests, influence state, or reach a higher-privilege function.
3. Impact occurs when the attacker uses the logic flaw to access data, alter execution flow, or trigger a business process that was never meant to be reachable.

NHI Mgmt Group analysis

Agentic AST is becoming a compensating control for code that cannot be judged by pattern alone. Traditional SAST still has value, but it is structurally weak when the defect depends on application intent, chained requests, or trust boundary movement. That is why agentic workflows matter: they add context, validation, and prioritisation to problems that would otherwise sit in a manual review queue. For AppSec leaders, the practical conclusion is that code security coverage must now distinguish between known-pattern detection and reasoning-based discovery.

AI-generated code is turning application logic into an identity and access governance problem. When software controls authentication, authorisation, secrets, or service-to-service trust, a missed flaw can become an access-control failure rather than a simple code defect. That intersection is where IAM and AppSec increasingly overlap, because the application itself becomes a policy enforcement surface. Teams should treat code review failures as governance failures when privileged paths are embedded in application logic.

Reachability-informed prioritisation is the named concept that matters here. Security teams do not need more findings; they need findings tied to code paths that are actually reachable in runtime context. The article’s emphasis on validation and prioritisation reflects a wider market shift toward exploitable-risk reduction rather than backlog inflation. The practitioner takeaway is to measure tools by whether they separate theoretical weakness from reachable attack surface.

Agentic AST will not replace developer responsibility, but it will expose where developer workflows are too slow for modern release velocity. The report’s emphasis on developer-native delivery is a reminder that finding defects is only half the job. If remediation does not flow into the tools engineers already use, even high-confidence findings become operational noise. Security leaders should evaluate whether their AppSec operating model can absorb more precise findings without creating review bottlenecks.

The market is moving toward layered testing, not binary replacement. Gartner’s forecast that half of application security programmes will combine traditional SAST with agentic AST by 2028 points to augmentation, not substitution. That suggests the category is maturing around complementary control coverage, where deterministic tooling handles known patterns and agentic systems handle reasoning-heavy cases. Practitioners should plan for coexistence, integration, and governance rather than tool consolidation alone.

What this signals

Agentic AST is a sign that AppSec programmes are moving from broad discovery toward evidence-based prioritisation. For teams that already struggle with triage debt, the lesson is straightforward: if a tool cannot prove exploitability, it is only adding noise.

Reachability-informed prioritisation: the next control maturity step is not more findings, but better discrimination between theoretically vulnerable code and paths an attacker can actually use. That is where developer workflow integration and runtime validation matter most.

For identity-heavy applications, the governance boundary is shifting closer to code. Authentication logic, secrets handling, and service-to-service authorisation are no longer just implementation details; they are security controls that need continuous assurance.

For practitioners

• Map AppSec coverage by defect type Separate deterministic vulnerabilities from logic-heavy issues, then assign agentic AST only to the classes that require context, cross-file reasoning, or exploit validation.
• Require runtime reachability before prioritisation Do not let unverified findings dominate backlog triage. Use reachability evidence to rank issues that can actually be exercised in the application’s current runtime context.
• Integrate findings into developer workflows Push validated results into pull requests, ChatOps, and ticketing so developers can act without moving to a separate security console.
• Review AI-generated code paths for control drift Inspect code produced by AI-assisted development for authentication, authorization, secrets handling, and cross-service trust assumptions that may bypass existing review habits.
• Measure false-positive suppression and validation depth Track how many findings are independently confirmed, how many are reachable, and how many are removed before reaching engineering queues.

Key takeaways

• Agentic AST is best understood as a reasoning layer for defects that pattern-based SAST cannot reliably surface.
• The practical value comes from validation, reachability, and developer-native delivery, not from more findings.
• As AI-generated code expands, application security and identity governance increasingly converge around the same control failures.

Key terms

• Agentic AppSec: An application security model that embeds detection, remediation, and policy enforcement into AI-assisted development workflows. It treats AI coding tools and remediation agents as part of the security control plane, not just productivity software that developers use informally.
• Agentic Harness: The orchestration layer that lets a model choose tools, execute actions, and repeat a task loop until a goal is met. In practice, it is what turns a model from a responder into an actor, so identity and privilege controls must govern the harness, not just the model.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.

What's in the full article

Arnica's full blog post covers the operational detail this post intentionally leaves for the source:

• How the agentic harness orchestrates specialist agents across discovery, validation, and remediation
• Examples of the context-mapping workflow used to reason across files and trust boundaries
• Why reachability analysis changes the way teams prioritise findings for remediation
• How the Developer Feedback Loop reduces false positives and fits into pull request workflows

👉 The full Arnica post covers the agentic harness, reachability analysis, and developer-native remediation workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the software delivery and access patterns that AppSec teams now depend on.