AI appsec velocity is widening vulnerability and secrets risk

At a glance

What this is: Orca Security’s 2026 appsec findings show that development velocity, unresolved vulnerabilities, and AI credential exposure are outpacing existing security controls.

Why it matters: For IAM and security teams, the implication is that secrets governance, access review, and remediation workflows must now account for faster-moving application and AI workloads.

By the numbers:

• 78% of organizations are running production applications with critical vulnerabilities.
• Over 77% of organizations have unpatched high or critical vulnerabilities after 90 days of discovery.
• 43% of organizations have exposed AI/ML credentials like API keys and tokens for model hosting, inference APIs, and ML platforms.
• 11% of organizations are running publicly known malicious packages in production.

👉 Read Orca Security's 2026 State of Application Security Report

Context

AI appsec risk now turns less on whether organisations can find vulnerabilities and more on whether they can act before modern development velocity turns findings into exposure. The primary issue is application security governance, with secrets management and AI credentials becoming part of the same control problem.

Orca Security’s analysis argues that the old problem set has not changed, but the operating tempo has. For IAM, NHI, and security leaders, that means code review, dependency trust, and secrets handling all need to survive a faster path from developer intent to production state.

When security processes are still calibrated to slower release cycles, the result is predictable: vulnerabilities remain open, exposed credentials linger, and third-party dependencies slip into production before anyone can make a risk-based decision.

Key questions

Q: How should security teams handle AI credentials in secrets management programmes?

A: Treat AI credentials as a separate high-risk secret class, not as a generic API key. They often control access to model hosting, inference services, and sensitive training data, so exposure can create data loss, cost shock, or model abuse. Security teams should inventory them separately, monitor usage patterns, and assign tighter access and rotation controls.

Q: Why do critical vulnerabilities remain open for so long in modern appsec programmes?

A: They stay open because remediation is harder than detection in modular environments. Teams often lack complete dependency context, fear breaking load-bearing services, and do not have documented rollback playbooks. The result is deferral, not ignorance. Mature programmes reduce this by linking each finding to owners, dependencies, and business impact before deciding what to fix first.

Q: What breaks when supply-chain trust is based mainly on package popularity?

A: Popularity signals can be manipulated, and they do not prove package integrity or safe behaviour. A malicious dependency only needs to land in a CI/CD pipeline, base image, or reusable module to create wide blast radius. Security teams should verify provenance, inspect execution paths, and treat third-party trust as an ongoing control, not a one-time review.

Q: Which controls matter most when development velocity outpaces security review?

A: The most important controls are enforced review gates, dependency awareness, and contextual prioritisation. Without them, security teams receive alerts faster than they can decide what matters. The practical goal is to stop changes from bypassing review, understand what each change depends on, and fix the issues that most increase real exposure.

Technical breakdown

Why application velocity breaks vulnerability remediation

Modern application stacks are modular, with third-party packages, containers, and infrastructure-as-code templates creating layered dependency chains. That complexity makes remediation non-trivial because a single patch can affect multiple services and hidden dependencies. The security challenge is not detection. It is determining what is load-bearing, what is safe to change, and what needs documented rollback logic before the fix is applied. In fast-moving development environments, that context is often incomplete, so teams defer rather than repair.

Practical implication: map dependency relationships before remediation so critical fixes do not stall on uncertainty.

Why AI credentials expand the secrets management problem

AI/ML credentials are not just another secret type. API keys for model hosting, inference endpoints, and ML platforms can unlock model access, sensitive data, and usage-based services that traditional secrets controls were not tuned to monitor. A leaked AI key can create data exposure, model abuse, or cost shock without triggering the same alerts used for conventional cloud credentials. That makes AI credential inventory and monitoring a separate control concern, not a minor extension of existing secrets hygiene.

Practical implication: classify AI credentials separately in secrets programmes and treat them as high-impact access tokens.

How malicious packages create blast-radius problems

Supply-chain compromise becomes dangerous when a malicious package lands inside a CI/CD pipeline, a reusable base image, or an IaC module that gets replicated across environments. At that point, the attack is no longer limited to one developer workstation or one repository. It becomes a distribution problem, where trusted build paths propagate malicious code faster than human review can catch it. The governance failure is over-trusting package metadata, popularity signals, and provenance assumptions that attackers can manipulate.

Practical implication: add provenance checks and runtime trust gates to build pipelines before packages reach production.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed secret, vulnerable service, or malicious dependency into broad operational access and measurable business impact.

1. Entry occurs when exposed AI/ML credentials, vulnerable applications, or malicious packages provide a path into production workflows.
2. Escalation follows when credentials unlock model hosting, inference services, or replicated build paths, widening the attacker’s reach across environments.
3. Impact lands in the form of data exposure, service abuse, unexpected billing, or broad environment compromise through supply-chain propagation.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Velocity, not AI, is the governance variable that changed the AppSec equation. The article’s core finding is that development speed now outruns the control points security teams built for slower release cycles. Code review, branch protection, and CI/CD approval gates only work when they still exist in practice. The implication is that programme design has to assume compressed decision windows, not stable remediation cadences.

AI credentials are not just more secrets, they are a different trust class. API keys for model hosting and inference services can expose data, models, and spend in ways that classic cloud credentials do not. Existing secrets programmes often treat all secrets as interchangeable, which is the wrong abstraction for AI-enabled environments. Practitioners need to re-segment credential governance by blast radius and service effect, not by storage location.

Secret sprawl challenge: the real failure mode is not simply leaked credentials, but fragmented control across build, runtime, and developer workflows. Once secrets detection was designed for a narrower application stack, it no longer matches the number of places secrets can now appear or move. Teams that do not centralise discovery and remediation will keep producing alerts without reducing exposure.

Supply-chain trust is now an operational control, not a procurement assumption. Malicious packages do not need broad adoption to be effective if they enter the right pipeline or base image. That means star counts, package popularity, and publisher reputation cannot be treated as sufficient trust signals. The implication is that third-party code governance has to be evaluated as a continuous runtime discipline, not a periodic audit.

The security teams that reduce risk are the ones that can connect context to action. The report’s separation between visibility and actual risk reduction is important. Context about exploitability, ownership, and business criticality determines whether a finding gets fixed or deferred. Practitioners should treat contextual prioritisation as the control that turns appsec telemetry into outcomes.

From our research:

• 43% of organisations have exposed AI/ML credentials like API keys and tokens for model hosting, inference APIs, and ML platforms, according to The State of Secrets in AppSec.
• Our research also found that the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
• That gap between confidence and control is why the Guide to the Secret Sprawl Challenge is the right next resource for teams trying to reduce secret exposure at scale.

What this signals

Secret sprawl challenge: application security teams are now dealing with a control problem that spans code, build systems, and runtime identities. When secrets, AI credentials, and dependencies move faster than review cycles, the programme shifts from prevention to reactive cleanup unless ownership and remediation paths are explicit.

The practical signal for IAM and security leaders is that secrets governance can no longer sit apart from appsec and cloud runtime control. Teams should expect more pressure to connect build-time findings to access scope, credential lifecycle, and production risk in one workflow.

The relevant external baseline is the OWASP Non-Human Identity Top 10, because exposed machine credentials and over-trusted build paths now behave like a single governance problem rather than separate silos.

For practitioners

• Enforce code review gates on production-bound changes Block direct paths from prompt to production by requiring review, branch protection, and approval for changes that can reach live environments.
• Separate AI credentials from standard secret classes Inventory API keys, tokens, and platform credentials used for model hosting and inference as a distinct category with tighter monitoring and access limits.
• Document remediation playbooks for modular application stacks Capture rollback steps, dependency owners, and service-impact checks so high-risk fixes do not get deferred because teams fear breaking something else.
• Add provenance checks to build and packaging pipelines Verify the origin and integrity of packages, base images, and IaC modules before they are replicated into production workflows.
• Prioritise context-rich risk scoring over raw alert volume Use reachability, exploitability, and business criticality together so security teams can focus on fixes that materially reduce exposure.

Key takeaways

• AI did not create the appsec problem, but it did accelerate the path from weak control to production exposure.
• AI/ML credential exposure should be treated as a distinct secrets-governance issue because the impact profile is broader than conventional API key leakage.
• Security teams reduce risk when they combine review gates, dependency context, and credential governance instead of relying on alert volume alone.

Key terms

• AI Credential: A credential used to authenticate access to AI services, model hosting, inference endpoints, or machine learning platforms. In practice, it behaves like a high-value secret because exposure can unlock data, model abuse, and service costs, not just routine account access.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, pipelines, environments, and developer tooling. It becomes a governance problem when no single team can reliably discover, classify, rotate, and revoke the secrets that still have active access.
• Blast Radius: Blast radius is the amount of damage a compromised credential, dependency, or package can cause once trusted by production systems. In appsec, it helps teams decide whether a finding is a local issue or a platform-level exposure that needs immediate containment.
• Contextual Prioritisation: Contextual prioritisation is the practice of ranking security work by reachability, business criticality, ownership, and exploitability rather than alert volume alone. It matters because modern application environments generate more findings than teams can fix without a decision framework.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Orca Security: the 2026 State of Application Security Report and webinar discussion. Read the original.