Notifications
Clear all
Topic starter
01/08/2026 8:59 pm
TL;DR: AI security tools reached a $35.40 billion market in 2026, but the source article argues the category still splits between systems that secure AI itself and tools that use AI to find code flaws, with traditional SAST missing broken access control and privilege chains that affect 100% of tested apps, according to Gecko Security. The practical issue is not more scanning, but better reasoning about application intent, trust boundaries, and false positives.
NHIMG editorial — based on content published by Gecko Security: AI security tools and what they miss in 2026
By the numbers:
- Across 80 coding tasks spanning four programming languages, only 55% of AI-generated code was secure.
Questions worth separating out
Q: How should security teams evaluate AI security tools for broken access control in microservices?
A: Security teams should test tools against real authorization flows, not just common injection patterns.
Q: Why do AI security tools struggle with privilege escalation chains?
A: They struggle because privilege escalation often depends on context, sequence, and trust between services.
Q: What do security teams get wrong about AI-based false-positive reduction?
A: They often assume AI will fix weak telemetry, but AI only scores what the platform can already see.
Practitioner guidance
- Validate authorization-aware detection Test whether scanning tools can identify broken access control, IDOR, and multi-service privilege chains in your real codebase, not just syntax-level issues.
- Measure findings by exploitability Require proof-of-concept validation, concrete remediation guidance, or reproducible evidence before a finding reaches engineering queues.
- Treat service-to-service access as an identity control Review internal APIs, delegated tokens, and workload identities as part of your access governance model.
What's in the full article
Gecko Security's full article covers the operational detail this post intentionally leaves for the source:
- How the vendor distinguishes AI system protection from code vulnerability detection in practice
- Tool-by-tool capability comparisons for semantic analysis, SAST, and runtime detection workflows
- Examples of microservice authorization flaws that the vendor says traditional scanners miss
- Pricing and deployment considerations for teams evaluating AI security tools at scale
👉 Read Gecko Security's analysis of AI security tools and broken access control →
Broken access control in AI security tools: what teams miss?
Explore further
01/08/2026 9:06 pm
Broken access control is the real frontier in AI security tooling. The article’s strongest finding is not about model protection or signature quality, but about whether tools can understand application intent. In identity terms, that means authorisation logic now matters as much as vulnerability pattern coverage. Teams that treat authorization as a code-only problem will miss the governance layer where identity, privileges, and service trust actually fail.
A question worth separating out:
Q: How should security teams govern AI use in developer tooling?
A: Security teams should govern AI use as a data and access problem, not only a productivity feature. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.
👉 Read our full editorial: AI security tools still miss access flaws that break real apps
