Claude Code Security Review exposes the limits of AI code scanning

At a glance

What this is: This is an analysis of Claude Code Security Review, a Claude Code feature that uses LLM reasoning to find code vulnerabilities and business logic flaws that pattern-based scanners often miss.

Why it matters: It matters to IAM and security practitioners because authorization logic, privilege boundaries, and trust assumptions are exactly where AI-assisted code review can improve detection or create new attack surface.

By the numbers:

• Broken access control affects 100% of tested apps.
• AI-generated code contains 2.74x more vulnerabilities than human-written code on average.
• CVE-2025-59536 allows remote code execution through prompt injection in Claude Code scans.

👉 Read Gecko Security's analysis of Claude Code Security Review and business logic flaws

Context

Claude Code Security Review sits at the intersection of application security and identity governance because it tries to reason about whether code actually enforces access policy, not just whether a control exists on paper. That distinction matters in codebases where authentication, authorization, and privilege boundaries are distributed across services and repositories. This article is really about the limits of pattern-based security testing when logic, not syntax, defines the risk.

For IAM and PAM teams, the important signal is that business logic flaws are often identity failures in disguise. Missing permission checks, over-trusted service-to-service calls, and weak trust boundaries can all create privilege escalation paths even when scanners report clean results. The starting position described here is increasingly typical in modern development pipelines, especially where AI-generated code and AI-assisted review are already in use.

Key questions

Q: What breaks when AI code review tools are allowed to analyse untrusted pull requests?

A: The review workflow itself becomes an attack surface. Prompt injection in comments, documentation, or code can steer the model, expose secrets, or trigger unsafe actions if the tool has privileged access. Teams should treat untrusted pull requests as hostile inputs and require manual approval before automated security scanning runs.

Q: Why do AI-generated codebases create more security risk for authorization controls?

A: AI-generated code often looks functionally correct while missing the security context needed to enforce permissions properly. That creates broken access control, inconsistent checks across services, and logic gaps that traditional scanners may not recognise. The risk grows when teams assume syntax-correct code is also policy-correct.

Q: How do security teams know whether semantic code analysis is actually working?

A: Look for findings that map to real execution paths, cross-service trust boundaries, and business logic errors that pattern scanners miss. If a tool only repeats known syntax issues or produces noisy findings without proving exploitability, it is not giving you meaningful semantic coverage.

Q: Who is accountable when an AI security scanner exposes secrets or approves unsafe fixes?

A: Accountability stays with the organisation operating the workflow. The scanner is a privileged automation system, so teams need clear ownership for repository trust rules, approval gates, credential scope, and remediation validation. Security, engineering, and platform owners should share governance, but responsibility cannot be outsourced to the tool.

Technical breakdown

How semantic code analysis differs from pattern matching

Traditional SAST tools look for known insecure patterns such as string concatenation, literal secrets, or missing decorators. Claude Code Security Review instead builds semantic context, tracing how inputs move across functions and how checks behave along execution paths. That lets it reason about whether a permission check is meaningful in practice, not just whether a check exists. This matters for authorization because broken access control is usually a policy failure, not a syntax failure. The same code can look safe in isolation and still fail when a downstream service skips validation or a conditional branch opens an alternate route.

Practical implication: security teams need review methods that evaluate execution paths and policy enforcement, not just signature matches.

Why business logic flaws evade conventional application security tooling

Business logic flaws arise when software behaves correctly from a programming standpoint but incorrectly from a security standpoint. Examples include time-of-check-time-of-use issues, race conditions, and access control decisions that depend on assumptions a scanner cannot infer. In multi-tenant or microservice environments, those assumptions are often spread across gateways, APIs, and downstream services. That is why access control remains a hard problem: the correct policy is application-specific, while the failure mode is contextual. AI reasoning can help surface these mismatches, but only if the analysis understands the real execution context.

Practical implication: teams should treat authorization design as a first-class testable security property, especially across service boundaries.

Prompt injection risk in AI-powered security review

When an AI security tool reads repository content, it inherits the repository's trust boundary unless the workflow constrains it. Prompt injection turns ordinary code comments, documentation, or pull request text into an attack vector that can steer the model, expose secrets, or trigger unintended actions. That risk is amplified when the tool has access to API keys or privileged automation in CI/CD. In effect, the scanner becomes both a detector and a target. This is not a model-quality problem alone, it is a governance problem about where AI is allowed to operate and what it can touch.

Practical implication: restrict AI review systems to trusted inputs, minimal privileges, and manual approval for untrusted pull requests.

Threat narrative

Attacker objective: The attacker wants to exploit the AI review workflow itself to gain execution, extract secrets, or corrupt the security validation process.

1. Entry occurs when malicious content is placed into a pull request, code comment, or repository document that the AI review system will process during scanning.
2. Credential access or abuse follows when prompt injection steers the tool toward secrets, API keys, or other privileged context available in the scanning environment.
3. Impact occurs when the model is induced to execute unintended actions, expose credentials, or produce unsafe remediation suggestions that undermine the review workflow.

Breaches seen in the wild

• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Broken access control is now a semantic governance problem, not just an application bug. Pattern-based scanners can spot missing decorators and obvious injection strings, but they cannot determine whether a policy decision is correct across every execution path. That is why authorization flaws survive even in teams with mature tooling. For IAM and PAM practitioners, the lesson is that access logic needs contextual validation across gateway, service, and data layers, not just static code checks.

AI-powered review creates a new control plane for code security, and control planes need identity boundaries. Once an AI scanner can read code, use credentials, and produce fixes, it becomes part of the privileged workflow, not just an observer. That means the governance question shifts from detection accuracy to trust zoning, approval flow, and least privilege for the scanner itself. The practical conclusion is that AI review must be governed like any other high-trust automation.

Business logic security will become a defining gap in AI-generated code programmes. AI-generated code can satisfy functional tests while still violating authorization intent, which is why code quality and security quality are diverging. The article's statistics support a wider pattern: semantic flaws are outpacing control design. Practitioner teams should expect code review to become increasingly dependent on context-aware analysis and manual verification.

Prompt injection against security tooling is a supply chain issue for identity workflows. The moment repository content can influence a privileged AI assistant, untrusted text becomes an attack surface inside the development control plane. That failure mode is especially relevant to NHIs because API keys, tokens, and service credentials often sit inside the same automation boundary as the scanner. The governance conclusion is simple: trusted automation must not inherit unbounded trust from the artefacts it inspects.

Compiler-accurate semantic indexing is the right direction for cross-service authorization analysis. Once security logic spans multiple repositories and microservices, isolated scanning loses the ability to prove policy consistency. The market is moving toward tools that preserve call chains, trust boundaries, and execution context across the application estate. For practitioners, the key implication is to evaluate whether their security stack can follow identity and authorization decisions end to end.

From our research:

• Broken access control affects 100% of tested apps, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• AI-generated code contains 2.74x more vulnerabilities than human-written code on average, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• For a broader view of how compromised NHIs turn AI workflows into attack paths, see Shai Hulud npm malware campaign and its secret-exposure pattern.

What this signals

Authorization review is becoming a control problem, not a tooling problem. As codebases absorb more AI-generated logic, security teams need to test whether permission checks still work across gateways, services, and data paths. The practical signal is that static findings alone will understate risk, especially where identity and access decisions are distributed. For a broader control baseline, map the programme to NIST SP 800-53 Rev 5 Security and Privacy Controls and the Ultimate Guide to NHIs.

Scanner trust now belongs in the same conversation as credential trust. If an AI review system can read repository content and interact with privileged automation, it needs the same boundary discipline you would apply to any other NHI. That means least privilege, explicit approvals, and clear separation between detection and remediation. The emerging concept here is scanner privilege inflation: a security tool quietly gaining access that exceeds its actual review function.

The next governance question is whether your AI review stack can survive hostile content without exposing tokens, code, or control logic. That is where development security, IAM, and NHI governance start to converge, because the scanner is no longer passive infrastructure. Teams should watch for workflow designs that treat AI analysis as trusted by default, since that assumption breaks under prompt injection and credential exposure pressure.

For practitioners

• Test authorization logic across execution paths Add review cases for gateway-only checks, downstream service validation, and alternate routes that may bypass intended permission enforcement. Focus on business logic that looks correct in one component but fails in the full request path.
• Constrain AI review workflows to trusted inputs Restrict automated code review to repositories and pull requests you trust, require manual approval for external contributions, and block scans on forks where adversaries control repository content.
• Treat AI scanners as privileged systems Limit API key exposure, narrow repository read scope, and separate security-review permissions from broader CI/CD privileges so the scanner cannot access more than it needs to analyse code.
• Build human validation into every AI-generated patch Require developers to test AI-suggested fixes against business requirements, regression suites, and authorization intent before merging, because a patch that closes one flaw can create another.

Key takeaways

• AI-powered code review can uncover semantic authorization flaws that traditional scanners miss, but it also creates a new privileged workflow that must be governed like any other high-trust system.
• The evidence points to two parallel risks: broken access control remains pervasive, and AI-generated code introduces materially more vulnerabilities than human-written code.
• The practical control response is to combine semantic analysis with strict trust boundaries, human validation, and least-privilege access for every automated security reviewer.

Key terms

• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Semantic Code Analysis: A method of examining code based on meaning and intent rather than only syntax or known patterns. It tries to understand how an application behaves across files, services, and call chains so it can detect logic failures that signature-based tools miss.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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.

What's in the full article

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

• Step-by-step setup for Claude Code Security Review in terminal and GitHub Actions workflows.
• Configuration examples for severity thresholds, file exclusions, and scan timing in CI/CD.
• Limitations and exploitability notes for prompt injection and API key exposure scenarios.
• Side-by-side examples showing how the tool reasons about business logic flaws across code paths.

👉 Gecko Security's full post covers the semantic analysis workflow, configuration details, and security limitations in more depth.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security and identity practitioners build the control foundation needed for modern automation and privileged workflows.