TL;DR: Agentic application security testing uses structured LLM-driven workflows to reason about code logic, trust boundaries, and multistep exploits that traditional pattern matching misses, according to Arnica’s analysis of Gartner’s June 2026 Innovation Insight. The shift matters because AI-generated code is expanding the attack surface faster than deterministic SAST was designed to cover, making context-aware validation and prioritisation essential.
At a glance
What this is: Arnica says agentic AST adds structured reasoning to application security testing so teams can surface context-dependent flaws that pattern-based SAST often misses.
Why it matters: It matters because AppSec teams are now dealing with AI-generated and multi-component code paths that need contextual validation, not just broader scanning.
By the numbers:
- by 2028, half of organizations with an application security testing program will integrate traditional SAST with agentic AST as a complementary layer.
Context
Application security testing still struggles when the risk sits in code behaviour rather than known signatures. Pattern-based SAST is effective for deterministic checks, but it does not explain what an application is supposed to do, which is why business-logic flaws, authentication bypasses, and multistep exploits often escape shallow scanning.
Agentic AST changes the control problem by adding structured reasoning, trust-boundary mapping, and validation into the testing workflow. For AppSec teams, the relevance is not just detection depth, but whether code testing can keep up with AI-generated development and cross-file logic paths without turning triage into a backlog.
The identity angle is indirect but real: access-control failures, authentication bypasses, and insecure object references are still identity governance problems when they appear in application logic, even if they are found in code rather than an IAM console.
Key questions
Q: Where does traditional SAST fail in application security testing?
A: Traditional SAST fails when the issue depends on application intent, trust boundaries, or execution order rather than a known bad pattern. It is useful for deterministic checks, but it struggles with business-logic flaws, authentication bypasses, and multistep exploits that require contextual reasoning to confirm and prioritise.
Q: Why do contextual code tests matter for AppSec teams?
A: They matter because many of the highest-risk flaws are not obvious from a single file or signature. Contextual testing helps teams decide whether a weakness is reachable, exploitable, and worth prioritising, which is essential when AI-generated code increases the volume of candidate findings.
Q: What do security teams get wrong about more findings in AST?
A: They often assume that more findings equal better security. In practice, value comes from validated, reachable issues that developers can act on quickly. Without exploitability checks and workflow integration, agentic testing can simply create a larger triage queue.
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.
Technical breakdown
Why pattern matching misses logic flaws and multistep exploits
Traditional SAST is built to recognise known code patterns, unsafe functions, and signatures that map cleanly to common vulnerability classes. That works well for deterministic issues, but it fails when the exploit depends on application intent, execution order, or relationships across files and services. Business logic flaws, authentication bypasses, race conditions, and insecure direct object references often require reasoning about how the application is meant to behave, not just how code appears line by line. Agentic AST addresses that gap by using structured reasoning rather than single-pass matching.
Practical implication: use agentic reasoning where the flaw depends on context, control flow, or cross-file state rather than a standalone code pattern.
What an agentic harness changes in code analysis
An agentic harness is the orchestration layer that lets multiple specialised agents work through a testing workflow with shared context. One agent can map architecture and trust boundaries, another can probe specific attack classes, and another can validate whether a finding is actually exploitable. That separation matters because it turns the test into a staged analysis process rather than a flat scan. The result is better coverage of complex attack paths and less dependence on manual review for ambiguous findings.
Practical implication: evaluate tooling on whether it can preserve application context across the testing chain, not just whether it produces more findings.
Why reachability and validation matter more than raw volume
More findings do not improve security if most of them are not reachable in the runtime context. Reachability analysis helps separate exploitable issues from theoretical ones, while dynamic validation checks whether the suspected weakness can actually be triggered. That is especially important in modern AppSec programmes where AI-generated code can multiply the number of potential issues without changing the underlying remediation capacity. Prioritisation therefore has to move from counting vulnerabilities to ranking them by exploitability and business exposure.
Practical implication: wire prioritisation to reachability and validation so development teams work the issues that can be exploited first.
Threat narrative
Attacker objective: The attacker aims to turn contextual application flaws into reachable exploitation paths that bypass intended controls and expose data or protected actions.
- Entry occurs through application code paths that appear safe to pattern-based tools but contain logic weaknesses or inconsistent trust handling.
- Credential or access abuse follows when authentication bypasses, broken access control, or insecure object references let an attacker move through protected workflows.
- Impact is realised through multistep exploitation of reachable flaws that manual review or signature scanning failed to prioritise in time.
Breaches seen in the wild
- Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic AST is best understood as a control shift from pattern recognition to contextual decision-making. The core limitation of traditional SAST is not speed, but its inability to understand intent, trust boundaries, and multi-step exploit paths. That makes it weak precisely where modern application risk concentrates, including business logic and access-control failures. AppSec programmes should treat contextual reasoning as a new testing layer, not a replacement for deterministic scanning.
Trust-boundary mapping is the hidden governance value in agentic AST. Once a testing workflow can identify where one component depends on another, the security discussion moves from isolated code defects to system behaviour. That is where identity and authorisation issues surface in practice, because many application vulnerabilities are really failures in who can do what, and under which assumptions. Practitioners should align testing coverage with trust boundaries, not just repositories.
Reachability is the right filter for AI-era application risk. AI-generated code increases the number of candidate flaws faster than teams can manually triage them, so remediation quality depends on separating theoretical exposure from exploitable exposure. This is a governance problem as much as a tooling problem: security teams need evidence that testing output maps to runtime reality. The right response is to prioritise validation and exploitability, not raw issue counts.
Agentic AST validates a broader AppSec operating model, but only if developers can act on the results. A richer finding set is useful only when it fits into pull requests, ChatOps, and existing fix workflows. That means the testing layer must reduce decision friction, not add another review queue. The practitioner conclusion is straightforward: measure AppSec tooling by closed-loop remediation, not by discovery volume alone.
Agentic application testing becomes a named capability only when it connects context, validation, and prioritisation. Without all three, it is just another automated scan with a more complex interface. The market is moving toward layered testing models because modern code needs both deterministic coverage and reasoning-driven analysis. Teams should therefore design AppSec governance around complementary controls rather than a single testing method.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and insufficient risk controls.
- Read next: Agentic AI Security Guide
What this signals
Context-aware AppSec testing is becoming necessary because AI-assisted development increases the amount of code that can contain logic flaws, while conventional scanning still misses intent-driven weaknesses. The practical shift is toward testing that can reason about trust boundaries, not just search for known insecure patterns.
Agentic AST also changes the governance burden on AppSec leaders. If a tool cannot validate reachability, teams will inherit a larger triage problem rather than a better security signal. The near-term programme question is not whether to replace SAST, but how to layer contextual analysis without slowing delivery.
Application logic is now part of identity governance by another route: access control failures inside code can create the same business risk as weak policy in an IAM stack. Teams should therefore treat authentication bypasses and broken access paths as governance defects, not only coding defects.
For practitioners
- Adopt contextual testing for logic-heavy code paths Target business workflows, authentication flows, and cross-file dependencies where pattern matching is least effective and false negatives are most likely.
- Map trust boundaries before prioritising findings Require any advanced AST workflow to show how it models component relationships, access assumptions, and data movement across the application.
- Validate exploitability before assigning remediation priority Use runtime validation or equivalent proof steps so developers are not forced to treat every candidate issue as equally urgent.
- Align testing output to developer workflows Route verified findings into pull requests and ChatOps so remediation happens inside the same workflow that produced the code.
Key takeaways
- Traditional SAST still struggles most where code behaviour, not code pattern, determines risk.
- Agentic AST adds context, validation, and reachability so teams can focus on exploitable issues instead of raw alert volume.
- For AppSec programmes, the question is no longer whether to scan more code, but whether the testing model can reason about trust and intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic AST in this article is about reasoning over access-control and authentication failure paths. |
| Recommendation — Apply ASI03 to test whether AI-assisted workflows can expose or exploit privilege and identity assumptions in code. | ||
| OWASP ASVS | V8 — Authorization | The article highlights broken access control, IDOR, and authentication bypasses in application logic. |
| V6 — Authentication | Authentication bypasses are explicitly named as a class agentic AST should detect. | |
| Recommendation — Use V8 to verify that access control is enforced in code paths, not only at the UI or perimeter. Use V6 to validate authentication checks in complex workflows and reject assumptions that static patterns prove safety. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The testing problem centres on whether applications enforce authorisation correctly. |
| Recommendation — Use PR.AA-05 to align application testing with actual permission and authorisation outcomes. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This is fundamentally an application security testing and verification problem. |
| Recommendation — Apply CIS-16 to embed verification of high-risk application paths into the software lifecycle. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article focuses on exploit paths that can lead from code flaws to access abuse and spread. |
| Recommendation — Map code-driven abuse paths to TA0006 and TA0008 to improve detection and prioritisation. | ||
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.
- 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.
- Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
- Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management alongside the identity disciplines that underpin modern security programmes. It is suitable for practitioners who need a stronger baseline in governance across human and machine access.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org