Topic starter
02/08/2026 11:42 am
TL;DR: AI-assisted code can accelerate delivery, but it also drives more critical findings, more logic errors, hallucinated packages, and hidden secrets, according to OXSecurity. The real control shift is from post-commit scanning to in-workflow prevention that links repository lineage to live cloud reachability.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “AI Code Security: Common Threats, and Best Practices for Securing AI-Generated Code”.
By the numbers:
- AI-generated code contains up to 2.74x more cross-site scripting security vulnerabilities than human-written code.
- Traditional SAST tools can generate 76% false positives on AI-heavy projects.
- Traditional SAST tools can exceed 90% false positives on many large software projects.
Key questions
Q: What breaks when AI-generated code is only checked after commit?
A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them.
Q: Why do AI coding assistants increase the risk of real production exposure?
A: They increase risk because plausible-looking code can still carry unsafe dependencies, secrets, or cloud permissions that become dangerous only when linked to live runtime.
Q: What do organisations get wrong about scanning AI-generated code?
A: The common mistake is treating more scanning as a complete answer.
Practitioner guidance
- Implement prompt governance for AI coding assistants Constrain assistants with approved system prompts, policy rules, and pre-vetted templates so they cannot freely invent secrets, permissions, or insecure dependencies.
- Block hallucinated packages before installation Add dependency checks in the IDE and pull request flow so invented libraries are flagged before they reach build pipelines or production artifacts.
- Tie repository lineage to runtime reachability Correlate source files, pull requests, cloud roles, and exposed services so only reachable findings are prioritised for remediation.
Bottom line: AI-generated code can accelerate delivery while multiplying security defects, so teams need controls that act before code reaches the repository.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:54 pm
AI code security is now a governance problem, not just an application security problem. The article shows that AI assistants can accelerate defect creation faster than legacy review processes can absorb. That makes control design, not just scan coverage, the defining issue. Practitioners should treat generated code as governed output with identity, dependency, and runtime implications.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations govern AI tools that analyse source code?
A: Set evidence thresholds, require secondary validation for high-impact findings, and define who owns the final decision. Governance should cover prompt scope, output format, reviewer sign-off, and auditability. That keeps AI in an advisory role and prevents noisy model output from becoming an unreviewed security decision.
👉 Read our full editorial: AI code security fails when velocity outruns cloud context