DAST in the agentic era: runtime testing still closes gaps

At a glance

What this is: DAST tests running applications from the outside and confirms which flaws are exploitable at runtime, especially where code scanning stops short.

Why it matters: It matters because IAM, NHI, and application security teams need runtime evidence when authentication, session handling, and API authorisation failures emerge only after deployment.

By the numbers:

• 88% of Basic Web Application attacks involved stolen credentials in Verizon's 2025 Data Breach Investigations Report.
• 80% of organisations report their AI agents have already performed actions beyond intended scope, according to SailPoint.

👉 Read Cycode's guide to DAST in the agentic era

Context

Dynamic application security testing, or DAST, evaluates a live application by attacking it the way an outsider would. The key governance gap is simple: code-level analysis can show where risk may exist, but only runtime testing can show what is actually exploitable in the deployed system.

That distinction matters in modern application and identity-heavy environments because authentication flows, session state, API authorisation, and third-party integrations often fail only after deployment. In agentic development, where AI agents can generate and ship code at pace, runtime assurance becomes harder to treat as a periodic check and easier to treat as a continuous control.

For identity and access teams, the most important implication is that application security testing now has to speak to runtime trust boundaries, not just code quality. That is a typical condition in fast-moving software programmes, but the speed of AI-assisted delivery makes the blind spots larger.

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: Why do runtime flaws still matter when SAST is already in place?

A: SAST shows where code may be risky, but it cannot prove that a flaw is exploitable in the deployed application. Runtime testing matters because authentication, session handling, access control, and server configuration often fail only after the application is assembled and processing real requests.

Q: What do teams get wrong about API testing with DAST?

A: Teams often assume browser crawling is enough, but most modern attack surface now sits in APIs. If scanners do not understand REST, GraphQL, or service-to-service endpoints, they miss authorisation failures and broken object access paths that attackers can reach without the UI.

Q: How do organisations decide which DAST findings matter most?

A: The best triage model starts with exploitability, then adds business context. Findings that affect authentication, session integrity, object-level authorisation, or externally exposed APIs should rise first because they can turn into real compromise. Lower-priority issues can wait if they are not reachable in production or are already covered by other controls.

Technical breakdown

Why runtime testing finds flaws code analysis misses

DAST works as a black-box method, so it does not inspect source code or dependency graphs. Instead, it sends crafted requests, observes responses, and infers whether the application can be abused in practice. That makes it useful for issues that only emerge once authentication, session handling, server configuration, and business logic all interact in a live stack. SAST can flag suspicious patterns, but it cannot prove exploitability at runtime. DAST closes that gap by validating behaviour, not intent, which is why it remains valuable even in mature AppSec programmes.

Practical implication: treat DAST as the runtime confirmation layer after code and dependency checks, not as a replacement for them.

Why API-first and agentic development change the DAST problem

Modern DAST has to inspect more than browser pages. REST, GraphQL, and gRPC endpoints now carry much of the application logic, and automated agents often generate or modify that logic faster than teams can manually review it. That creates a shifting attack surface where broken object-level authorisation, authentication bypass, and misconfigured access paths may appear between builds. In this model, scan scope and authentication configuration matter as much as payload quality. If the scanner cannot reach protected flows or understand the API surface, the highest-risk paths remain invisible.

Practical implication: configure DAST around API specs, test accounts, and authenticated flows before relying on it in agentic delivery pipelines.

How DAST findings become governance signals

A mature DAST workflow does more than generate vulnerability tickets. It ties runtime findings back to other control layers, such as SAST, SCA, asset inventory, and deployment context, so teams can distinguish exploitable defects from noisy or redundant alerts. That correlation is especially important when applications are built and updated by AI-assisted tooling, because the volume of change can overwhelm manual triage. The governance value is not just detection. It is deciding which runtime exposures are real, repeatable, and urgent enough to block release or require immediate remediation.

Practical implication: use correlated DAST results to drive release gates and remediation priority, especially where AI-generated change increases alert volume.

Threat narrative

Attacker objective: The attacker wants to turn a runtime application flaw into real access, data theft, or account compromise.

1. Entry occurs through exposed web pages, API endpoints, or authenticated flows that a DAST scanner maps as part of the application attack surface.
2. Escalation happens when crafted payloads reveal broken authentication, session flaws, IDOR, or other runtime weaknesses that let requests cross intended trust boundaries.
3. Impact is unauthorised access, data exposure, account takeover, or a production-side abuse path that code review alone did not confirm.

NHI Mgmt Group analysis

Runtime confirmation is the missing governance layer in fast-moving application programmes. Code scanning tells teams where flaws may exist, but DAST tells them whether the flaw is exploitable in the deployed environment. That distinction becomes more important as AI-assisted development increases release volume and reduces the time available for manual triage. Practitioners should treat runtime evidence as the deciding factor for release confidence.

API surface expansion has turned authorisation quality into a first-class control issue. When applications expose REST, GraphQL, and service-to-service flows, broken object-level authorisation and session handling become easier to miss and harder to reconstruct after the fact. This is where application security and identity governance intersect most clearly, because the problem is not only code weakness but trust boundary failure. Teams should align runtime testing with access-control review.

Agentic development creates DAST noise unless control correlation is built in. AI agents can generate large volumes of code changes, which increases the number of findings without increasing security signal. The named concept here is runtime signal correlation: linking DAST results to SAST, SCA, and asset context so teams can separate real exposure from duplicate or theoretical alerts. Practitioners should use that correlation to reduce backlog inflation and strengthen release decisions.

DAST is most useful when it shapes governance, not just tickets. A runtime finding should inform whether a deployment gate stays closed, whether an authentication flow needs redesign, and whether a known risk pattern repeats across services. The control question is not only whether a vulnerability exists, but whether the organisation can prove exploitability before production exposure. Practitioners should make DAST a policy input, not a reporting output.

Identity boundaries inside applications now deserve the same scrutiny as external identities. Web sessions, tokens, service accounts, and API authorisation paths can all become the practical boundary that decides whether an attack succeeds. In that sense, DAST is increasingly relevant to IAM-adjacent governance because it shows where runtime trust assumptions fail. Practitioners should map those failures back to the controls that govern authentication and authorisation.

What this signals

Runtime signal correlation is becoming a practical programme requirement, not an advanced tuning option. As release velocity rises, security teams need a way to separate exploitable runtime findings from duplicate scanner noise, and DAST only scales if it is linked to code and asset context.

The governance challenge is shifting from simple vulnerability discovery to release confidence under AI-assisted delivery. Teams that cannot prove a finding is real, reproducible, and attached to a live trust boundary will struggle to convert scan results into timely risk decisions.

Application and identity teams should expect more attention on authenticated flows, API authorisation, and session integrity because those are the runtime controls that determine whether a technical defect becomes an incident.

For practitioners

• Embed DAST into release gates Run authenticated DAST scans on every merge or deployment path so exploitable runtime flaws block release before they reach production.
• Prioritise API coverage first Map REST, GraphQL, and other API endpoints before relying on browser crawling, because modern attack paths increasingly bypass the UI.
• Correlate runtime and code signals Link DAST findings with SAST, SCA, and asset inventory so duplicate or theoretical issues do not bury confirmed exploitation paths.
• Harden authentication test setup Use dedicated test accounts, session handling, and scoped credentials so protected flows are actually scanned instead of skipped.
• Treat repeat findings as governance defects If the same runtime weakness appears across services or releases, escalate it as an application control failure rather than a one-off ticket.

Key takeaways

• DAST remains valuable because it confirms exploitability in a live application, not just theoretical weakness in code.
• Agentic development raises the bar for runtime assurance because faster release cycles create more opportunities for exploitable flaws to slip through.
• The right operational model is continuous, authenticated, and correlated with other security signals so runtime findings change release decisions.

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.
• Runtime Vulnerability Management: Runtime Vulnerability Management prioritises flaws based on what software actually does in production, not only on static scan results or catalogue entries. It combines execution telemetry, reachability, and exploit signals to determine whether a finding is genuinely actionable in the current environment.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Runtime Signal Correlation: Runtime signal correlation is the practice of linking DAST findings to code-level analysis, dependency data, and asset context. It helps security teams decide whether a finding is reproducible, exploitable, and urgent enough to block release or trigger immediate remediation.

What's in the full article

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

• Payload examples and scanner behaviours for SQL injection, XSS, CSRF, SSRF, and broken authentication cases.
• Configuration detail for authenticated scanning across CI/CD, staging, and API-first environments.
• Workflow guidance for correlating DAST with SAST, SCA, and issue tracking to reduce false positives.
• Limitations and tuning considerations for complex login flows, production scanning, and microservice architectures.

👉 Cycode's full article covers runtime testing methods, integration patterns, and DAST limitations in modern delivery pipelines.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It is suited to practitioners who need to connect identity control with application and AI-era risk.