AI code review is missing the context that determines exploitability

At a glance

What this is: Gecko Security argues that code-only AI review can identify defects but cannot judge whether they are exploitable without deployment, trust, and runtime context.

Why it matters: IAM, NHI, and security teams need exploitability-aware review because code findings without context can inflate triage work while still missing where access, privilege, and exposure really matter.

By the numbers:

• AI coding tools increased code output per developer by 200%, widening the review gap.

Context

Code review is only useful for risk decisions when it can see the environment the code will run in. Source files show implementation, but they do not show whether a service is internal or public, which callers are trusted, or what compensating controls already sit in front of a flaw.

This matters to IAM, NHI, and agentic AI governance because exploitability often depends on authentication boundaries, service trust, and runtime privilege, not just vulnerable code. A scanner that cannot see those controls will overstate some findings and understate others, especially in systems where machine identities, tokens, and internal service paths shape the real blast radius.

The article treats that gap as structural rather than accidental. That is a typical failure mode in modern delivery pipelines, where review volume scales faster than human context gathering.

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 code-only scanners struggle with business logic vulnerabilities?

A: Business logic vulnerabilities depend on intended behaviour, trust assumptions, and compensating controls that are usually documented outside source code. If the scanner cannot see those inputs, it cannot tell whether a missing check is a defect or a deliberate exception, so the finding remains only partially interpretable.

Q: How should teams triage AI-generated code findings at scale?

A: Teams should prioritise findings by exposure, trust boundary, and whether a path is externally reachable, then use code-level review as one input rather than the final verdict. That keeps remediation focused on exploitable risk instead of flooding engineers with every suspicious pattern in the diff.

Q: How can organisations reduce false confidence in automated security checks?

A: They should measure whether controls catch known-bad examples, not just whether scans complete successfully. Add fixture-based tests, review exceptional cases, and periodically revalidate rules after language or engine changes. That approach turns automation into a tested control instead of a presumed one.

Technical breakdown

Why code-only review cannot judge exploitability

Code scanners can identify suspicious constructs, but exploitability depends on where the code sits in the system. A buffer overflow, an auth bypass, or an unsafe function call means very different things on a public endpoint than behind multiple internal gates. The missing inputs are deployment topology, trust boundaries, and runtime exposure. Those controls live in architecture documents, infrastructure configuration, and operational policy, not in the diff. Without them, the tool can only classify theoretical weakness, not real attack surface. That is why code-only review is useful for defect discovery but incomplete for security decision-making.

Practical implication: Treat code findings as hypotheses until they are checked against deployment and trust context.

How multi-agent PR review improves signal, but only inside the code boundary

The article describes Claude Code Review as using multiple independent agents to inspect a pull request from different angles, such as compliance, bugs, git history, and prior comments. Independent analysis reduces confirmation bias and can suppress low-confidence noise. That is a meaningful improvement over single-pass scanning because different checks surface different classes of issue. But the architecture still operates on source files only. It can rank observations within the code boundary, yet it cannot infer whether a missing check is intentional, whether a service is publicly reachable, or whether an internal caller already has compensating privileges.

Practical implication: Use multi-agent review to improve code-level triage, but keep runtime validation outside the review workflow.

Why AI-generated code changes the review economics

AI coding assistants increase the amount of code that reaches review without changing the amount of human context available to judge it. That creates a structural backlog: more pull requests, more findings, and the same number of reviewers. The result is not just volume, but lower signal quality, because code-only tools respond by producing more issue candidates than teams can validate. In security terms, this is a governance problem as much as an automation problem. Review capacity is no longer the bottleneck only because teams write faster. It is the mismatch between code production and context-rich validation that determines what ships safely.

Practical implication: Redesign review intake so security teams triage by exposure and trust boundary, not by PR count alone.

Threat narrative

Attacker objective: Exploit the gap between code-level findings and deployment reality so real weaknesses survive review or get deprioritised.

1. Entry occurs through AI-generated or developer-authored code changes that introduce defects into pull requests faster than reviewers can inspect them.
2. Credential or trust impact emerges when the scanner lacks deployment context and cannot distinguish a vulnerable path from an internally protected one.
3. Escalation happens in triage, where teams chase theoretical findings while the most exposed issues remain buried in volume.
4. Impact is delayed or misdirected remediation, because review output grows while real exploitability stays unclear.

Breaches seen in the wild

• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Code-only review is a triage amplifier, not an exploitability engine. The article makes the right distinction between defect detection and real-world risk. A finding only becomes security-relevant when a team can place it inside the trust model, deployment topology, and compensating controls around it. For practitioners, that means code review outputs should feed a broader risk decision process, not pretend to be the process itself.

Exploitability context is now part of identity governance. When service boundaries, internal auth layers, token scopes, and runtime exposure are missing from the review loop, teams lose the ability to reason about who or what can actually use a flaw. That is especially relevant for NHI-heavy systems, where machine identities and service-to-service trust determine whether a code issue is reachable. Practitioners should treat context ingestion as a governance control, not a convenience feature.

AI review will keep scaling the finding count before it scales the decision quality. The underlying problem is not insufficient static analysis, but a missing control plane for exposure and trust. The named concept here is exploitability context gap: the distance between code-level suspicion and system-level risk. Security teams need to close that gap before automated review becomes a larger source of noise than signal.

Code reasoning cannot replace environment reasoning. Even strong multi-agent analysis stays bounded by what the code says, while actual risk depends on architecture, policy, and operational exception handling. That means the future of secure delivery is not more code-only scanning, but review processes that combine source analysis with deployment and identity context. Practitioners should align tooling with the environment, not the other way around.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Agentic AI Identity Risk Board Briefing

What this signals

Exploitability context gap: code scanners increasingly need environment data, because source-only review cannot tell whether a flaw is reachable, compensated for, or already isolated behind stronger controls. In practical terms, security teams should treat architecture, identity boundaries, and runtime exposure as inputs to review, not post-review documentation. According to the State of Secrets in AppSec, companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%.

Review volume is outrunning decision quality. AI-assisted development changes the security problem from finding defects to ranking them against real exposure. When review throughput stays flat while code output rises, organisations end up with more findings and less confidence in remediation priorities. For practitioners, the signal is that automation must be paired with system context, or it will scale noise faster than it scales assurance.

For practitioners

• Map review findings to exposure context Require every high-severity code finding to be checked against deployment topology, authentication layers, and reachability before it enters remediation priority queues.
• Ingest architecture and trust documents into triage Pull design specs, risk registers, and infrastructure configuration into the review workflow so reviewers can tell intentional exceptions from real flaws.
• Separate code defects from exploitability decisions Create a second-stage validation step for findings that may be neutralised by internal auth, compensating controls, or service-to-service trust boundaries.
• Track review capacity against AI-generated output Measure PR volume, issue volume, and reviewer throughput together so security teams can see when automation is outpacing human validation.

Key takeaways

• Code-only scanners can surface defects, but they cannot determine exploitability without deployment and trust context.
• AI-assisted development increases review volume faster than human teams can validate findings, which pushes security into triage overload.
• The control gap is context, not detection: teams need architecture, runtime, and identity data before they can prioritise remediation.

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.
• 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.
• 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.
• Triage Overload: The condition where the volume of security reports exceeds the team’s ability to review them in a timely way. In email defence, overload reduces analyst availability, increases dwell time for real attacks, and turns a visibility control into an operational bottleneck.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management for practitioners who need to connect access control to real-world security decisions. It is designed for teams building defensible identity security programmes across human and non-human identities.