AI security tools still miss access flaws that break real apps

At a glance

What this is: Gecko Security argues that many AI security tools still miss business logic failures like broken access control and privilege escalation chains, even as the category expands.

Why it matters: For IAM, application security, and NHI practitioners, the issue is whether tooling can understand trust boundaries and authorisation intent well enough to catch real access flaws before they become abuse paths.

By the numbers:

• The AI cybersecurity market hit $35.40 billion in 2026.

Context

AI security tools now sit in two different problem spaces: securing AI systems themselves and using AI to find vulnerabilities in software. The governance challenge is that teams often buy for one problem while assuming coverage across both, especially when microservices and AI-generated code create more trust boundaries than traditional review processes can handle.

The core gap is broken access control. Pattern-matching scanners can find obvious injection flaws, but they struggle when the defect depends on application intent, service-to-service authorization, or a privilege chain that only appears across components. That makes this a practical application security and IAM problem, not just a scanning problem.

For identity teams, the important intersection is authorisation governance across service-to-service calls and machine-driven workflows. When a tool cannot reason about who or what should be allowed to act across boundaries, the organisation is left with detection that is fast but shallow.

Key questions

Q: What breaks when AI security tools cannot reason about broken access control?

A: They miss the defects that depend on application intent, object scope, and service-to-service authorisation rather than known code patterns. That creates blind spots for IDOR, privilege escalation, and other logic flaws that only appear when a request is evaluated in context. The result is confidence without coverage, which is worse than an obvious gap because teams trust the tool too much.

Q: Why do microservices make privilege escalation harder for scanners to detect?

A: Because the authorisation decision is often distributed across several services instead of living in one obvious code location. A scanner that only inspects a single file or endpoint cannot always see the full trust chain, so it may miss the point where a lower-privilege request becomes a higher-privilege action. Distributed systems therefore demand distributed reasoning.

Q: How do security teams know if an AI scanner is missing real authorisation flaws?

A: Look for repeated misses on representative tests such as IDOR, object access bypasses, and service-to-service escalation paths. If the tool flags many syntactic issues but fails on business logic cases that matter to your architecture, it is optimised for noise reduction rather than meaningful assurance. The test is whether it catches the exact control failures your system can actually suffer.

Q: Should teams use the same tooling for AI system security and code vulnerability detection?

A: No. AI-system security tools focus on prompt injection, model misuse, and pipeline abuse, while code security tools need to reason about authorisation, business logic, and trust boundaries in applications. Conflating the two leads to gaps because the underlying control questions are different, even when the vendor marketing makes them sound adjacent.

Technical breakdown

Why pattern matching misses broken access control

Traditional SAST and rule-based scanners look for known code shapes, token patterns, or unsafe functions. That works well for injection-style flaws, but broken access control is usually an intent failure: code does something unsafe because the authorisation decision is missing, misplaced, or applied to the wrong object. In microservices, the problem gets harder because the check may be split across services, middleware, and API gateways. A scanner that only inspects local syntax cannot determine whether a request should have been blocked earlier in the trust chain.

Practical implication: Use tools that can reason about application intent and service boundaries when authorisation errors are part of the threat model.

Why microservices create privilege escalation chains

Microservices break monolith assumptions by distributing trust across many internal calls. One weak access control can become a privilege escalation chain when a lower-trust service can call a higher-trust service without proper object-level or function-level authorisation. That is why IDOR and broken access control often appear as multi-step abuse paths rather than single vulnerable lines of code. The flaw is not just exposure, but the absence of a reliable decision point that proves the caller may act on the target resource.

Practical implication: Model service-to-service authorisation explicitly and verify that each hop enforces the intended privilege boundary.

Semantic analysis versus syntax scanning

Semantic analysis builds a representation of what the code is supposed to do, not just what it says. In practice, that means tracking data flow, trust boundaries, and control flow across files and services so the scanner can ask whether an action is authorised in context. This is the difference between finding suspicious code and proving that an execution path lacks a meaningful access check. For modern applications, especially AI-generated code and distributed systems, that deeper reasoning is often the only way to surface business logic flaws before production.

Practical implication: Prioritise scanning approaches that validate behaviour across context, not just syntax within a single file.

Threat narrative

Attacker objective: The attacker wants to bypass intended authorisation boundaries and gain access to functions or data that should have remained out of reach.

1. Entry occurs through application code or API paths where the scanner must understand whether a request is authorised in context.
2. Credential or privilege abuse follows when a lower-privilege caller can reach a higher-value object or function through a missing access check.
3. Impact appears as broken access control, IDOR, or privilege escalation across microservices, exposing actions that the application design never intended to permit.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

Broken access control is the defining blind spot in many AI security tools. The market may be crowded, but crowding does not equal coverage. Tools that excel at pattern detection often underperform when the risk depends on application intent, object ownership, or service-to-service authorisation. For practitioners, that means the decision is no longer about scan volume but about whether the platform can reason across trust boundaries.

Microservice architecture turns authorisation into a distributed governance problem. Each service call can become part of a privilege chain if the caller identity, object scope, or function scope is not checked consistently. This is where IAM and application security converge: the control failure is not only in code, but in how the system models who may do what across internal boundaries. Teams should treat service authorisation as a first-class governance domain, not a side effect of API design.

Semantic analysis is the more relevant category distinction than AI branding. The useful split is not AI versus non-AI security, but whether the tool understands the business meaning of a request. That is a more durable concept for buyers because it maps to the actual control gap, which is the inability to prove whether a user, service, or workload is authorised for a given action. Practitioners should select for reasoning depth, not marketing language.

AI-generated code raises the cost of shallow detection. When code ships faster and with less scrutiny, tools that only match known vulnerability shapes will miss the flaws that matter most in distributed applications. The governance consequence is a larger authorisation review burden at the same time that engineering teams want less friction. Security programmes should therefore align scanner choice with the complexity of their trust model, not with the volume of alerts they can tolerate.

Application intent is now a security control surface. When tooling cannot understand the expected behaviour of a microservice or API, it cannot reliably separate a real vulnerability from benign variation. That makes business logic analysis a category requirement for modern software estates, especially where access decisions are embedded in service flows rather than centralised in one gateway. Practitioners should expect tooling to validate intent, not merely inspect inputs.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Business logic analysis is becoming a minimum requirement for modern application security. As microservices, AI-generated code, and delegated service calls increase, the question is no longer whether a scanner can find obvious defects. It is whether it can understand the intended control path well enough to detect when access rules are missing or misapplied.

For IAM and application security teams, the real buying criterion is reasoning depth. Tools that cannot model object ownership, service trust, and privilege boundaries will underperform in environments where access decisions are distributed. That pushes the control conversation from vulnerability counting toward authorisation assurance.

Broken access control remains the governance gap that pattern matching cannot close. Security leaders should treat this as a selection problem, not a tuning problem, because a tool that cannot evaluate context will continue to miss the same class of defect no matter how many rules are added.

For practitioners

• Prioritise semantic reasoning for authorisation-heavy code Evaluate scanners against workflows where access decisions depend on business context, not just known bad patterns. Use representative microservice paths, object access cases, and multi-step service calls to test whether findings reflect real authorisation gaps.
• Map service-to-service trust boundaries Document where each internal call makes an access decision, then check whether that decision is enforced consistently at the service, API, and object level. This matters most where privilege escalation could occur across internal hops.
• Test for false negatives on broken access control Build validation cases for IDOR, privilege escalation, and missing object checks, then compare scanner output against the expected control path. A low-noise tool that still misses these cases is not fit for this risk profile.
• Separate AI-system security from application security Buy or deploy controls for prompt injection, model abuse, and pipeline risk separately from controls that find code flaws. The two problems overlap operationally, but they require different detection logic and different assurance questions.

Key takeaways

• AI security tooling still splits between protecting AI systems and finding application flaws, and those are not interchangeable problems.
• Broken access control remains a blind spot because it depends on business intent, not just code patterns or signature matching.
• Teams need tools that reason across trust boundaries if they want to catch IDOR and privilege escalation before release.

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.
• IDOR: Insecure Direct Object Reference is a vulnerability where an application exposes internal object identifiers and fails to verify whether the requesting principal is entitled to access them. The flaw often produces unauthorized reads, writes, or account-level actions.
• Semantic Analysis: Semantic analysis is the process of understanding how code behaves in context rather than only matching known patterns. In security review, it helps surface logic flaws, trust-boundary issues, and access problems that signature-based tools often miss.
• Microservices Trust Boundaries: Microservices trust boundaries are the points where one service is allowed to communicate with another and where access decisions must be enforced. In practice, they require precise authentication and authorization because small services multiply the number of interactions, making weak boundary design a common source of lateral movement and unauthorized access.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions their programmes depend on.