Deepsec improves agentic code review, but runtime validation still matters

At a glance

What this is: This is an independent analysis of Deepsec that finds agentic static code review is useful for breadth, but cannot replace runtime testing for exploitability.

Why it matters: It matters to security and identity teams because authentication, access control, and business-logic failures often only appear in the running system, not in source code alone.

👉 Read MindFort's analysis of Deepsec's agentic code review and runtime limits

Context

Deepsec sits in a familiar application security gap: static analysis can surface likely weaknesses in code, but it cannot confirm how an application behaves once identity, session handling, APIs, and infrastructure are live. That matters because exploitability is often governed by runtime conditions such as authentication state, access scope, and downstream service interactions, not just code patterns. For identity programs, the gap is especially relevant where application controls depend on access decisions that only become visible during execution.

The article also highlights a broader control design issue. Teams increasingly rely on AI-assisted review to accelerate detection, but that does not remove the need for a second control layer that tests the deployed system. In practice, source review and runtime validation are complementary, not interchangeable. For practitioners, this is a mature application security posture rather than an edge case.

Key questions

Q: How should security teams use agentic static analysis without over-trusting it?

A: Use it to widen coverage and surface plausible weaknesses faster, but do not treat the output as proof of risk. The practical model is candidate generation followed by independent runtime validation, especially for authentication, authorization, and business logic paths. Findings should be prioritized only after the deployed system confirms the issue is reachable and exploitable.

Q: Why do identity and access flaws often require runtime testing?

A: Because the control that matters is enforced in the live application, not in the source tree. Authentication state, sessions, tokens, upstream services, and authorization decisions all affect whether a weakness can be exploited. Static review can suggest a problem exists, but runtime testing shows whether the access boundary actually fails in production.

Q: What do security teams get wrong about review loops in AI-assisted development?

A: Teams often assume a review loop automatically means control is preserved. In practice, the agent may still make substantial changes before the developer sees them, especially when planning is hidden or optional. The control issue is not whether review exists, but whether review happens early enough to constrain the change path.

Q: Should organisations pair static analysis with runtime validation for AppSec?

A: Yes. Static analysis is best for breadth across large codebases, while runtime validation is best for confirming whether a flaw survives configuration, identity controls, and business logic in production. Together they reduce both missed vulnerabilities and false urgency, which is what mature application security programmes need.

Technical breakdown

Why agentic static analysis still stops at the code boundary

Agentic static analysis uses coding agents and large language models to inspect source, trace data flows, and rank candidate weaknesses. That can outperform rule-only scanning on broad repo coverage because the model can reason across files and infer intent. The limit is structural: source code does not expose live authentication state, deployed configuration, external integrations, or business logic that only resolves at runtime. A scanner can identify a plausible weakness, but it cannot prove whether the path is exploitable in the target environment.

Practical implication: treat agentic SAST as a discovery layer, not a final verdict on exploitability.

Why runtime testing is required for authentication and access control flaws

Runtime testing sends actual requests into a live application and observes the real responses. That is the only way to confirm whether broken access control, IDOR, weak session handling, rate limiting gaps, or multi-service business logic flaws are reachable in practice. For identity-sensitive applications, the real question is not whether the code looks suspicious, but whether the deployed control actually enforces the intended authorization boundary under real session and role conditions.

Practical implication: validate identity and access paths against the running system before you ticket or prioritise remediation.

Why AI-generated findings need an independent verification layer

When the same class of models helps write code and review it, the review process can inherit blind spots from the authoring process. That does not make AI review useless, but it does mean one model’s confidence cannot substitute for independent validation. Mature AppSec workflows separate candidate generation from exploitation proof, then use both signals to decide severity. This is especially important in environments where application behaviour depends on chained services, tokens, or delegated identity contexts.

Practical implication: pair AI-assisted findings with a separate verification control that proves exploitability or closes the issue as non-actionable.

Threat narrative

Attacker objective: The attacker’s objective is to turn a code-level weakness into a live, exploitable path that bypasses intended application controls.

1. Entry begins with a codebase scan that identifies suspicious patterns, but the real attack surface only appears when the application is running and reachable through its live interfaces.
2. Escalation occurs when a theoretical weakness in authentication, access control, or business logic is confirmed through runtime behaviour and becomes an exploitable path.
3. Impact is achieved when the attacker uses the validated weakness to access data, bypass authorization, or manipulate application workflows in the deployed environment.

NHI Mgmt Group analysis

Agentic static analysis is useful, but it is not an exploitability control. The article is correct to separate breadth from proof. Static tools can identify suspicious code patterns faster than manual review, but they cannot establish whether an issue survives deployment, identity enforcement, or service chaining. Practitioners should treat this as a two-stage control model: candidate generation first, runtime verification second.

The real governance gap is the runtime trust boundary. Many security programmes still assume that a well-reviewed code path is a secure code path. That assumption breaks when authorization, session state, and downstream services determine whether a flaw is actually reachable. For IAM and application security teams, the relevant control question is whether the deployed system enforces the intended access decision, not whether the source looked reasonable.

Identity-aware applications need identity-aware testing. Authentication flows, delegated access, and token handling are not fully testable in static review alone because they depend on runtime state. That makes runtime validation especially important where applications mediate access to sensitive data or privileged workflows. The practitioner conclusion is simple: if identity is part of the attack path, code review alone is incomplete.

Validation-based security is becoming the differentiator in AppSec programmes. As AI-assisted review lowers the cost of finding candidates, the burden shifts to proving which findings matter. That changes how teams should think about triage, severity, and remediation priority. Programmes that cannot validate exploitability will continue to over-ticket noise while missing the issues that matter most.

Runtime verification should be integrated with governance, not bolted on later. The strongest operating model is one where code scanning, deployment context, and exploitation proof are linked in a single workflow. That gives security leaders a defensible path from finding to decision. The practitioner conclusion is to govern application risk through evidence, not inference.

What this signals

Application security programmes are moving toward evidence-based triage, where scan output must be confirmed by runtime behaviour before it drives remediation priority. That shift matters because identity, session, and authorization failures are rarely resolved by source review alone. Practitioners should expect more pressure to prove exploitability, not just detect possibility.

Runtime trust boundary: the control question is no longer whether code looks secure, but whether the deployed service enforces access under real conditions. Teams that cannot test this boundary will keep overvaluing static findings and underestimating live exposure.

The most durable programme change is to connect AppSec findings to verification artefacts, deployment context, and remediation evidence. That creates a defensible path for risk acceptance, especially where identity-sensitive workflows can only be understood in production.

For practitioners

• Implement runtime confirmation for high-risk findings Require every severe finding that affects authentication, authorization, session handling, or business logic to be validated against the live application before remediation priority is set.
• Separate candidate detection from exploit proof Use agentic static analysis to generate candidates, then route them into a distinct runtime validation step so severity reflects observed behaviour rather than code suspicion alone.
• Prioritise identity-sensitive attack paths first Focus validation effort on access controls, token handling, delegated permissions, and cross-service workflows because those are the paths most likely to hide in source but fail in production.
• Tie AppSec output to remediation evidence Store proof of exploitability, false-positive closure, or non-reachability alongside the ticket so engineering teams can see why a finding was escalated or downgraded.

Key takeaways

• Agentic static analysis improves code coverage, but it does not prove whether a weakness is exploitable in production.
• Authentication, authorization, and business-logic failures need runtime validation because the deployed system determines whether the control actually holds.
• Mature AppSec programmes will separate candidate detection from exploit proof so severity reflects evidence, not inference.

Key terms

• Agentic Static Analysis: A security review method that uses AI agents to inspect source code, trace flows, and rank likely weaknesses. It expands coverage beyond pattern matching, but it still depends on source-level evidence and cannot by itself prove exploitability in the deployed system.
• Runtime validation: A control practice that tests how an AI system behaves while it is connected to real tools and data, rather than only reviewing configuration or design documents. It matters because agentic systems can appear safe on paper and still fail when prompted, chained, or given access to connected services.
• Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.

What's in the full article

MindFort's full analysis covers the operational detail this post intentionally leaves for the source:

• How the harness dispatches coding agents across candidate files and revalidates findings before ticket export
• The practical differences between agentic SAST output and runtime exploit validation in deployed applications
• Why its local and CI execution model matters for teams that do not want source code exposed to a third-party SaaS
• The comparison points practitioners should use when deciding where static review ends and runtime testing begins

👉 MindFort's full post covers the code review workflow, false positive discussion, and runtime validation gap in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security practitioners connect identity governance to the operational controls their programmes depend on.