Notifications
Clear all
Topic starter
02/08/2026 11:47 am
TL;DR: AI-generated code often passes functional tests while missing ownership checks, authorization logic, and other semantic safeguards, with Veracode finding 45% of samples contain vulnerabilities and Carnegie Mellon reporting only 10% meet basic security standards. Traditional SAST tools miss these flaws because they analyze syntax, not execution meaning, so governance must shift to semantic verification and review.
NHIMG editorial — based on content published by Gecko Security: The AI Code Security Crisis and AI-generated business logic vulnerabilities
By the numbers:
- Gecko Security finds authorization gaps across microservices with 50% fewer false positives.
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why do AI-generated features create more broken access control risk?
A: AI assistants optimise for code that works, not code that preserves application-specific security rules.
Q: What do security teams get wrong about scanning code faster?
A: They often assume more scanning will close the gap created by faster development.
Practitioner guidance
- Define code categories that must stay human-authored Keep authentication flows, authorization frameworks, and cryptographic logic outside AI generation unless an engineer can review every decision point.
- Require explicit authorization specifications before generation Document ownership rules, role hierarchy, tenant isolation, and data access constraints before asking an assistant to build any feature touching user data.
- Trace execution paths across services before merge Check that the request remains authorized after it leaves the API gateway and before any sensitive query, update, or delete action runs.
What's in the full article
Gecko Security's full article covers the operational detail this post intentionally leaves for the source:
- Analysis of Code Property Graph techniques for tracing authorization across files and services
- Examples of how proof-of-concept exploit generation separates true business logic flaws from noisy findings
- Side-by-side comparison of AST-based scanning versus semantic analysis on AI-generated code
- Microservice-specific detection examples for ownership checks, role validation, and trust-boundary failures
👉 Read Gecko Security's analysis of AI-generated code and broken access control →
AI-generated code and broken access control: are your controls keeping up?
Explore further
02/08/2026 12:57 pm
Semantic security debt is the right label for AI-generated code risk. The problem is not simply that generated code contains bugs. It is that the code often satisfies functional requirements while silently violating the application's security intent. When access control lives in application logic, that debt becomes an IAM-adjacent governance issue because privilege decisions are being expressed in code that may not enforce them reliably. Practitioners should treat generated code as a control boundary, not just a productivity aid.
A question worth separating out:
Q: How do microservices make AI-generated authorization flaws harder to detect?
A: Each service can look correct in isolation while the overall flow still fails to enforce access control. The gateway may authenticate the request, but a downstream service can still skip authorization before querying or modifying data. Teams need end-to-end path analysis to catch that gap.
👉 Read our full editorial: AI-generated code is widening the business logic security gap
