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

At a glance

What this is: This is an AppSec analysis of how DAST changes in AI-first development, with the key finding that dynamic testing becomes more, not less, important as code generation and agentic workflows accelerate.

Why it matters: It matters to IAM and security practitioners because AI-assisted SDLCs expand the number of identities, tools, and runtime decisions that can expose secrets, data, and privileged pathways.

👉 Read Checkmarx's analysis of DAST in an AI-first AppSec programme

Context

Dynamic application security testing matters when code is changing quickly, because it checks the running application rather than relying only on static review. In AI-first delivery, that distinction becomes sharper: generated code may be cleaner at the surface, but runtime behaviour, data handling, and prompt-driven logic can still expose security gaps. The primary issue is not whether DAST exists, but whether teams still use it as a late-stage compliance activity instead of a continuous control for modern delivery pipelines.

The identity angle is real even in an AppSec discussion. AI-enabled development increases the number of non-human workflows touching code, secrets, test environments, and production-like systems, which expands the governance problem around who or what can act, inspect, and remediate. That makes DAST adjacent to machine identity and agentic AI governance, not just vulnerability scanning. The article's starting point reflects a common enterprise shift rather than an outlier.

Checkmarx's full article covers the operational detail this post intentionally leaves for the source:

Key questions

Q: How should security teams implement DAST in CI/CD pipelines?

A: Start by making DAST part of the release workflow, not a separate review process. Connect scans to branches or build stages, require authenticated test coverage, and export results in machine-readable formats so downstream systems can act on them. The key is to block only confirmed, reachable issues while keeping lower-confidence findings visible for follow-up.

Q: What breaks when AI skills are judged only by static code review?

A: Static review misses behaviours that only appear at runtime, including hidden exfiltration, environment variable access, and unauthorized network calls. A skill can look benign in source and still behave maliciously once executed, so code-only review creates a false sense of security and leaves the real attack path untested.

Q: What do security teams get wrong about prompt injection defence?

A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

Q: How do organisations decide whether DAST should be automated with remediation?

A: Automated remediation makes sense when the issues are low-risk, well-scoped, and governed by clear approval boundaries. The key decision is whether the testing agent has enough context to fix safely without changing business logic or access control. If not, DAST should still generate findings, but humans must own the change.

Technical breakdown

Why runtime testing matters more when code is generated faster

Dynamic application security testing evaluates the application while it is running, so it can observe inputs, outputs, authentication flows, and error handling in context. That makes it different from static analysis, which inspects source code before deployment. In AI-assisted delivery, generated code may increase throughput, but it also increases the chance that runtime issues emerge in integrations, data handling, or business logic. DAST remains useful because it tests the actual attack surface, not just the code artifact. It is especially relevant when development velocity makes manual review harder to sustain.

Practical implication: keep DAST in the delivery pipeline as a runtime control, not a final compliance gate.

Prompt injection and data exposure are now AppSec test cases

AI-powered applications create attack patterns that look different from classic web flaws but still manifest at runtime. Prompt injection can manipulate model or agent behaviour through crafted input, while data exposure failures occur when an application reveals sensitive context, prompts, or retrieved content to the wrong user or system. DAST can help exercise these paths by probing how the application responds to malicious or unexpected inputs. The important point is that the control must assess both traditional vulnerabilities and AI-specific behaviour, because the same application can contain both classes of weakness at once.

Practical implication: add AI-specific abuse cases to DAST coverage, including prompt injection and sensitive-data leakage tests.

From scanner to security agent: what changes in automation

The article describes a shift from passive scanning toward an active security agent that can continuously test applications and even trigger remediation workflows. Architecturally, that implies tighter integration with development tooling, environment discovery, and code-generation systems. The security control is no longer a standalone report generator. It becomes a participant in the SDLC, which raises governance questions about approval, change control, and how findings are routed to humans or automated fixers. That is a meaningful operational shift because it changes the boundary between detection and response.

Practical implication: define who can authorise autonomous remediation and how DAST findings flow into change management.

Threat narrative

Attacker objective: The attacker aims to influence application behaviour or extract sensitive information through runtime weaknesses that static review is unlikely to catch alone.

1. Entry occurs through AI-generated or AI-assisted application paths that accept untrusted input and expose runtime behaviour to manipulation.
2. Escalation follows when prompt injection, data poisoning, or sensitive-data handling flaws alter what the application reveals or executes.
3. Impact is the leakage of confidential information or the corruption of application behaviour in production-facing workflows.

NHI Mgmt Group analysis

DAST is becoming a runtime governance control, not just a security test. As AI-assisted delivery accelerates, the value of DAST shifts from finding defects at the end of a release cycle to observing security behaviour while code is alive. That matters because runtime is where access, data handling, and user-facing exposure are actually expressed. For AppSec leaders, the practical conclusion is that DAST should be governed as part of the delivery control plane, not treated as a discrete scanner run.

AI-generated code increases verification debt. Faster code production does not eliminate the need for validation, it increases the burden on runtime checks because developers can no longer assume every code path has been manually understood. The named concept here is verification debt: the accumulated gap between what code claims to do and what has actually been tested. Teams that do not account for that debt will discover it in production, where the cost of correction is highest. The governance implication is to expand DAST coverage as AI-generated components spread.

Agentic workflows blur the line between testing and response. Once a security system can identify issues and coordinate fixes, AppSec is no longer just detecting risk, it is influencing change. That raises policy questions about identity, authorisation, and auditability for the testing agent itself. In identity terms, the testing platform starts to behave like a non-human actor with operational reach. The conclusion for practitioners is that agent permissions, remediation scope, and logging become part of AppSec governance, not separate concerns.

Runtime security for AI apps will converge with broader identity governance. AI-driven development increases the number of service accounts, integrations, and delegated tools involved in release pipelines. That means the question is not only whether an app is vulnerable, but which non-human identities are allowed to test, fix, and deploy it. AppSec, IAM, and PAM teams will need a shared operating model. The practical conclusion is that AI-era DAST must be designed with identity controls in mind from the start.

Continuous scrutiny will matter more than periodic assurance. The article's direction of travel is toward always-on testing across feature branches, staging, and production. That matches where enterprise delivery is already heading: more automation, more runtime dependency, and less tolerance for release-cycle blind spots. The governance takeaway is clear. Security programmes that still rely on point-in-time testing will struggle to keep pace with AI-first delivery models.

What this signals

AI-first delivery will force AppSec teams to reclassify runtime testing as an operational control, not an end-of-cycle assurance activity. The organisations that adapt fastest will be those that can govern non-human workflows as part of the SDLC, including how security agents, code generators, and deployment tools interact with production-like systems.

Verification debt: the gap created when development velocity outpaces the ability to test runtime behaviour thoroughly. As AI-assisted coding expands, that debt accumulates faster than manual review can absorb, so teams should use DAST to reduce blind spots before release pressure turns them into incident response work.

For identity and access teams, the practical signal is that AI-enabled development introduces more non-human actors into build and test pipelines. That means service-account governance, secrets handling, and delegated remediation permissions need to be reviewed alongside AppSec tooling, not after the fact.

For practitioners

• Embed DAST earlier in the delivery pipeline Run DAST against feature branches and staging environments, then keep it active in production-facing validation where risk justifies it. Treat the control as continuous assurance for runtime behaviour, not a one-off release checkpoint.
• Add AI-specific abuse cases to test coverage Extend test suites to include prompt injection, data poisoning patterns, and unintended disclosure of sensitive or confidential information. Make sure the test plan covers both classic web flaws and AI behaviour failures.

Key takeaways

• DAST remains relevant in AI-first AppSec because runtime behaviour, not source code alone, is where many modern security failures surface.
• AI-generated code increases verification debt, which makes continuous testing more important than late-stage scanning.
• Once DAST can trigger or coordinate fixes, teams must govern its identity, permissions, and audit trail like any other non-human actor.

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.
• 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.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.

What's in the full article

Checkmarx's full article covers the operational detail this post intentionally leaves for the source:

• How the DAST workflow is expected to operate across feature branches, staging, and production.
• The article's treatment of prompt injection, data poisoning, and data leakage as AI-era testing cases.
• The way Checkmarx frames DAST as a security agent that can identify issues and support fixes.
• The broader AppSec programme implications that are only sketched here.

👉 Checkmarx's full post covers the AI testing use cases, automation model, and SDLC implications.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to modern development and automation programmes.