TL;DR: Application security risk is shifting in 2026 as Cycode reports that 92% of organisations are using or piloting AI coding assistants while 81% still lack full visibility into how AI is used across the SDLC, leaving AI-generated code as a major blindspot. The governance problem is no longer just insecure code, but the combination of broken access control, misconfiguration, supply chain exposure, and agent-driven execution paths that outpace traditional review models.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “Application Security Vulnerabilities to Watch out for in 2026”.
By the numbers:
- 92% of organisations are actively using or piloting AI coding assistants, according to Cycode.
- 81% of organisations lack full visibility into how AI is used across their software development lifecycle, according to Cycode.
- In the first half of 2025, the National Vulnerability Database coordinated over 23,667 CVEs, according to Cycode.
Key questions
Q: What breaks when broken access control is not enforced server-side?
A: When access control is only checked in the UI or at login, attackers can call protected APIs, change object identifiers, or invoke functions they should never reach.
A: AI generated code can accelerate delivery, but it also increases the chance that insecure patterns, vulnerable dependencies, or untrusted model outputs enter production quickly.
Q: What are the signs that security misconfiguration is slipping into production?
A: Common warning signs include open admin panels, public storage buckets, debug mode left on, verbose error pages, exposed internal ports, and CI systems that allow anonymous access.
Practitioner guidance
- Audit authorisation logic in critical applications Prioritise applications that expose administrative functions, sensitive records, or API-driven workflows, and test for IDOR, missing checks, and privilege escalation paths.
- Enforce configuration baselines across cloud-native deployments Lock down container privilege, storage exposure, and default settings before release, then continuously verify that runtime configuration still matches the approved baseline.
- Verify code provenance for AI-assisted changes Require traceability for AI-generated code, dependency changes, and build outputs so teams can distinguish human-authored logic from machine-produced additions.
Bottom line: Broken access control remains the clearest example of how application flaws become access-governance failures, not just insecure code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Broken authorisation is now the primary access-control failure mode in modern application security. The article’s own figures show why this matters: broken access control remains pervasive, and its blast radius extends from data disclosure to administrative abuse and lateral movement. For identity practitioners, the important point is that authorisation gaps in application code are now part of the access governance problem, not a separate development issue. The practical conclusion is that authorisation assurance must be treated as a control domain in its own right.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
A: They should treat the application, pipeline, and runtime as one control plane and remove standing privilege from the identities that can change code or release artefacts. The goal is to stop a flaw in one layer from becoming a full-path compromise across build, deployment, and production.
👉 Read our full editorial: Application security vulnerabilities in 2026 are widening access risk