LLMs are changing how teams find business logic vulnerabilities

At a glance

What this is: This is a Gecko Security analysis of why LLMs are being used to find business logic vulnerabilities that traditional SAST, DAST, and runtime controls often miss.

Why it matters: It matters because IAM and application security teams need to understand where intent failures and authorization gaps outgrow pattern-based testing, especially in cloud-native and AI-assisted development.

By the numbers:

• Broken access control remained OWASP’s number one web application risk in the 2025 release, while injection fell to fifth place.
• OWASP said 100% of applications tested had some form of broken access control.
• GitLab disclosed three CVEs in July 2025 that allowed users to bypass group-level restrictions on invitations and forking.
• Optus exposed 10 million user records in 2022, roughly a third of Australia’s population.

Context

Business logic vulnerabilities are not syntax problems. They are intent problems, which means controls that rely on known patterns, signatures, or fixed rules will always miss a class of failures that only appears when a system behaves in the wrong context. That makes this topic relevant not just to application security, but to identity governance wherever permissions, trust boundaries, and access decisions are encoded in application flow.

The article frames LLMs as a way to scale human-style reasoning across code paths, API flows, and state transitions. For IAM and PAM teams, the identity angle is clear: when authorization logic is wrong, the control failure is often not a missing login but a broken decision about what an authenticated user or system should be allowed to do.

The article’s examples show this is a mainstream application security problem, not a niche edge case. Broken access control becomes harder to contain as cloud-native architectures multiply endpoints, identities, and decision points across services.

Key questions

Q: What breaks when business logic controls are tested only with pattern-based tools?

A: Pattern-based tools miss intent failures because they look for known code shapes, payloads, or signatures. Business logic flaws often sit in valid workflows where the system behaves incorrectly only when state, sequence, or authorization context is wrong. That is why semantic review and human validation remain necessary alongside automated scanning.

Q: Why do broken access control issues keep ranking above other web vulnerabilities?

A: Because authentication can succeed while authorization still fails. Modern applications distribute decisions across APIs, services, and user states, which multiplies the chances that a request is accepted even though the caller should not be allowed to act. The result is persistent exposure across data, tenancy, and privilege boundaries.

Q: What are the signs that authorization logic is failing?

A: Common signs include repeated role-check branches, inconsistent decisions between services, manual exceptions, and difficulty explaining why a user could act on a specific object. If reviewers cannot trace the decision path, governance is already too fragmented.

Q: How should teams use LLMs for business logic testing without overtrusting them?

A: Use LLMs to accelerate code reading, path tracing, and hypothesis generation, then validate every candidate flaw with human context and manual verification. The model should reduce search time, not replace judgement about business intent, exploitability, or impact.

Technical breakdown

Why business logic flaws evade pattern-based testing

Business logic flaws occur when code does the wrong thing while still looking syntactically correct. Unlike injection, where defenders can enforce safe structure through parameterization or prepared statements, these bugs depend on application meaning, user state, and the expected sequence of actions. Static scanners, DAST probes, and runtime filters are built to match known shapes of abuse, so they struggle when the exploit is really about an invalid business decision hidden inside legitimate functionality.

Practical implication: Treat semantic testing as a separate workstream from signature-based scanning, especially for authorization-heavy workflows.

How LLMs change source-code review for authorization paths

LLMs can follow call chains, infer intent from surrounding code, and reason about whether an authorization rule actually matches the application’s business model. That makes them more suited to tracing multi-step logic than tools that only look for known CWE patterns. The useful shift is not that the model replaces testers, but that it can help surface candidate abuse paths fast enough for a human to validate them with context and judgement.

Practical implication: Use AI-assisted review to triage complex authorization paths before human testers spend time on low-value code search.

Why cloud and microservice sprawl increases business logic risk

Microservices, APIs, and cloud delivery break application behaviour into more trust boundaries, which multiplies the number of places where intent can drift from enforcement. Each service may authenticate correctly but still authorize incorrectly, especially when identifiers are sequential, tenancy boundaries are weak, or upstream assumptions are not enforced downstream. The more distributed the workflow, the more likely a logic flaw will hide in the gaps between components.

Practical implication: Map authorization decisions across service boundaries, not just inside individual services or endpoints.

Threat narrative

Attacker objective: The attacker wants to turn legitimate application flows into unauthorized access paths that expose data, bypass boundaries, or elevate privileges.

1. Entry occurs through exposed application functionality that is reachable to ordinary users or internet callers, not through exploitation of a memory corruption bug.
2. Credentialed or unauthenticated access is then used to test business logic boundaries, where the attacker probes whether the system enforces the intended authorization state.
3. Escalation happens when the attacker chains weak object controls, missing session checks, or predictable identifiers to reach data or functions outside their permissions.
4. Impact is unauthorized disclosure, modification, or destruction of data, often at tenant, account, or repository scale.

Breaches seen in the wild

• Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

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

Business logic is now the decisive blind spot in application security. Injection was reduced by making invalid syntax harder to express, but intent failures cannot be eliminated by pattern matching. That means traditional secure-development controls are necessary but no longer sufficient when authorization itself is the thing under attack. Practitioners should treat semantic abuse as a first-class testing category, not an edge case.

LLM-assisted testing changes the economics of finding authorization flaws. Human testers still provide judgement, but models can accelerate code comprehension, flow tracing, and candidate exploit path discovery. That matters because the bottleneck has never been the existence of bugs, only the cost of reasoning through enough code to find them. Teams that ignore AI-assisted review will fall behind attackers and defenders who can reason at scale.

Broken access control is the identity problem hiding inside application security. Every authorization failure is also a failure to enforce who or what may act on a resource, which is why IAM concepts, application logic, and API governance increasingly overlap. This is where business logic testing and identity governance meet, especially in cloud-native systems with many service identities and delegated decision points. Practitioners should align application testing with identity enforcement, not keep them as separate disciplines.

Semantic vulnerability detection will become a governance question, not just a tooling question. If AI can reason over intent, then security teams must decide how results are validated, triaged, and translated into policy. The real operational challenge is not whether LLMs can find flaws, but whether the organisation can absorb those findings into engineering and assurance workflows. Teams should prepare for AI-assisted review as part of the security operating model.

Business logic findings create a different risk signal than conventional vulnerability counts. A single flaw can expose entire tenants or operational workflows, so severity scores alone understate impact. That changes prioritisation for security leaders, who need to weigh exploitability, business reach, and control boundaries together. Practitioners should rank these issues by blast radius, not by scanner output volume.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Business logic testing is becoming an identity governance problem as much as an application security problem. When an application accepts a request it should not, the failure is often a broken access decision rather than a broken code pattern. Teams should expect more findings where authorization rules, tenant separation, and service identity assumptions need to be tested together.

LLM-assisted review will shift attention from detection volume to decision quality. The hard part is no longer only finding issues, but deciding which findings reflect real intent failures and which are noise. Security programmes that can absorb semantic findings into secure-development and IAM workflows will be better placed to handle cloud-native sprawl and AI-assisted coding.

Business logic flaws expand faster when developers trust generated code too much. That is especially relevant as AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. The practical response is to test intent at the same speed that development is now producing code.

For practitioners

• Instrument authorization-flow testing for semantic abuse Add review steps that trace how users, tenants, and service accounts move through business workflows, with explicit checks for missing or inconsistent authorization decisions.
• Prioritise high-value logic paths for AI-assisted review Focus LLM-based analysis on endpoints, workflows, and call chains where a single access-control failure would expose many records, tenants, or privileged actions.
• Verify object-level and group-level access enforcement Check whether identifiers, invitation flows, forking actions, and tenant boundaries are enforced consistently across the application, not just at the front door.
• Test distributed workflows for hidden trust gaps Review cloud-native and microservice flows for places where one service assumes another already performed authorization, validation, or session checks.
• Feed confirmed logic flaws back into secure development rules Turn each validated business logic issue into a reusable test case or policy rule so the same failure mode is caught earlier in future builds.

Key takeaways

• Business logic vulnerabilities persist because they break intent, not syntax, so the controls that defeated injection do not solve the new problem.
• LLM-assisted analysis is changing how teams find authorization flaws by scaling the reasoning that human testers already use.
• Application security and identity governance now overlap more tightly because broken access control is fundamentally a failed authorization decision.

Key terms

• 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.
• 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 Vulnerability: A semantic vulnerability is a flaw in meaning rather than structure. The application may pass syntax checks and still fail because its logic does not enforce the right business rule, which makes these issues harder to detect with pattern-based tools alone.
• LLM-Assisted Security Testing: LLM-assisted security testing uses large language models to help reason about code, workflows, and attack paths. The value is not automatic detection, but faster analysis of context and intent so that human reviewers can validate whether a candidate flaw is real and exploitable.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management. It is designed for practitioners who need a stronger identity lens across modern security programmes.