AI/ML credentials expose a new AppSec blind spot in production

At a glance

What this is: This report shows that production AppSec risk is increasingly driven by exposed AI/ML credentials, long-lived vulnerabilities, and secrets that remain active across repositories and delivery workflows.

Why it matters: For IAM, PAM, and NHI practitioners, the takeaway is that application security and identity governance now overlap at the credential layer, where exposure creates immediate authenticated access paths.

By the numbers:

• 43% of organisations have exposed AI or machine learning credentials, according to Orca Security.
• 77% of organisations retain high or critical container vulnerabilities for more than 90 days, according to Orca Security.
• 31% of organisations expose valid secrets in source code, according to Orca Security.
• 30% of organisations retain recoverable secrets in Git history, according to Orca Security.

Context

Application security is no longer just about finding flaws in code. In modern delivery environments, exposed AI/ML credentials, embedded secrets, and vulnerable dependencies all become identity and access problems as soon as they reach production.

Orca Security’s report argues that traditional AppSec workflows are missing the operational context needed to decide what is actually exploitable. The practical issue is not only detection, but whether credentials, containers, and supply chain artefacts can be governed before they create a usable access path.

That makes the boundary between AppSec and identity management much thinner than many programmes assume. Secrets, tokens, and model-access credentials now behave like high-value non-human identities that must be inventoried, scoped, and retired with the same discipline as any other privileged asset.

Key questions

Q: What breaks when AI/ML credentials are exposed in production?

A: The failure is immediate authenticated access. If a model token, inference API key, or MLOps credential is exposed, an attacker may not need exploitation at all. They can often use the credential directly, which turns a code issue into an access-control problem with real operational and financial impact.

Q: Why do exposed secrets keep creating risk after they are detected?

A: Because detection does not stop a credential from remaining valid, and exposed values often persist in repositories, logs, backups, and configuration files. Risk remains until revocation, cleanup, and dependency removal are complete, which is why exposed secrets are really lifecycle failures rather than alerting failures.

Q: What are the signs that an AppSec program is failing to support remediation?

A: Common signs include excessive false positives, low-risk findings drowning out critical issues, slow release cycles, and developers working around security tools. Another warning sign is poor context, where teams cannot tell whether a vulnerability is exploitable or relevant to sensitive data. When findings are not tied to business impact, remediation becomes slow, inconsistent, and easy to deprioritise.

Q: Should teams treat AI-related credentials differently from ordinary application secrets?

A: Yes. AI-related credentials often sit in rapidly changing pipelines, tool connections, and agent workflows, so ownership and scope can be unclear. Teams should give them separate inventory, tighter scope, and faster rotation than legacy application secrets.

Technical breakdown

Why exposed AI/ML credentials are an identity problem

AI and machine learning credentials are not just application secrets. They often authenticate to model hosting services, inference APIs, and MLOps platforms, which means compromise can produce immediate access to proprietary models, sensitive data, or compute-backed services. In practice, these credentials behave like non-human identities because they grant machine-to-machine access outside a human login flow. Once exposed in code, logs, or workflow files, the credential itself becomes the control point, not the application that used it. That changes the governance question from code hygiene to access authority, lifecycle ownership, and revocation speed.

Practical implication: Treat AI/ML credentials as governed NHI assets with ownership, rotation, and revocation controls.

Why vulnerability backlogs become an access problem in production

The report’s remediation gap shows a common failure mode in AppSec: teams may know a vulnerability exists, but without production context they cannot judge exposure severity quickly enough. High or critical flaws that persist for more than 90 days turn from findings into stable attack surface. When these issues sit in containers or runtime dependencies, they can intersect with exposed credentials, permissive IAM roles, or cloud workloads that attackers can reach directly. The mechanism is not just delay. It is the conversion of known weakness into sustained operational exposure.

Practical implication: Prioritise remediation using runtime context, not scan severity alone.

How secrets in source and Git history create persistent compromise paths

Secrets embedded in source code or preserved in Git history are dangerous because removal from the visible codebase does not equal removal from the environment. If a token, API key, or certificate remains valid after exposure, the attacker does not need to break authentication. They inherit it. That is why secrets detection must be paired with revocation, not treated as a discovery-only control. In cloud and CI/CD environments, the persistence of an old secret creates a standing entry path long after the original commit has shipped.

Practical implication: Pair secret discovery with immediate token invalidation and history-aware cleanup.

Threat narrative

Attacker objective: The attacker wants authenticated access to AI services and cloud-backed resources using credentials that were never meant to be publicly reachable.

1. Entry occurs when valid AI/ML credentials or other secrets are exposed in source code, Git history, or CI/CD workflows.
2. Credential access is achieved without exploitation because the leaked token or key already authenticates to model services or internal systems.
3. Escalation follows when the credential grants access to proprietary datasets, inference APIs, or cloud services that can be abused at scale.
4. Impact is realised through intellectual property theft, model manipulation, or GPU abuse that consumes resources and exposes data.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.

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

AI/ML credentials are now NHI assets, not just application secrets. Once a token or API key authenticates to a model, inference, or MLOps platform, it functions as a machine identity with direct operational power. That means the old split between AppSec and identity governance is no longer defensible. Programmes need to manage these credentials as governed identities with ownership, scope, and revocation, because the access they confer is already production-grade.

Ephemeral application code does not reduce the blast radius of a persistent credential. The report’s 43% exposure figure matters because the exposure point is not the only problem. What matters is how long the credential stays valid and where it can be used. That creates identity blast radius, not just code risk, and it is the blast radius that determines whether a leak becomes an incident.

Development velocity is outpacing governance when remediation takes longer than exposure discovery. The article shows a recurring pattern: organisations can find issues, but they cannot clear them fast enough to matter operationally. That is a control-plane failure, not a tooling gap. The implication is that AppSec must be judged on revocation speed, runtime containment, and lifecycle control rather than backlog size alone.

Secret sprawl is now the practical meeting point between AppSec, CNAPP, and NHI governance. Secrets in code, recoverable Git history, and workflow files behave like dispersed access artefacts whose ownership is often unclear. That is exactly the kind of environment where governance breaks down across teams. Practitioners should expect identity, pipeline, and runtime controls to converge around the same artefacts, because the exposure path is already shared.

Production context is the missing decision layer in modern vulnerability management. A vulnerability becomes material when it intersects with a reachable workload, a usable credential, or a trusted automation path. Without that context, remediation becomes triage theatre. The field needs risk decisions that reflect actual reachability and credential validity, not isolated scan results.

From our research library:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• Read next: Secrets Management Guide

What this signals

AI credential governance now sits inside the AppSec remit. When tokens for model hosting, inference APIs, and MLOps platforms leak into production systems, the issue is no longer just code exposure. It becomes credential lifecycle control, with ownership, validity, and revocation determining whether a leak can be weaponised.

Production context will separate actionable risk from noisy findings. The teams that reduce exposure fastest will be the ones that decide based on reachability and credential validity, not on severity labels alone. That means the same vulnerability can be urgent in one workload and tolerable in another.

Secret sprawl is a control-plane problem, not a detection problem. Once secrets spread across repositories, Git history, and deployment workflows, discovery alone does not change the attack surface. The programme has to move from finding exposures to removing their authentication value before an attacker does.

For practitioners

• Prioritise exposed AI/ML credentials Inventory tokens for model hosting, inference APIs, and MLOps platforms, then revoke anything exposed in source, logs, or workflow files before it can be reused.
• Bind remediation to runtime context Rank vulnerabilities by whether they sit in reachable containers, production pipelines, or internet-facing services instead of treating every critical finding as equal.
• Treat Git history as an exposure source Search commit history for recoverable secrets, rotate any credential that may have been committed, and assume deletion from the working tree is not enough.
• Harden CI/CD token permissions Restrict pipeline tokens to the narrowest possible scopes so a leaked automation credential cannot authenticate beyond the build or deployment task it was meant for.
• Adopt ephemeral credentials for deployment paths Replace standing pipeline and workload secrets with short-lived credentials where the task can be completed without persistent reuse.

Key takeaways

• AI/ML credentials now create a direct identity and access exposure in production, not just a code-quality issue.
• The report shows that delayed remediation and recoverable secrets keep attack paths alive long after discovery.
• The control that matters most is fast revocation tied to production context, not scan results in isolation.

Key terms

• Ai/ml credential: A credential that lets software authenticate to AI or machine-learning services without a human in the loop. In practice, this includes tokens, keys, and service secrets used for model hosting, inference, or MLOps platforms, where exposure can create direct access to sensitive workloads and usage spend.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Production Context: Production context is the operational information that shows how a workload behaves in a live environment. It includes runtime state, exposure reachability, and control effectiveness. Security teams use it to distinguish real business risk from issues that appear serious in scanning but cannot actually be exploited.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.