AI code review is missing the context that determines exploitability

At a glance

What this is: This analysis argues that code-only scanners cannot reliably judge exploitability because they do not see deployment, trust boundaries, or infrastructure context.

Why it matters: For IAM and security practitioners, the issue is that access paths and privilege boundaries define real risk, so code findings without system context can mis-rank what needs fixing first.

By the numbers:

• Code output per developer jumped 200 percent while security review capacity stayed flat.
• Across 38 scans covering 30 pull requests from Claude Code, OpenAI Codex, and Google Gemini, agents produced 143 security issues.
• The review set showed an 87 percent vulnerability rate, with 26 of those pull requests containing at least one security flaw.

👉 Read Gecko Security's analysis of why code-only scanners miss exploitability context

Context

AI-assisted code review is useful for finding defects in changed files, but exploitability is a different question. A scanner can identify a flaw in isolation, yet still miss whether the application is publicly exposed, internally segmented, or protected by compensating controls. In practice, that means the primary keyword here is code review, but the security problem is context loss, not code quality alone.

The identity angle is indirect but real: trust boundaries, service access, and privileged paths decide whether a code flaw becomes a breach path. When review tooling cannot see architecture, deployment topology, or access design, it cannot judge whether a finding affects a human workflow, an NHI pathway, or a machine-to-machine trust chain. That is a familiar governance problem for IAM and NHI programmes.

This makes the article’s starting position typical for modern engineering teams: code review has scaled faster than the surrounding security governance that should interpret the findings. The gap is structural, not a matter of reviewer effort.

Key questions

Q: What breaks when code scanners cannot see deployment context?

A: They can still find code defects, but they cannot tell whether those defects are reachable in the live system. That means teams lose the ability to separate exploitable risk from theoretical findings. In practice, the result is noisy prioritisation, delayed fixes, and security effort spent on issues that architecture or access controls already neutralise.

Q: Why do large codebases make AI-assisted security review harder?

A: Large repositories create context loss. Once analysis spans many packages, dependencies, and build paths, a model can identify patterns without proving whether the path is reachable or the exploit is real. That drives false positives, validation debt, and triage fatigue. Security teams need workflows that preserve execution context, not just tools that generate more candidate issues.

Q: How do security teams know if a code finding is actually dangerous?

A: They need to check exposure, trust boundaries, and compensating controls before assigning priority. A flaw behind internal authentication, segmentation, or privileged-only access may be materially different from the same flaw on a public endpoint. If the review process cannot answer that, it is not yet risk-based.

Q: How should IAM teams think about application code review?

A: IAM teams should treat code review as one input into access-risk assessment, not the final decision. The important question is whether the affected function is reachable by a human user, service account, or delegated workload, and under what trust conditions. That is where identity governance and application security meet.

Technical breakdown

Why code-only scanners miss exploitability

Code-only scanners reason over source files, diffs, and local control flow. That is enough to spot patterns such as unsafe input handling or missing checks, but not enough to understand whether the flaw is reachable in the live system. Exploitability depends on deployment topology, network exposure, upstream controls, and whether the function sits behind compensating authentication or segmentation. Without that context, the scanner can only say the issue exists in code, not whether an attacker can actually use it. Practical reviews need system context alongside source analysis, not instead of it.

Practical implication: pair code review with deployment-aware risk scoring before assigning remediation priority.

How AI code review changes the signal problem

AI coding tools increase output, which also increases the number of findings a security team must triage. The issue is not just volume. Large language model-based reviewers can produce plausible but context-free alerts, especially when they cannot inspect architecture docs or infrastructure state. That creates a signal problem: teams receive more findings, but fewer are tied to the actual exposure surface. In security governance terms, the review process shifts from defect discovery to evidence validation. That is a material change in how teams should operationalise review workflows.

Practical implication: establish a triage step that confirms exposure, reachability, and business impact before escalation.

Why business logic failures need system context

Business logic vulnerabilities arise when implementation diverges from intent. That intent usually lives in design documents, threat models, and risk registers, not in the code diff. A function that omits an authorization check can be a defect, a deliberate internal exception, or a safe shortcut behind layers of defence. Source-only analysis cannot distinguish those cases. For IAM and PAM teams, this is the same governance challenge seen in access decisions: the control outcome depends on who can reach what, through which trust path, and under what conditions. Code alone cannot answer that.

Practical implication: require architecture and identity context to validate whether a code finding creates a real access path.

Threat narrative

Attacker objective: The practical attacker objective is to exploit the mismatch between code-level findings and real-world exposure, slipping a usable path past overloaded review processes.

1. Entry occurs when AI-assisted development increases the number of code changes and review findings faster than security teams can assess them.
2. Escalation happens when code-only scanners flag flaws without knowing whether the application is exposed, trusted internally, or already protected by compensating controls.
3. Impact is a growing triage burden and a higher chance that teams fix low-value findings before genuinely exploitable issues.

NHI Mgmt Group analysis

Code-only analysis creates a context gap that security teams now have to govern explicitly. The article’s core point is not that scanners are useless, but that their verdicts stop at the source file. That leaves architecture, deployment, and trust boundaries outside the control loop. For identity programmes, this is the same failure mode seen when entitlement reviews ignore where access is actually reachable. Practitioners should treat exploitability as a governed decision, not a static code property.

AI-assisted development has turned review throughput into a governance issue. When code volume rises faster than review capacity, teams get a backlog of possible issues rather than a ranked list of real risk. The article’s 200 percent code-output increase shows why this is no longer an edge case. Security teams should measure not just how many findings they receive, but how many survive exposure validation and system-context review.

Trust-model blindness is the named concept this article exposes. A scanner that cannot see internal authentication, segmentation, or privilege boundaries cannot judge whether a flaw is exploitable. That is especially relevant in IAM and NHI environments, where reachability often matters more than the bug itself. The practitioner conclusion is simple: if the tool cannot model trust, the team must.

Identity governance and code review are converging on the same question: who or what can actually reach the vulnerable function? That question applies to human access, service accounts, and machine-to-machine workflows alike. Where code review stops at syntax, identity governance adds the missing layer of exposure, privilege, and delegation. Teams should align application security, IAM, and NHI review processes so findings are assessed against real access paths.

Context-aware security is becoming the baseline expectation, not a premium capability. The article shows why source-only reasoning will keep generating expensive false priorities as AI systems increase the pace of software change. NHI and IAM leaders should treat this as a signal to integrate identity, runtime, and architecture evidence into security review. Otherwise, review quality will keep lagging behind delivery speed.

What this signals

Trust-model blindness will become a recurring control failure as AI-assisted development scales. Security teams cannot assume code review output maps cleanly to risk unless they add architecture, deployment, and identity evidence to the decision process. This is where NIST Cybersecurity Framework 2.0 and the review workflow need to meet, because governance without exposure validation is only partial governance.

Context-aware triage is the next practical maturity step for application security and IAM. Findings should be ranked by who or what can actually reach the vulnerable function, including service accounts and delegated machine access. Where that path exists, the control question is not whether a bug exists, but whether the privilege boundary is real. See also NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and audit alignment.

Review velocity without governance velocity produces backlog, not resilience. The teams that adapt fastest will be the ones that connect code scanning to identity, runtime, and architecture evidence before findings are escalated. That is also why NHI programmes should watch for the same pattern in machine identity review, where reachability and privilege matter more than syntax.

For practitioners

• Integrate deployment context into code review Require reviewers to validate exposure, segmentation, and compensating controls before accepting a scanner finding as actionable. Pull in architecture notes, infrastructure config, and runtime data for any issue that could change based on where the service runs.
• Rank findings by exploitability, not just detection Create a triage workflow that separates theoretical defects from reachable attack paths. Use a risk score that reflects authentication layers, trust boundaries, and whether the affected service is public, internal, or privileged.
• Align IAM and application security review Make identity teams part of reviews for endpoints, service calls, and privileged workflows that could turn a code defect into an access control failure. This is especially important where service accounts or internal trust paths are involved.
• Measure review quality beyond false positives Track how many flagged issues are confirmed by system context and how many are dismissed after exposure validation. A low scanner false positive rate does not guarantee good prioritisation if the tool cannot see the real trust model.
• Use context-aware findings for NHI pathways Where code affects machine-to-machine access, check whether the vulnerable function is reachable by service accounts, tokens, or delegated workflows. That is where code-only analysis most often misses the real blast radius.

Key takeaways

• Code-only scanners can identify bugs, but they cannot decide whether a flaw is exploitable in your environment.
• AI-assisted development increases review volume faster than security teams can absorb it, turning prioritisation into the real bottleneck.
• Identity, architecture, and runtime context must be part of security review if teams want to rank findings by real access risk.

Key terms

• 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.
• Trust Model: The set of assumptions customers and stakeholders make about whether an organisation will protect their data and recover well after failure. In identity security, the trust model is shaped by access discipline, response quality, and whether control gaps remain visible after compromise.
• Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.
• Context-aware access analysis: Context-aware access analysis evaluates who the identity is, what similar identities can do, and which data the identity can reach. It is more precise than coarse role checks because it connects entitlement patterns to business meaning and data sensitivity.

What's in the full article

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

• The comparison between Claude Code Review and Claude Code Security across PR review and standalone scanning workflows.
• The full breakdown of the five-agent review architecture and how the 80-point confidence threshold affects output.
• The specific examples Gecko uses to show where code-only scanners miss exploitability in deployment context.
• The article's practical notes on installing the review plugins and using them in a live development workflow.

👉 Gecko Security's full article covers the multi-agent review model, the code-only boundary, and the plugin workflow examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. It helps security practitioners connect access control, privilege, and governance across modern identity programmes.