Deepsec improves agentic code review, but runtime validation still matters

At a glance

What this is: This is an analysis of Deepsec as agentic static code review, with the key finding that deeper static findings still do not verify whether a vulnerability is exploitable in a running system.

Why it matters: It matters because IAM, application security, and platform teams still need runtime validation to confirm whether authentication, authorisation, and infrastructure findings represent real exposure.

Context

Agentic static analysis can widen review coverage, but it still operates on source code rather than on a live system. That means it can rank suspicious paths and enrich findings, yet it cannot directly observe how authentication, business logic, API calls, or infrastructure behave once the application is deployed.

For identity-heavy systems, the distinction matters because many failure modes only appear at runtime, especially where session handling, access decisions, or cross-service authorisation determine whether a code issue is exploitable. The governance gap is not code visibility alone, but proof that a finding survives contact with the running environment.

Key questions

Q: Where does agentic SAST fail in practice?

A: Agentic SAST fails when teams treat code-level confidence as proof of exploitability. It can trace suspicious paths and improve prioritisation, but it cannot execute the application, observe live responses, or confirm whether authentication, authorisation, or business logic actually permits abuse in the deployed environment.

Q: Why do static findings need runtime validation before remediation?

A: Static findings need runtime validation because exploitable risk depends on the deployed configuration, live APIs, and stateful controls. A finding that looks dangerous in source may be blocked in production, while another path can look harmless in code but become exploitable through real requests and chained behaviour.

Q: What are the signs that code review is missing real exploitability?

A: The main sign is a backlog of plausible findings that never map cleanly to real requests, real responses, or confirmed attack paths. If authentication, access control, and business logic issues are repeatedly uncertain after review, the programme is over-trusting source analysis and under-testing runtime behaviour.

Q: Should teams use agentic SAST instead of penetration testing?

A: No. Agentic SAST is useful for broad code review, but penetration testing or runtime validation is still needed to confirm whether a weakness can actually be exploited. The two controls answer different questions, and neither should be treated as a substitute for the other.

Technical breakdown

Why agentic SAST is stronger than rule-based scanning

Agentic SAST uses coding agents and large language models to inspect code with more context than a pattern library can provide. Instead of matching only known signatures, the tool can trace security-sensitive paths, follow data flow across files, and re-rank findings after a second pass. That improves coverage for complex codebases where conventional SAST misses logic buried in abstractions, service boundaries, or framework glue. The gain is breadth and prioritisation, not certainty about exploitability.

Practical implication: Use agentic SAST to widen code review coverage, but treat its output as candidate findings that still need independent validation.

Why runtime validation remains the control that proves exploitability

Runtime validation sends real requests against the live application and observes actual responses, so it can test whether a code path is truly reachable and damaging in the deployed environment. That matters for authentication, business logic, rate limiting, and infrastructure interactions that cannot be inferred safely from source alone. A static finding may be plausible, but exploitability depends on the real configuration, the real APIs, and the real control state at runtime.

Practical implication: Pair static findings with live testing before escalating severity or assigning remediation priority.

Where static analysis breaks on identity and access flows

Identity-related weaknesses often emerge only when a system is operating end to end. A code review may flag a risky path, but it cannot confirm whether the application actually enforces session controls, checks object ownership, or applies the right authorisation decision across microservices. That is why access control failures, IDOR-style issues, and distributed business logic flaws frequently evade static certainty. The limitation is architectural, not just model quality.

Practical implication: Validate identity and access paths in the running application, especially where permissions cross services or depend on live state.

NHI Mgmt Group analysis

Agentic SAST improves discovery, but it does not change the evidence standard for exploitability. The value of coding agents is that they can inspect more code paths than traditional rule-based tools and surface better candidates. That still leaves the core security question unanswered: can the issue actually be reached and abused in the deployed environment? For practitioners, the finding should influence triage, not final trust.

Runtime proof is the governance control that separates plausible defects from operational risk. Source-code analysis cannot observe authentication decisions, session state, or live infrastructure behaviour, which means its conclusions remain provisional. The security programme needs a control that tests reality, not just intent. For teams running application security or IAM-adjacent reviews, runtime validation is the decision point that matters.

Identity and authorisation failures are especially poor candidates for static certainty. A codebase can look sound while the deployed system still misapplies access control, object ownership, or service-to-service permissions. That is why application security and IAM cannot be treated as separate lanes when runtime behaviour determines who can do what. The named concept here is static confidence gap: the distance between a convincing scan result and a proven exploit path. Practitioners should close it with live validation.

Hybrid review models are becoming the practical baseline for modern software assurance. The article points to a split that security teams increasingly have to manage: breadth from agentic code review and proof from runtime testing. That does not make static analysis obsolete, but it does redefine where it sits in the control stack. For the field, the implication is clear: source review without runtime confirmation is incomplete.

What this signals

Static code review is only one half of software assurance. The operational question is whether a finding survives contact with the running application, especially when identity, session, and service-to-service decisions determine whether the defect is real.

Static confidence gap: security teams should treat the distance between a plausible scan result and a proven exploit path as a distinct governance problem. When code review cannot test the live system, prioritisation has to shift to runtime evidence before remediation decisions are final.

For practitioners

• Pair code review with live exploit validation Use agentic static findings as inputs to runtime testing so that only issues proven in the deployed application are escalated for remediation.
• Prioritise identity and access paths for runtime checks Focus validation on authentication, session handling, object ownership, and cross-service authorisation because these controls often fail only in the running system.
• Reclassify static findings as provisional until tested Treat agentic SAST results as hypotheses, then assign severity only after the application responds under realistic requests and state conditions.
• Use hybrid testing for business logic coverage Combine source-aware scanning with runtime probing so that logic flaws spanning multiple services are not missed by code-only review.

Key takeaways

• Agentic code review can improve coverage and ranking, but it still stops short of proving exploitability in the live environment.
• Identity, authorisation, and business logic failures are especially difficult to validate from source alone because the decisive behaviour appears at runtime.
• Teams get the best assurance when static findings are used to guide live validation, not to replace it.

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.
• Static Confidence Gap: Static confidence gap is the distance between what source code review suggests and what the running application actually permits. The gap matters most for authentication, authorisation, and business logic, where the decisive behaviour emerges only in live conditions.

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. It is suited to teams that need a common control vocabulary across identity, privilege, and autonomous systems.