DAST in an AI-first SDLC: what changes for AppSec teams

At a glance

What this is: This is Checkmarx’s analysis of how DAST changes in an AI-first SDLC, with the key finding that dynamic testing moves from a late-cycle scanner to a continuous security agent.

Why it matters: It matters because AppSec teams will need to govern AI-generated code, AI-powered attack vectors, and automated remediation inside delivery workflows rather than only at release gates.

Context

DAST is dynamic application security testing, which exercises a running application to find vulnerabilities that static review can miss. In an AI-first SDLC, the control problem shifts from whether applications can be scanned to whether testing keeps pace with faster code generation, shorter review cycles, and new attack paths introduced by AI-assisted development.

The governance gap is that many AppSec programmes still treat testing as a late-stage checkpoint. Once agentic workflows and automated code generation become normal, security review has to operate continuously across feature branches, staging, and production, with explicit attention to data leakage, prompt injection, and runtime behaviour.

Key questions

Q: How should AppSec teams adapt DAST for AI-generated applications?

A: AppSec teams should extend DAST beyond classic vulnerability checks to cover prompt injection, data leakage, and unsafe runtime behaviour in AI-powered applications. The control should run continuously where possible, because AI-assisted development shortens release cycles and increases the chance that issues appear only once the application is live.

Q: What breaks when DAST stays a late-stage release gate?

A: A late-stage-only model misses the reality of feature branches, automated code generation, and rapidly changing runtime behaviour. It also leaves AI-specific abuse paths under-tested until after deployment, which turns DAST into a reporting step instead of a live assurance control.

Q: Where does AI application testing fail in practice?

A: It fails when teams treat a single launch review as sufficient for a system that changes with prompts, retrieval context, tools, and model updates. Non-deterministic AI needs repeatable evaluation across the lifecycle, or guardrails only measure yesterday's behaviour. The practical failure mode is regression blindness, where unsafe or low-quality output appears after deployment and no control is watching for it.

Q: How should organisations govern autonomous security testing?

A: They should treat the testing agent like any other privileged non-human identity. That means least privilege, narrow scope, full logging, and human approval for sensitive actions. The goal is to make the automation auditable and bounded so it can test production safely without becoming an uncontrolled actor.

Technical breakdown

Why DAST becomes more important in AI-generated applications

Dynamic application security testing works by probing a live application, so it can validate behaviour after frameworks, prompts, configuration, and runtime dependencies are assembled. That matters more when code is increasingly generated by models, because defects can appear in logic, integration, and data handling rather than only in syntax or obvious pattern mistakes. The key shift is that DAST becomes a control for runtime assurance, not just a release gate. It can also surface issues that are only visible when the application is executing, including exposure paths that static analysis will not reliably reconstruct.

Practical implication: Treat DAST as a runtime control that must be present in every meaningful delivery stage, not as a one-time pre-release scan.

How agentic testing changes the AppSec operating model

Agentic testing means the security system can continuously observe a running application, trigger tests, and potentially coordinate fixes with adjacent tooling. That is a different operating model from a human tester performing a periodic assessment. The important governance issue is not whether automation exists, but whether the test agent has bounded scope, reliable context, and clear escalation when findings require human review. In AI-first delivery, the testing loop can become as continuous as deployment itself, which makes control boundaries, evidence retention, and exception handling part of the design rather than afterthoughts.

Practical implication: Define when automated testing may act, when it must stop, and how findings are escalated into the SDLC.

Prompt injection and data oversharing as application test targets

The article ties AI-first AppSec to attack patterns that are not traditional web defects. Prompt injection targets the instruction layer of AI-powered applications, while data manipulation and data oversharing target the integrity and confidentiality of what the application returns. That broadens DAST’s job because security teams now need assurance that runtime behaviour does not leak sensitive or confidential information through ordinary user interactions. In practice, DAST has to test both classic vulnerability classes and AI-specific abuse paths that emerge only when the model is part of the application flow.

Practical implication: Add AI-specific abuse cases to runtime test coverage, especially where prompts, retrieval, and user-facing responses intersect.

Threat narrative

Attacker objective: The attacker aims to manipulate runtime behaviour so the application leaks data, returns unsafe outputs, or behaves outside intended security boundaries.

1. Entry occurs when an AI-powered application accepts user input, retrieved content, or embedded prompts that can be shaped by an attacker.
2. Escalation happens when that input changes runtime behaviour, allowing prompt injection, data manipulation, or disclosure logic to affect the application’s response path.
3. Impact is sensitive or confidential information being exposed to users, or malicious outputs being returned through a trusted application workflow.

Breaches seen in the wild

• Checkmarx KICS supply chain attack 2026: Credentials stolen via Trivy let attackers poison Checkmarx KICS Docker images, VS Code extensions and Actions to steal developer secrets.
• Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions 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

DAST is being pushed from verification to continuous runtime governance. In AI-first delivery, the control is no longer just about finding known bugs before release. It has to observe how the application behaves once models, prompts, and user interactions are live, which makes runtime evidence the real object of governance. For AppSec teams, the practical conclusion is that testing scope now has to follow execution, not just code.

AI-assisted development changes the security debt profile of application teams. Faster code generation can reduce review bottlenecks, but it also shifts risk into the behaviour of assembled systems that are less predictable at the point of deployment. That creates a named gap we can call runtime assurance drift, where the testing model lags behind the actual application lifecycle. The implication is that security control design must track how software is built, not how it was once reviewed.

Prompt injection turns AI features into an application security problem, not a niche AI problem. Once AI capabilities are embedded in user-facing workflows, the attack surface expands to instruction manipulation, response shaping, and unintended disclosure. That means DAST, AppSec governance, and AI security cannot be separated cleanly in practice. The practitioner takeaway is to treat AI abuse cases as part of the core application risk register, not as an adjacent specialist concern.

Continuous testing only works if automation has clear authority limits. An agent that can identify a running application and test it autonomously is useful only when the organisation defines scope, evidence handling, and handoff conditions. Otherwise, the programme can create false confidence by producing more activity without improving governance. The field-level lesson is that automation must be paired with explicit control ownership and exception management.

The SDLC is moving toward machine-speed testing, but accountability remains human. Automated testing can narrow exposure windows and increase coverage, yet the decision to accept, defer, or remediate risk still belongs to the organisation. That makes AppSec governance more operationally demanding, not less. Practitioners should treat DAST as part of a broader control system where human oversight validates the exceptions the agent cannot resolve.

What this signals

Runtime assurance drift: when code generation speeds up and review cycles shrink, the testing model can lag the application lifecycle unless DAST is made continuous. For AppSec leaders, the practical issue is not whether more testing exists, but whether testing keeps pace with how software is now built and deployed.

AI-specific abuse cases belong in the same control plane as traditional application testing. If prompt injection and sensitive-data disclosure are not added to runtime test coverage, the organisation can overestimate assurance simply because its scan coverage looks familiar.

The important boundary is governance, not just automation. Agentic testing can widen coverage, but only if scope, escalation, and evidence handling are explicitly defined so the programme can trust the findings it acts on.

For practitioners

• Expand DAST coverage into AI-specific abuse cases Add prompt injection, data manipulation, and sensitive-data exposure scenarios to runtime test suites for AI-powered applications.
• Move testing earlier and keep it continuous Run dynamic tests across feature branches, staging, and production so runtime assurance follows the SDLC rather than ending at release.
• Define automation boundaries for testing agents Specify which tests the agent may run, when it must escalate findings, and what evidence must be retained for review.
• Correlate DAST findings with remediation workflows Connect runtime findings to code-generation or developer workflows so confirmed issues can be corrected without losing traceability.

Key takeaways

• DAST is evolving from a release-time scanner into a runtime assurance control as AI-assisted development changes how applications are built and tested.
• AI-powered applications add prompt injection, data manipulation, and sensitive-data exposure risks that require explicit test coverage.
• Continuous testing only improves security when automation boundaries, escalation paths, and remediation ownership are clearly defined.

Key terms

• 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.
• Agentic Testing: Security testing in which software agents can choose actions, sequence steps, and adapt during a validation workflow. In practice, it combines automation with governance, because the agent is not just running a script. It is operating with enough decision-making to require scope limits, auditability, and oversight.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Runtime assurance: Runtime assurance is the practice of validating how an application actually behaves after deployment. It matters because configuration, identity flow, and integration state can change security outcomes in ways that source code analysis alone cannot prove.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course when your programme needs a structured way to govern machine identities, agentic AI identity, and secrets management.