LLMs are changing how teams find business logic vulnerabilities

At a glance

What this is: This is an analysis of why business logic vulnerabilities remain hard to detect and why LLM-assisted code reasoning is being explored as a way to find them.

Why it matters: It matters because access-control failures, authorization bypasses, and intent-level bugs affect IAM, PAM, and application security programmes by creating hidden privilege and boundary violations that conventional tooling often misses.

By the numbers:

• 100% of applications tested were found to have some form of broken access control.

👉 Read Gecko Security’s analysis of how LLMs find business logic vulnerabilities

Context

Broken access control persists because systems often enforce syntax well but fail to enforce intent, which is exactly where business logic vulnerabilities emerge. In practical terms, the problem is not only a missing check, but a missing understanding of what each user, tenant, or role should be allowed to do in context. That makes the topic relevant to IAM, authorization design, and application governance as well as secure coding.

The article also touches an important identity intersection: AI-assisted code review is being used to reason about permissions, trust boundaries, and authorisation paths that humans typically map mentally. That creates a new governance question for security teams. If machine assistance is going to help find semantic flaws, it must be paired with clear identity and access assumptions in the application itself, not used as a substitute for them.

Key questions

Q: Where do business logic vulnerabilities fail in practice?

A: They fail wherever the application assumes intent instead of enforcing it. That usually shows up in object references, role transitions, workflow steps, or tenant boundaries. A tool may confirm that code runs, but only a semantics-aware review can tell whether the action should have been possible in the first place.

Q: Why do broken access control issues survive normal application security testing?

A: They survive because many tools look for patterns inside a single file or repository, while the failure often lives in how multiple functions or services enforce the same rule differently. If the analysis cannot trace where permissions are checked, dropped, or assumed, it will miss the actual control failure. That is especially common in distributed systems.

Q: What do security teams get wrong about review loops in AI-assisted development?

A: Teams often assume a review loop automatically means control is preserved. In practice, the agent may still make substantial changes before the developer sees them, especially when planning is hidden or optional. The control issue is not whether review exists, but whether review happens early enough to constrain the change path.

Q: How should teams test for business logic flaws before release?

A: They should build tests around misuse of legitimate functionality, not just malicious inputs. The right approach is to validate state transitions, privilege changes, object access, and tenant separation across full workflows. If an action becomes unsafe only when combined with another action, the test suite needs to cover that chain explicitly.

Technical breakdown

Why business logic vulnerabilities evade pattern-based tooling

Business logic flaws are semantic failures, not syntax failures. A scanner can detect a known bad pattern, but it cannot reliably infer whether an action is allowed in the business context of the application. That is why broken access control, IDOR, and authorization bypass often survive SAST, DAST, and runtime controls. These tools are useful for known classes of input abuse, but they struggle when the attack uses intended functionality in an unintended sequence. The hard part is understanding state, role, and workflow, not just code structure.

Practical implication: teams need explicit authorization testing for workflow edges, not just pattern-based scanning.

How LLMs help reason about source code intent

LLMs are useful here because they can read documentation, inspect call chains, and infer how the application is supposed to behave across multiple steps. In a code security context, that means they can model the difference between an allowed action and an allowed sequence. The value is not that the model magically knows security, but that it can correlate API paths, object references, and trust transitions faster than a human can on large codebases. The limitation is obvious: the model still needs guardrails, testable outputs, and human review for final judgement.

Practical implication: use LLMs to surface candidate logic flaws, then validate them with human review and exploitability testing.

Why broken access control stays high in cloud-native and AI-assisted code

Cloud, containers, and microservices multiply trust boundaries. Each service hop, token check, and object lookup becomes another place where authorisation can drift from design intent. When AI-generated code is added to that mix, the risk is not only more bugs but more confidence in insecure output. That combination creates fertile ground for privilege boundary mistakes, especially where developers assume the framework or model has handled the hard parts. Business logic risk grows when teams confuse speed of delivery with security of design.

Practical implication: review permission flows and object-level access in every new service and AI-assisted code path.

Threat narrative

Attacker objective: The attacker wants to abuse legitimate application behaviour to reach data or privileges that should have remained out of scope.

1. Entry occurs when an application exposes a workflow, endpoint, or object reference that can be invoked outside the intended permission path.
2. Escalation follows when the attacker chains missing authorization checks or weak object validation to move from normal user actions into unauthorized access.
3. Impact occurs when the flaw is used to disclose, modify, or destroy data, or to cross tenant and privilege boundaries at scale.

NHI Mgmt Group analysis

Broken access control is still the clearest signal that intent-based security is failing at scale. OWASP keeping this category at the top reflects a governance problem, not just a coding problem. Organisations have improved at blocking known technical patterns, but many still fail to encode who can do what, when, and in which state. The practitioner conclusion is simple: security review has to include business intent, not only syntax.

LLM-assisted code analysis matters because it targets the semantic layer that conventional tooling misses. The article’s core point is that business logic flaws are not reducible to signature matching. That makes them a natural fit for tools that can trace call chains, infer workflow, and reason about application meaning. For IAM and application security teams, the practical takeaway is to treat AI as a reasoning accelerator, not as a replacement for policy design.

AI-generated code is amplifying an existing authorisation problem, not creating a new one. Faster code production increases the amount of code that can contain unreviewed access assumptions, while developer confidence can rise faster than security quality. That is especially relevant where identity and access decisions are distributed across APIs, microservices, and machine-generated logic. The practitioner conclusion is to put authorisation verification on equal footing with functional testing.

Business logic security needs a named governance concept: intent drift. Intent drift is the gap between what the application is supposed to allow and what its actual control paths permit. It explains why a system can look secure in testing yet still fail under chained operations, role changes, or object enumeration. This is where identity governance meets secure engineering: if access intent is not explicit, automated tooling will keep missing the risk. The practitioner conclusion is to formalise access intent and test it continuously.

From an identity perspective, broken access control is the application-layer version of over-entitlement. The same governance weakness appears when systems assume the right actor will always use the right path. In reality, users, service accounts, and AI-assisted workflows can all traverse unintended routes if the control model is incomplete. That makes application authorisation reviews part of broader IAM and PAM assurance. The practitioner conclusion is to connect code review findings back to access policy ownership.

What this signals

Business logic security is becoming a programme-level issue because AI-assisted development increases code volume faster than human review capacity. Teams should expect more semantic flaws in permission paths, especially where application logic is split across services and identity checks are implicit rather than enforced. The operational response is to move authorisation validation earlier in the lifecycle and make it testable, not anecdotal.

The next control frontier is not another scanner, but stronger assurance around access intent. Intent drift: the mismatch between what a system should allow and what its actual control paths permit. That concept should now shape how teams review APIs, object access, and AI-generated code, because the risk is hidden in normal behaviour rather than obvious malicious payloads.

For practitioners

• Map business workflows to explicit authorization rules Document the actions, states, and role boundaries that each endpoint or object reference is allowed to support. Use that map to find where the implementation depends on implied behaviour instead of enforced policy. suggested_anchor should not be used here.
• Add adversarial tests for workflow abuse Create test cases for IDOR, privilege escalation, tenant crossing, and multi-step misuse of legitimate functions. Focus on how normal inputs can be chained into unauthorized outcomes rather than on payload signatures.
• Review AI-generated code for hidden access assumptions Treat code produced with AI assistance as a risk amplifier when it touches authorization, object lookup, or role logic. Require human review of access checks and ensure the same review applies to hand-written and generated code paths.
• Pair LLM findings with manual exploit validation Use LLMs to surface candidate business logic flaws, then confirm whether the issue is reachable, repeatable, and harmful in the real application. Prioritise the findings that cross tenant boundaries or expose administrative functions.

Key takeaways

• Broken access control remains high because many systems still fail to enforce intent, not just syntax.
• LLMs are useful for reasoning about application meaning, but they do not remove the need for human authorization review.
• Security teams should test workflows, role transitions, and object boundaries as part of release gating, not as an afterthought.

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.
• 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.
• Intent Drift: A mismatch between the original purpose of an agent session and the outcome produced by a later chain of actions. It matters because each step can be individually permitted while the overall behaviour still becomes unsafe or non-compliant.

What's in the full article

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

• The BSides London talk context and the research workflow behind the LLM-based approach to finding business logic bugs
• Examples from Cal.com, N8N, GitLab, and Optus that show how authorization failures manifest in real systems
• The comparison between SAST, DAST, runtime tooling, and human-style reasoning for semantic vulnerability discovery
• The implementation model Gecko Security uses to trace call chains from source to sink and infer intended behaviour

👉 Gecko Security’s full post covers the research examples, tooling limits, and reasoning workflow in more detail

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle topics. It helps practitioners connect access policy, privilege control, and governance across modern security programmes.