Notifications
Clear all
Topic starter
02/08/2026 11:32 am
TL;DR: AI coding tools frequently produce functional applications that still ship with injection flaws, exposed secrets, weak cryptography, and missing access controls, while Gartner says prompt-to-app adoption could increase software defects by 2500% by 2028 and many employees already use unapproved GenAI accounts for work. The security gap is no longer in code generation alone, but in whether teams can validate runtime behaviour, access control, and dependency risk before release.
NHIMG editorial — based on content published by OXSecurity: AI code security, common threats, and best practices for securing AI-generated code
By the numbers:
- Gartner warns that by 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2500%.
- A Gartner survey of 175 employees conducted between May and November 2025 found that over 57% use personal GenAI accounts for work purposes.
- 33% admit inputting sensitive information into unapproved tools.
Questions worth separating out
Q: What breaks when AI-generated code is reviewed without security gates?
A: What breaks is the assumption that a clean-looking diff is a safe diff.
Q: Why do AI coding tools increase the risk of insecure authentication and authorisation?
A: They often reproduce common patterns from training data, including incomplete login flows, permissive access checks, and unsafe session handling.
Q: How can security teams tell whether AI-generated code is actually safe?
A: They should look for security regression evidence, not just test pass rates.
Practitioner guidance
- Embed security context into prompt workflows Require generation prompts to include authentication, validation, secret-handling, and access-control requirements before code is accepted into the pipeline.
- Test live controls with adversarial cases Run behavioural tests against staging and production-like environments to confirm row-level security, token checks, and permission boundaries actually block unauthorised access.
- Treat generated dependencies as supply-chain risk Scan for vulnerable packages, transitive dependencies, and suspicious imports before build completion, then correlate findings with runtime reachability.
What's in the full article
OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- Walkthroughs of specific AI coding failure modes across authentication, injection, and dependency selection.
- Examples of how AI-generated infrastructure and application code introduce hidden access-control gaps.
- Operational guidance on embedding security into prompting, review, and validation workflows.
- Additional discussion of how runtime testing can confirm whether access controls actually hold.
👉 Read OXSecurity's analysis of AI-generated code security failures and runtime blind spots →
AI-generated code: why security gaps survive functional testing?
Explore further
02/08/2026 12:47 pm
AI-generated code creates security debt faster than conventional review can absorb. The central problem is not that AI writes bad code in every case, but that it writes plausible code faster than teams can validate it. That shifts risk from isolated defects to systemic governance failure. In that environment, application security becomes a control-plane problem that spans code generation, runtime permissions, and secret handling. Practitioners should treat AI-assisted development as a governance domain, not just a productivity choice.
A question worth separating out:
Q: What should organisations do when AI-generated applications handle tokens or privileged access?
A: Treat those applications as part of the identity security surface. Review token scope, service-account use, database roles, and any code path that can create or consume credentials. If the app touches identity, IAM and PAM teams should validate the control design before release.
👉 Read our full editorial: AI-generated code often works while remaining insecure in production
