AI appsec velocity is widening vulnerability and secrets risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Orca Security's research: AI has accelerated application delivery faster than security governance, leaving critical vulnerabilities, stale systems, and exposed AI credentials in production.

Why it matters: This matters to IAM and security teams because the same velocity gap now affects code review, secrets governance, dependency control, and runtime visibility across application and non-human identity programmes.

By the numbers:

• 78% of organisations are running production applications with critical vulnerabilities.
• Nearly 50% still have Log4Shell-exposed systems.
• 43% of organisations have exposed AI/ML credentials like API keys and tokens.
• Over 77% of organisations have unpatched high or critical vulnerabilities after 90 days of discovery.

Context

AI appsec velocity is the core governance problem here. When code moves from prompt to production faster than review, approval, and remediation processes can keep up, security teams lose the ability to enforce the controls they assumed were already in place.

Orca Security’s report treats AI as an accelerant, not the root cause. The deeper issue is that many organisations were already inconsistent on code review, patching, secrets handling, and dependency control, and faster delivery has exposed how thin those guardrails really were.

For identity programmes, the relevance is immediate: exposed AI credentials, autonomous build pipelines, and third-party dependencies all create non-human access paths that behave like identity risks even when they start as application issues.

Key questions

Q: What should teams do first when AI-assisted delivery is outrunning code review?

A: Start by restoring non-negotiable approval gates on the path to production. If AI-generated or AI-assisted code can bypass branch protection, code review, or CI/CD checks, the problem is governance timing, not developer speed. The first move is to make those controls mandatory again before you try to optimise anything else.

Q: Why do vulnerability findings often remain open for weeks after discovery?

A: Vulnerability findings linger when security and development operate as separate groups with different incentives and weak feedback loops. Static reports, unclear prioritisation, and poor communication make remediation feel burdensome rather than actionable. Skills shortages also add pressure, because teams are already stretched across many tools and languages. The result is delay, even when the issue is known and the fix is available.

Q: How should security teams handle exposed secrets in AI-driven environments?

A: Security teams should treat exposed secrets as active access paths and respond as though misuse can begin immediately. The right sequence is to identify the owning NHI, revoke the credential everywhere it is trusted, check downstream dependencies, and then validate whether the secret was copied into collaboration or CI systems.

Q: What happens when a malicious package lands in a trusted build path?

A: Its impact can spread far beyond the initial component. If the package is executed in CI/CD, a base image, or an IaC module, the attacker benefits from the organisation’s own replication machinery and can turn one compromise into repeated exposure across many deployments.

Technical breakdown

Why critical vulnerabilities stay open after discovery

Discovery does not equal remediation. In modern application estates, a vulnerable component may sit inside a container image, IaC template, library chain, or service dependency graph, so fixing it requires understanding what else depends on it. That dependency uncertainty creates delay, especially when teams lack documented remediation playbooks or the original engineers have moved on. The result is a long tail of known issues that remain open because the organisation can see them but cannot confidently change them. Practical implication: treat dependency mapping and remediation context as part of vulnerability management, not a separate task.

Practical implication: Build remediation around dependency context so known vulnerabilities can be fixed without creating avoidable outage risk.

Why AI credentials need separate secrets governance

AI API keys, inference tokens, and model-hosting credentials are not ordinary secrets. They often unlock proprietary models, training data, and usage-based services, which means misuse can lead to data exfiltration, service abuse, and billing impact without the patterns that conventional database-credential monitoring expects. Many secrets detection programmes were built around cloud keys and databases, so they miss the different blast radius of AI credentials. Practical implication: inventory AI-related secrets as a distinct class and govern them with explicit detection, rotation, and revocation paths.

Practical implication: Separate AI tokens from generic secrets so exposure triggers the right monitoring and revocation workflow.

How malicious packages amplify blast radius in AppSec

A malicious package becomes dangerous when it lands in a high-trust execution path such as CI/CD, a base image, or an IaC module that gets replicated widely. At that point the compromise is no longer local to one application component. It is a distribution problem, because the attacker inherits the organisation’s own replication and deployment machinery. The article also notes that attackers exploit trust signals such as popularity and apparent legitimacy. Practical implication: package trust has to be operationally monitored, not assumed from repository reputation or download counts alone.

Practical implication: Review where third-party code executes, not just whether it is approved, because placement determines blast radius.

Threat narrative

Attacker objective: To turn one weak trust point in the application pipeline into broad access, operational disruption, and expensive cleanup across the environment.

1. Entry occurs when exposed AI credentials, unreviewed code, or a malicious package enters the production path through rapid delivery workflows.
2. Credential access or misuse follows when AI API keys, tokens, or other secrets are used to reach model services or surrounding infrastructure.
3. Escalation happens as the compromise propagates through dependencies, CI/CD, or replicated artefacts, widening the affected surface beyond the initial component.
4. Impact is realised through data exposure, model abuse, unexpected billing, or large-scale remediation debt across the application estate.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Velocity, not AI, is the governing variable now: this article shows that the control problem is no longer whether organisations understand AppSec hygiene, but whether their delivery speed has outgrown the governance cadence that makes hygiene enforceable. Branch protection, code review, and CI/CD gating only work when they are actually present in the path to production. The practitioner conclusion is that speed has become a control design constraint, not merely an operational preference.

AI credentials create a distinct secrets class: AI API keys and inference tokens have a different business and technical blast radius from database credentials, because they can expose models, training data, and usage-based services in one move. That makes generic secrets programmes too blunt for the current environment. The practitioner conclusion is that secrets governance now needs identity-by-purpose, not just identity-by-store.

Standing hygiene assumptions are collapsing under fast delivery: code review is designed for a world where changes pause long enough to be inspected. That assumption fails when AI-assisted pipelines can reach production before meaningful human review or branch enforcement occurs. The implication is not simply that teams need more controls, but that their current control timing model no longer matches how software is moving.

Identity blast radius now extends through software supply chains: a malicious package, base image, or IaC module can become an identity problem once it carries secrets or lands in a trusted execution path. This is where application risk and NHI risk converge, because one compromised artifact can create many downstream access events. The practitioner conclusion is that blast-radius analysis should sit beside vulnerability triage.

Runtime context is the new control separator: the teams that reduce risk are not the ones with more alerts, but the ones that can tell which issues are reachable, which secrets matter, and which dependencies will break if changed. That is a governance capability, not a tooling feature. The practitioner conclusion is that AppSec maturity now depends on contextual decision-making as much as detection volume.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Ephemeral governance is now the point of failure: security programmes built around periodic review assume the thing being reviewed persists long enough to matter. AI-assisted delivery shortens that window, so the control problem shifts toward issuance-time enforcement and runtime visibility rather than after-the-fact inspection.

Secrets sprawl and AppSec sprawl are converging: exposed AI tokens, vulnerable dependencies, and malicious packages are no longer separate categories of risk. They now collapse into the same operational question, namely whether the organisation can see and govern the non-human access paths created by modern delivery systems.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That gap explains why teams struggle to connect application findings to identity governance in time to matter.

For practitioners

• Enforce code-review and branch-protection gates Require human approval before production promotion, including for AI-assisted changes and automated pull requests. Treat bypassable review as a governance failure, not a workflow shortcut.
• Classify AI credentials as a distinct secret tier Separate model-hosting keys, inference tokens, and ML platform credentials from standard cloud secrets so detection, rotation, and revocation can be tuned to their specific blast radius.
• Map dependency blast radius before remediation Document which services, containers, and IaC modules depend on each vulnerable component before fixing it, so patching does not become a blind break-fix exercise.
• Track malicious package exposure in execution paths Review where third-party packages are executed inside CI/CD, base images, and build artefacts, then prioritise the paths that can replicate compromise across many workloads.
• Use runtime visibility to prioritise what is actually reachable Tie vulnerability triage to live production context so teams can distinguish theoretical issues from defects that are currently exposed to abuse.

Key takeaways

• The article shows that AppSec risk is being amplified by delivery velocity, not by AI alone.
• Exposed AI credentials, stale vulnerabilities, and malicious packages all widen blast radius when governance gates are weak.
• The practical response is to restore review, improve dependency context, and govern AI secrets as a distinct access class.

Key terms

• AI Credential: A credential used by an AI service, model, or pipeline to access data, tools, or billing systems. In practice, it functions like a privileged machine secret and should be governed with ownership, scope, rotation, and revocation controls rather than treated as ordinary configuration.
• Secrets detection: Secrets detection is the identification of credentials such as API keys, tokens, certificates, and passwords in code, configuration files, or pipelines. In mature programmes, detection is paired with rotation, revocation, and ownership so exposed secrets do not remain usable.
• Dependency blast radius: Dependency blast radius is the amount of service impact created when a lower-level component fails. In identity-aware systems, it describes how far a resolver, proxy library, or sidecar defect can propagate before it disrupts authentication, authorisation, or session continuity.
• Approval Gate: An approval gate is the human or policy checkpoint that must be crossed before an AI system can take a state-changing action. For identity governance, the gate is the point where responsibility stays with the organisation, and it should be enforced separately from the system’s ability to observe or recommend.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.