TL;DR: Application security testing still depends on SAST, DAST and SCA, but Arnica argues agentic development changes the timing problem because agents can create risky code faster than scan schedules, while applications remain the entry point in 68% of global enterprise breaches, according to the article. The control question is shifting from finding flaws later to governing what gets generated before it reaches the pipeline.
At a glance
What this is: Arnica argues that application security testing is being pressured by agentic development, which can create risk faster than scheduled scans can absorb it.
Why it matters: This matters because AppSec, IAM and platform teams now need to govern code generation as well as code review, or they will keep scanning cleanly after risky content has already been introduced.
By the numbers:
- Applications are the most exploited entry point in 68% of global enterprise breaches, according to Arnica.
Context
Application security testing is the set of controls used to find vulnerabilities before attackers do, across source code, dependencies and runtime behaviour. Arnica frames the 2026 problem as a timing gap: agentic development can produce risky changes faster than conventional scan schedules can inspect them, which weakens the assumption that security review always happens before exposure.
The governance issue is not that SAST, DAST and SCA stop mattering. It is that they were built around a human-paced development model, while agent-driven workflows can compress code creation and merge cycles into a much shorter window. For security and platform teams, the real question is whether controls govern generation, pipeline entry, and testing all at once.
The article is about application security testing, but it also has a real identity angle because agentic development changes who or what is effectively producing code. That creates a governance overlap with human IAM, NHI-style control of software actors, and policy enforcement around non-human actions in the SDLC.
Key questions
Q: What breaks in application security testing when agentic development outpaces scan schedules?
A: The control that breaks first is timing. SAST, DAST and SCA still find real issues, but they no longer guarantee that risky code was blocked before it entered the pipeline. When code generation is continuous, the security model has to move upstream and constrain output before review and scanning begin.
Q: Why does faster code generation increase application risk even if scan coverage stays the same?
A: Because coverage and timing are not the same thing. A team can scan broadly and still miss the point if insecure code lands before the scan runs. Risk rises when the organisation assumes post-generation detection is sufficient, even though the dangerous content already exists in the repo or build path.
Q: What breaks when application security testing is moved too late in the delivery cycle?
A: Late testing turns vulnerabilities into backlog, which increases alert fatigue and encourages teams to work around controls. Developers lose context, fixes take longer, and security becomes a blocking event rather than a design input. In practice, delayed feedback raises the chance that issues survive into production unchanged.
Q: How should organisations govern agent-generated code in application security programmes?
A: They should treat agent output as a governed security input, with policy enforced at generation time and not only in CI/CD. That means controlling what the agent can produce, validating policy coverage across repositories, and keeping SAST, DAST and SCA as downstream verification rather than the first line of defence.
Technical breakdown
Why SAST and DAST lose timing advantage in agentic development
Static application security testing scans code before execution, while DAST probes running applications after deployment. Both assume there is a predictable interval between code creation, review and release. Agentic development compresses that interval because code can be generated, modified and submitted continuously. The result is not that the tools fail technically, but that their operating model becomes less reliable as a control boundary. Security findings may still be valid, yet they arrive after the risky content has already entered a pull request or dependency set. That shifts the design problem from deeper scanning alone to earlier policy enforcement in the creation path.
Practical implication: move control points upstream so unsafe code patterns are constrained before SAST or DAST ever see them.
How software composition analysis fits a dependency-heavy codebase
Software composition analysis inventories open source dependencies and flags known vulnerabilities, license issues and outdated packages. In modern application stacks, most of the attack surface sits in third-party libraries rather than handwritten code, which is why SCA sits beside SAST and DAST rather than replacing them. The technical limitation is reachability and context. A vulnerable package is not equally dangerous in every application, and a raw CVE list creates noise unless the scanner can determine whether the code path is actually callable. That makes transitive dependency visibility and exploitability context more important than a simple package count.
Practical implication: tune SCA to prioritise reachable dependencies and transitive packages instead of treating every CVE as an equal blocker.
Why agent-configured rules change the security boundary
The article’s most material architectural shift is the idea of writing security rules directly into agent configuration files before code lands. That moves enforcement from a pipeline gate to a generation-time policy layer. In practice, this is a governance problem about non-human software actors: if the agent can create code, then the policy that constrains its output must travel with the agent, not sit only in the CI pipeline. This reduces the volume of avoidable findings downstream, but it also creates a stronger dependency on configuration integrity, repository coverage and policy propagation across all connected workspaces.
Practical implication: treat agent configuration as a governed control surface and verify that policy updates propagate across every repo and workspace.
Threat narrative
Attacker objective: The attacker objective is to exploit application weaknesses that were created faster than the organisation could scan, review or block them.
- Entry occurs when agentic development generates code patterns or dependencies that bypass the normal human review cadence before traditional scanners run.
- Credential or logic-risk exposure follows when insecure code, hardcoded secrets or unsafe dependencies are introduced into the repository and pipeline.
- Impact emerges when those weaknesses reach production-ready code paths, increasing the chance of application exploitation or breach entry.
Breaches seen in the wild
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
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 development creates a code-generation trust gap: security teams have spent years hardening review and scan stages, but the new risk is that non-human actors can introduce unsafe code before those stages fire. That changes application security from a post-generation detection problem into a governance problem about what may be generated at all. Practitioners should treat agent output as a controlled security input, not just a developer productivity feature.
Application security testing still matters, but its control point has moved: SAST, DAST and SCA remain necessary because they cover different phases of application risk, yet none of them can compensate for a creation process that moves faster than the pipeline can inspect. This is where the intersection with NHI and agentic AI security becomes real: the system that writes code now needs policy boundaries just as much as the system that deploys it. Practitioners should re-evaluate where enforcement begins.
Security policy must travel with the agent, not only with CI/CD: the article’s strongest operational idea is that rules encoded into agent configuration reduce downstream noise and prevent avoidable findings from entering the pipeline. That is a governance shift, not a tooling tweak. It points to a broader market direction where identity, authorization and policy controls are applied to software actors before they can produce artefacts. Practitioners should design for policy propagation, not only pipeline inspection.
Application security programmes now need non-human control concepts: the old assumption was that code review and scan cadence could keep pace with development. Agentic workflows break that assumption by creating output continuously and at machine speed. That makes governed agent behaviour, policy enforcement and repository coverage the deciding factors, not just scanner breadth. Practitioners should align application security with NHI-style governance of software actors.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Application security is becoming a governance problem for non-human actors: once code can be generated continuously by agents, the control question shifts from inspection to authorization. That is a material identity issue because the actor producing the artefact now needs policy boundaries, not just the developer reviewing it. Teams should expect AppSec and IAM conversations to converge around who or what is allowed to create code and under what constraints.
Secret sprawl is a useful warning signal for agentic development programmes: internal repositories are 6x more likely to contain secrets than public ones, according to the State of Secrets Sprawl 2026, which is a reminder that private code is not automatically controlled code. As agentic workflows expand, the security model has to assume that speed increases exposure unless policy moves upstream.
Agent configuration is now part of the application security perimeter: if security rules live only in the pipeline, the agent can still generate unsafe output before enforcement. The programme implication is straightforward: policy propagation, repository coverage and rule integrity deserve the same attention as scanner tuning.
For practitioners
- Enforce policy before code generation Push approved security rules into agent configuration so risky patterns are constrained before code is written or committed.
- Tune SAST and DAST for pipeline timing Run static checks at commit time and runtime checks against staging on every deployment, but do not rely on them as the first control point.
- Prioritise reachable dependency risk Use SCA to focus on transitive packages and exploitable paths, not just raw CVE volume, so teams fix what can actually be reached.
- Verify policy propagation across repositories Confirm that every connected repository and workspace receives the same agent ruleset when security policy changes, otherwise coverage becomes inconsistent.
Key takeaways
- Agentic development changes the AppSec timing model by letting unsafe code appear before traditional scans run.
- The article’s core warning is that SAST, DAST and SCA still matter, but they are no longer enough as first-line controls.
- The strongest control response is to govern code generation directly, then use scanners as downstream verification.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, OWASP SAMM and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Agent-generated code and dependency paths can introduce misconfiguration into exposed application interfaces. |
| Recommendation — Use API8 reviews to detect misconfiguration risks before agent-produced code reaches exposed endpoints. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article centres on securing code before it reaches runtime, which maps to application security verification. |
| Recommendation — Apply V15 requirements to gate insecure code patterns before they become part of the build. | ||
| OWASP SAMM | Secure Architecture — Secure Architecture | The article is about embedding security earlier in the development lifecycle and governing how software is produced. |
| Recommendation — Use Secure Architecture practices to move security policy into the development process rather than relying on late scans. | ||
| NIST CSF 2.0 | PR.DS-10 — Information is Encrypted | The article references secret exposure and code-risk governance, which sit within protective data handling controls. |
| Recommendation — Apply PR.DS-10 where code handling or secrets exposure could place sensitive material into application artefacts. | ||
| MITRE ATT&CK | TA0006;TA0009 — Credential Access; Collection | The source discusses hardcoded credentials and application exposure paths that align with attacker credential collection. |
| Recommendation — Map exposed secrets and application weakness to TA0006 and TA0009 when prioritising detection and remediation. | ||
Key terms
- Application Security Testing Service: A managed or platform-based delivery model for finding and prioritising software vulnerabilities across code, dependencies, secrets, containers, and infrastructure. It combines scanning with workflow integration and often adds remediation support, reporting, and governance features for enterprise development teams.
- Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
- Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM and secrets management. It helps security teams apply identity controls to software actors and the systems they use.
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