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.
At a glance
What this is: Cycode says 2026 application risk is being widened by AI-generated code, broken access control, misconfiguration, supply chain compromise, and faster exploitation of disclosed weaknesses.
Why it matters: IAM, PAM, NHI, and application security teams need to treat code, deployment, and authorization failures as one governance problem because access abuse now starts earlier and propagates faster.
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.
- Broken access control affected 100% of applications tested in the OWASP Top 10 2025 release, according to Cycode.
- In the first half of 2025, the National Vulnerability Database coordinated over 23,667 CVEs, according to Cycode.
Context
Application security risk is no longer confined to insecure code in isolation. The article ties together broken access control, misconfiguration, supply chain compromise, and AI-generated code, showing how modern SDLCs now create overlapping failure modes that defeat point-in-time review.
For identity and access governance, the practical issue is that application flaws increasingly become access-control failures, not just code defects. When authorisation logic, deployment trust, and AI-assisted development all drift at once, IAM, PAM, and NHI controls have to be considered earlier in the software lifecycle.
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. The result is often horizontal or vertical privilege abuse, where authenticated users act outside their intended scope. Server-side authorization must enforce both who the user is and what that user may do.
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. Open source models add provenance and integrity risk when teams cannot verify their origin or training data. That makes software supply chain controls, policy enforcement, and review discipline more important, not less, in modern AppSec programs.
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. These issues often appear as working systems that are simply too permissive. If configuration drift or unreviewed defaults keep surfacing, the environment is likely drifting outside its intended security boundary.
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.
Technical breakdown
Broken access control and unauthorised execution paths
Broken access control means an application lets a user or system reach data or functions it should never be able to use. In modern systems this often shows up as missing authorisation checks, insecure direct object references, or privilege escalation in APIs and workflows. Because access decisions are enforced in code, a single mistake can expose records, trigger administrative functions, or permit lateral movement inside connected environments. The article’s 100% prevalence point shows this is not a corner-case defect but a structural one. In practice, access control failures are now part of application architecture, not just authentication.
Practical implication: teams need to test authorisation logic as a release gate, not rely on post-deployment reviews.
Security misconfiguration in cloud-native applications
Security misconfiguration is what happens when platforms, containers, storage, or services are deployed with insecure defaults, excessive privileges, or exposed interfaces. Cloud-native systems multiply the problem because each microservice, API, and runtime layer adds new settings that can drift independently. Common failure points include public storage, default credentials, verbose error messages, and containers running with too much privilege. The article’s emphasis is that misconfiguration now sits beside broken access control as a top enterprise risk because modern deployment complexity creates more ways for access to be granted accidentally than intentionally.
Practical implication: configuration baselines and runtime guardrails must be enforced continuously across build and deployment stages.
AI-generated code and software supply chain compromise
AI-generated code creates a new trust problem because code can appear functional while still embedding insecure patterns. That risk is amplified when AI assistants are used widely but the organisation cannot see where, how, or by whom they are used across the SDLC. Software supply chain compromise extends the same issue into dependencies, build systems, and distribution pipelines, where attackers can tamper with trusted components and gain downstream reach. Together, these trends mean code provenance, authorisation logic, and pipeline integrity now intersect in ways that traditional code review does not reliably catch.
Practical implication: teams should verify code provenance and pipeline integrity before they trust AI-assisted changes in production.
Threat narrative
Attacker objective: The attacker’s objective is to turn application trust failures into broader unauthorised access, data theft, or control over production and development environments.
- Entry begins when attackers exploit broken access control, insecure defaults, or compromised third-party components in the application and delivery pipeline.
- Credential or privilege abuse follows when the flaw exposes administrative functions, privileged container access, or authentication tokens that should not be reachable.
- Escalation occurs as malicious code, misconfigurations, or supply chain tampering expands access across connected services and development environments.
- Impact is unauthorised data access, lateral movement, financial fraud, or broader compromise of production systems and release pipelines.
Breaches seen in the wild
- ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group 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.
AI-generated code has created governance debt, not just code debt. Cycode’s data shows organisations are adopting AI coding assistants faster than they can observe or govern their use, which means insecure patterns can enter software at scale before security teams see them. That matters because the risk is not only vulnerable syntax but the loss of provenance over who or what produced the code. The practitioner conclusion is to control the use of AI in the SDLC as a governance issue, not a productivity choice.
Supply chain trust is shifting from dependency management to execution-path assurance. The article connects compromised libraries, build pipeline attacks, and leaked credentials to a broader pattern where trusted software paths become attack paths. That is also where NHI governance matters: build systems, CI runners, tokens, and service identities are often the mechanism of compromise. The practical conclusion is to govern the identities that can change software, not only the software itself.
Cloud-native misconfiguration and agentic execution are converging into the same risk model. The article shows that excessive privileges, exposed environments, and autonomous execution paths all widen the attack surface when systems can act, deploy, or call APIs without tight constraints. That means security teams need one governance view across code, pipeline, runtime, and machine identity. The practical conclusion is to align application security, cloud security, and NHI controls around access boundaries, not tooling silos.
From our research library:
- 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.
- Read next: Agentic AI Security Guide
What this signals
AI code governance debt: when organisations adopt coding assistants faster than they can inventory where AI is used, security review shifts from the application layer to the provenance layer. That is the real operational gap: teams cannot reliably secure code they cannot distinguish, trace, or attribute across the SDLC.
The next control boundary is not only scanning more code, but governing the identities and pipelines that produce it. IAM, NHI, and application security teams should treat build credentials, CI runners, and deployment permissions as part of the same assurance model, because that is where compromised trust becomes production impact.
For practitioners
- 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.
- Protect build and CI identities Treat pipeline tokens, runner identities, and deployment credentials as high-value access paths and remove standing privilege wherever they can modify code or release artefacts.
Key takeaways
- Broken access control remains the clearest example of how application flaws become access-governance failures, not just insecure code.
- AI-assisted development expands the attack surface when visibility into SDLC usage is limited and provenance is unclear.
- The most effective control response is to govern code provenance, deployment privilege, and authorisation logic as a connected system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Broken access control is the article's central application risk and maps directly to authorisation requirements. |
| V13 — Configuration | Security misconfiguration is a major theme in the article's cloud-native risk discussion. | |
| Recommendation — Apply V8 to verify every sensitive function has explicit, testable authorisation checks. Use V13 to enforce secure configuration baselines across application and deployment layers. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article links access-control flaws to unauthorised access and broader movement through systems. |
| Recommendation — Map application abuse paths to TA0006 and TA0008 to prioritise controls that stop escalation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about weak permissions and missing authorisation in software systems. |
| Recommendation — Use PR.AA-05 to govern application permissions and reduce overreach in sensitive workflows. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Excessive access in applications, containers, and deployment paths is a recurring risk in the article. |
| Recommendation — Apply AC-6 to reduce privileges across application, pipeline, and runtime identities. | ||
Key terms
- Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
- Security Misconfiguration: Security misconfiguration is a control failure caused by unsafe defaults, incorrect settings, or overly broad permissions in systems and pipelines. In NHI environments, it often shows up as exposed secrets, persistent roles, or permissive cloud templates. The risk is that routine automation becomes a durable access path.
- Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
- AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the software and deployment paths that now carry production risk.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org