Topic starter
06/09/2026 9:34 am
TL;DR: AI coding tools are now mainstream in enterprise development, with about 90% of Fortune 100 companies using them and 40% to 50% of code in many environments being AI-generated, according to Arxan Technologies. The security implication is that faster code creation is compressing the window between vulnerability introduction and exploitation, making continuous application protection more urgent than periodic review.
Editorial analysis by NHI Mgmt Group, based on content published by Arxan Technologies: “The Fourth Wave: When AI Writes the Code — and Hacks It”.
By the numbers:
- ~90% of Fortune 100 companies are using AI coding tools.
- ~40-50% of code is now AI-generated in many environments.
Key questions
Q: What breaks when AI coding agents are allowed to ship code without security constraints?
A: Teams get working software that can still carry old, well-known vulnerabilities back into production.
Q: Why do AI-assisted attacks increase risk even when teams still run vulnerability scans?
A: Because the attacker’s cycle can now be shorter than the defender’s scan-and-remediate cycle.
Q: Why do service accounts and API tokens make application exploits worse?
A: Service accounts and API tokens extend a host compromise into other systems because they carry machine authority beyond the vulnerable process.
Practitioner guidance
- Embed policy checks in the build pipeline Require automated checks for insecure patterns, secret exposure, and authorization logic before code reaches release gates.
- Treat runtime protection as baseline control Use runtime application self-protection, anti-tampering, and obfuscation where applications face direct internet exposure or handle sensitive business flows.
- Review NHI dependencies in AI-assisted applications Map the service accounts, tokens, and API keys that AI-generated components can reach, then constrain their scope to the minimum required.
Bottom line: AI-assisted development is compressing the time between vulnerability introduction and exploitation, which makes periodic review too slow on its own.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 9:34 am
AI-generated code has created a security governance gap, not just a productivity shift. The central failure is that many development and release controls still assume human review can absorb the risk introduced by software created at machine speed. Once code can be produced, copied, and deployed faster than it can be understood, the organisation is governing velocity without governing trust. Practitioners should treat this as a release-governance problem as much as an appsec problem.
A question worth separating out:
Q: Should security teams prioritise runtime application protection or better code review first?
A: They should treat them as complementary controls, but runtime protection becomes more urgent when release cycles are fast and applications face active probing. Better code review reduces defect introduction, while runtime controls reduce exposure after defects inevitably slip through. The right priority depends on how quickly the application can be attacked after release.
👉 Read our full editorial: AI writes code faster, but application security is falling behind