AI credential leaks and pipeline weakness outpace app security

At a glance

What this is: This report shows that AI credential leakage, dependency exposure, and weak CI/CD governance are converging into one production risk pattern.

Why it matters: It matters because IAM, NHI, and DevOps controls now need to work together, or exposed tokens, over-privileged pipelines, and stale vulnerabilities will keep multiplying blast radius.

By the numbers:

• 41.88% of production organizations have leaked AI or ML credentials.
• 81% of organizations deploy vulnerable dependencies.
• 46.20% remain exposed to Log4Shell years after disclosure.
• 21.68% maintain overly permissive CI/CD token permissions.

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

Context

Application security is no longer just a code quality problem. When AI credentials, secrets in repositories, vulnerable dependencies, and CI/CD permissions all sit in the same production path, the governance failure is usually not one missing control but the absence of coordinated identity and lifecycle discipline across the delivery chain.

For IAM and NHI teams, the relevant question is how machine identities, tokens, and pipeline permissions are being issued, reviewed, and revoked in production workflows. The report suggests that many organisations still optimise for development speed while leaving identity-bound controls too loose to contain compromise once a single token or dependency is exposed.

Key questions

Q: How should security teams handle AI credentials in production environments?

A: Security teams should treat AI credentials as privileged non-human identities, not as ordinary application settings. That means assigning owners, restricting scope, rotating secrets automatically, and scanning repositories and pipelines for exposure. The goal is to prevent a single leaked token from unlocking models, data, billing, or downstream automation.

Q: Why do vulnerable dependencies create such a large software supply chain risk?

A: Vulnerable dependencies create large risk because build systems often trust upstream packages and then distribute that trust into many downstream environments. If a malicious or outdated package is embedded in production, the compromise can scale far beyond the original application. Provenance checks and workload mapping reduce that blast radius.

Q: What do organisations get wrong about CI/CD token governance?

A: Many organisations treat CI/CD tokens as engineering convenience rather than privileged identity. That leads to broad permissions, legacy access settings, and weak review gates that let automation alter production without enough control. Token governance should be managed as part of IAM and NHI policy, not only developer tooling.

Q: How can teams reduce the impact of exposed secrets and malicious packages?

A: Teams should combine continuous secret scanning, fast revocation, package integrity checks, and dependency inventorying across production workloads. When a secret leaks or a package is flagged, containment must happen before the credential or library can be reused in build, deployment, or runtime paths. That shortens the time attackers can exploit trust.

Technical breakdown

AI credential leaks as a non-human identity problem

AI service credentials behave like high-value non-human identities because they often unlock models, inference endpoints, training data, and usage-based billing. When those tokens land in code, logs, or misconfigured pipelines, an attacker does not need to defeat the model itself. They only need the credential that governs access to it. That makes secret hygiene, scope control, and revocation speed central to AI security. The report’s figures show that AI credential exposure is already common in production, not an edge case.

Practical implication: treat AI tokens like production NHIs, with scoped issuance, automated rotation, and repository scanning for exposed credentials.

Why vulnerable dependencies and malicious packages widen the blast radius

Modern supply chain attacks exploit trust in upstream packages and automated build paths. A single compromised dependency can cascade across many downstream environments because the build system often trusts package provenance more than runtime behaviour. The report’s references to malicious packages and long-lived vulnerable dependencies show why patching alone is insufficient when dependency governance is weak. Security teams need provenance awareness, package integrity checks, and visibility into which production workloads actually consume the risky component.

Practical implication: map dependency trust chains to production workloads so you can isolate and remove high-risk packages before they spread.

CI/CD token permissions and review controls are identity controls

CI/CD systems are often treated as engineering infrastructure, but they are also identity systems. Build tokens, repository permissions, commit signing, and code review gates determine who or what can change production software. When those controls are overly permissive, automation becomes an attack path rather than a defense layer. The report’s data on permissive token permissions, missing review requirements, and weak commit validation shows that pipeline governance is now a core IAM and NHI concern.

Practical implication: review pipeline tokens and merge controls as privileged identities, not just developer tooling settings.

Threat narrative

Attacker objective: The attacker aims to turn a single secret, dependency compromise, or pipeline weakness into broad software supply chain access and repeated downstream compromise.

1. Entry occurs through exposed AI credentials, leaked repository secrets, or compromised upstream dependencies in production software workflows.
2. Escalation follows when overly permissive CI/CD tokens, legacy repository access settings, or unpatched dependencies let the attacker move from one foothold into build and deployment paths.
3. Impact arrives as credential reuse, malicious package propagation, data exposure, code tampering, or uncontrolled cloud and model access across multiple downstream environments.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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

NHI Mgmt Group analysis

AI credentials are now production NHIs, not just application secrets. Once a token can reach a model endpoint, training data, or billing surface, it behaves like a privileged machine identity with real operational impact. The governance failure is that many security programmes still classify these credentials as ordinary app config instead of high-risk access. Practitioners should manage AI tokens under the same lifecycle discipline as other privileged NHIs.

Identity blast radius is being created upstream of the application. The report ties vulnerable dependencies, permissive pipelines, and exposed secrets into one production risk chain. That means the security boundary is no longer the running workload alone but the trust relationship between repositories, build systems, and deployment credentials. IAM and NHI teams should treat software delivery paths as privileged identity domains.

Standing pipeline privilege is the control gap behind too many modern breaches. CI/CD systems still rely on long-lived tokens, legacy access settings, and broad repo permissions that were designed for convenience, not containment. That assumption fails when automation can publish, deploy, and authenticate at machine speed. The implication is that access governance must move closer to the build path and away from periodic review alone.

Dependency trust debt is accumulating faster than remediation can clear it. More than 81% of organisations deploy vulnerable dependencies, and 46.20% remain exposed to Log4Shell years after disclosure. That combination shows a structural accountability problem, not a one-off patching failure. Security leaders should view dependency exposure as lifecycle debt that compounds across multiple release cycles.

Security maturity is lagging the pace of software automation. The report shows organisations are scaling cloud-native development and AI adoption faster than they are hardening the controls that govern secrets, tokens, and package trust. That mismatch is now a board-level risk because one exposed token or one compromised dependency can cascade widely. Practitioners need governance models that match software speed.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Track the lifecycle gap: Review how 52 NHI Breaches Analysis links exposed secrets and weak offboarding to repeat compromise.

What this signals

Secret sprawl is now a governance signal, not just a hygiene issue. When AI tokens, repository secrets, and pipeline credentials are leaking in the same production estate, the real risk is that identity controls are fragmented across teams that do not share the same lifecycle model. Organisations that still review these controls separately will continue to miss the combined blast radius of one exposed credential and one permissive build path.

Dependency trust debt: The combination of vulnerable packages and slow remediation creates a backlog that behaves like hidden access exposure. Security teams should expect that package provenance, token scope, and deployment permissions will increasingly be assessed together in audit and incident response. The practical implication is that application security and IAM programme owners need a shared operating model, not just shared dashboards.

Orca’s data fits a wider pattern already visible in NHI governance: identity confidence is materially lower for machine identities than for human ones. That is why practitioners should align secrets management, workload identity, and CI/CD access reviews into one control plane rather than preserve separate governance silos.

For practitioners

• Classify AI credentials as privileged NHIs Put model tokens, inference keys, and billing credentials into the same inventory and access review process used for other production machine identities. Apply scope limits, owner assignment, and automated expiry so these secrets are not treated as ordinary application settings.
• Harden CI/CD identity before tightening application code Review build tokens, repository permissions, and merge gates as privileged access paths. Remove legacy token settings, require signed commits where practical, and ensure every deployment credential has an accountable owner and a short renewal path.
• Reduce trust in upstream packages Track which production workloads depend on high-risk libraries and monitor for malicious package activity, especially in ecosystems with fast-moving release cycles. Where possible, pin provenance and isolate build paths that can introduce unvetted dependencies.
• Scan repositories for exposed secrets continuously Use automated scanning across source control, pipelines, and artefact stores to detect AI tokens, cloud keys, and other production secrets before they are reused. Couple detection with rapid revocation so an exposed credential does not become a standing access path.

Key takeaways

• AI credential leaks, vulnerable dependencies, and permissive CI/CD controls now form one connected production attack surface.
• The scale is already material, with 41.88% of production organisations leaking AI or ML credentials and 46.20% still exposed to Log4Shell.
• Security teams should govern pipeline tokens, secrets, and dependency trust as privileged identity problems, not isolated engineering issues.

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.
• Software Supply Chain: The set of dependencies, build systems, repositories, and deployment paths that turn source code into running software. In security terms, it is an identity and trust chain because each stage can inherit permissions, secrets, and provenance from the one before it.
• CI/CD Token: A machine credential used by build or deployment automation to authenticate, publish, or modify software artefacts. Because it can change code, infrastructure, or releases at scale, it should be managed as a privileged non-human identity with tight scope and frequent review.
• Dependency Provenance: Evidence showing where a package came from, who produced it, and whether it has been altered before use. Provenance helps security teams decide whether a dependency can be trusted in production, especially when malicious packages or rapid release cycles increase supply chain risk.

Deepen your knowledge

NHI governance, machine identity security, and workload identity lifecycle 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 maturing governance in your organisation, it is worth exploring.

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