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

At a glance

What this is: This is Orca Security’s 2026 application security research, and its key finding is that exposed AI/ML credentials, long-lived vulnerabilities, and secrets in code are now routine production risks.

Why it matters: It matters because the same identity controls that govern NHI, autonomous systems, and human delivery workflows now determine whether modern software pipelines leak access or contain it.

By the numbers:

• 43% have exposed AI/ML credentials
• 78% of organizations run packages with critical vulnerabilities in production
• 31% expose valid secrets in source code and 30% retain them in Git history

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

Context

AI/ML credentials are non-human identities in practice: they are tokens, keys, and service credentials that let software call models, inference APIs, and MLOps platforms. When those credentials are exposed, the problem is not just data leakage. It is direct authenticated access to production systems, usage charges, and model-integrity risk.

The broader issue is that application security tooling often treats code, infrastructure, and identity as separate control planes. Orca Security’s report shows why that split no longer holds. Secrets in repositories, privileged pipeline tokens, and permissive infrastructure-as-code all create durable access paths that standard backlog-driven remediation does not close quickly enough.

Key questions

Q: How should security teams handle exposed AI/ML credentials in production pipelines?

A: Treat them as active non-human identities, not simple code artefacts. Revoke the credential, search for copies in Git history, build logs, and forks, and validate whether the token had access to models, storage, or cloud APIs. If the credential was shared across systems, assume the blast radius extends beyond the original repository.

Q: Why do secrets in source code remain a persistent security risk after removal?

A: Because removal from the file does not guarantee removal from every place it was replicated. Commit history, caches, logs, clones, and CI/CD artefacts can keep the secret recoverable and valid. The risk is persistent authenticated access, not just visible exposure in the original codebase.

Q: What breaks when infrastructure as code embeds overly permissive IAM roles?

A: The same bad entitlement can be deployed repeatedly across environments, which turns one mistake into a scalable access problem. Instead of a single misconfigured resource, teams inherit many copies of the same privilege excess. That makes containment slower and remediation more expensive.

Q: Should organisations prioritise secrets rotation or runtime monitoring first?

A: Rotation comes first when a secret is exposed, because the access path is already live. Runtime monitoring still matters, but it does not remove authenticated access by itself. If the credential is still valid, the attacker does not need to evade detection to keep using it.

Technical breakdown

AI/ML credentials as non-human identities

AI/ML credentials function as machine identities because they authenticate software to external services without a person in the loop. In modern delivery pipelines, these credentials often sit alongside model-hosting APIs, inference endpoints, and MLOps services. The risk is not limited to unauthorized use. A leaked token can enable model scraping, prompt abuse, quota exhaustion, or access to sensitive training data. Once the credential is active in production workflows, the compromise path is immediate and often invisible to traditional application security reviews.

Practical implication: treat AI service tokens as governed NHI assets, not developer convenience artifacts.

Why secrets in code and Git history remain exploitable

Secrets that appear deleted often remain recoverable in commit history, build logs, forks, or cached CI/CD artifacts. That persistence matters because many application credentials are valid long after first exposure. If repository controls do not combine detection, revocation, and history-aware cleanup, the secret remains a usable access path even after teams think they have fixed the issue. This is why secret detection is an identity problem as much as a code problem.

Practical implication: pair repository scanning with rapid revocation and history-aware remediation workflows.

Infrastructure as code replicates privilege at scale

Infrastructure as code turns one configuration decision into many deployed instances. That is efficient when controls are correct, but dangerous when templates embed open network rules, unencrypted storage, or overly permissive IAM roles. The same replication that accelerates delivery also multiplies identity and access mistakes across cloud environments. In other words, IaC does not create the misconfiguration, it industrialises it.

Practical implication: insert policy checks before merge and before deployment so bad identity posture cannot propagate.

Threat narrative

Attacker objective: The attacker aims to turn exposed machine credentials into durable authenticated access to production systems, models, and cloud resources.

1. Entry begins when attackers obtain exposed secrets from repositories, commit history, or CI/CD workflows and use them to authenticate as legitimate services.
2. Escalation follows when those credentials unlock AI platforms, container environments, or cloud APIs with more privilege than the task requires, expanding the blast radius.
3. Impact lands as model abuse, GPU consumption, dependency poisoning, or cloud compromise through authenticated access that bypasses perimeter controls.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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/ML credential exposure is now an NHI governance failure, not a narrow AppSec issue. Credentials for model hosting, inference APIs, and MLOps services are non-human identities that grant real production access. When 43% of organisations expose them, the problem is not isolated developer error. It is evidence that identity governance has not reached the software delivery plane. The implication is that AppSec teams can no longer treat secret handling as a side control.

Secret sprawl creates an identity blast radius that traditional remediation queues do not capture. A leaked token in source control can survive in Git history, logs, caches, and downstream forks even after the original file is removed. That persistence means the access window outlives the visible defect. Identity blast radius: the amount of authenticated reach a single exposed credential can create across cloud, CI/CD, and AI services. Practitioners need to think in terms of reachable systems, not just vulnerable files.

Infrastructure as code turns access mistakes into repeatable policy drift. Overly permissive IAM roles and open network rules embedded in templates are not one-off misconfigurations. They are replicated entitlement decisions that scale with every deployment. NIST CSF and ZT-NIST-207 both matter here because the control failure is not only detection, but the inability to constrain trust before propagation.

Application security must absorb lifecycle governance across code, pipeline, and runtime identities. The article’s roadmap points toward rotation, ephemeral credentials, and Zero Trust for CI/CD, but the deeper issue is lifecycle ownership. Who creates the credential, who approves its scope, who revokes it, and who verifies it after deployment are still fragmented questions in many programmes. Practitioners should treat those questions as governance design, not operational cleanup.

Static credentials remain a structural mismatch for AI-enabled delivery models. When software delivery is continuous and AI-assisted, long-lived credentials accumulate more exposure than most teams model. That makes OWASP-NHI and NIST-CSF the right baseline references for identity, secret, and control coverage. The field is moving toward pipeline-native governance, and teams that keep secrets outside that model will continue to chase symptoms.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which is why static credential models are becoming a governance liability.
• The 52 NHI breaches Report shows how exposed machine identities repeatedly turn into direct cloud compromise when lifecycle control is absent.

What this signals

AI credential governance is becoming part of software delivery governance, not a separate security workstream. When the same pipeline creates code, deploys infrastructure, and carries credentials, entitlement decisions have to be reviewed at the point of change. Teams that still rely on manual secret cleanup will keep inheriting access paths they never meant to publish.

Secret sprawl is turning into identity debt. The practical issue is no longer whether a secret was detected, but whether the organisation can prove it was revoked everywhere it existed. That pushes security leaders toward lifecycle ownership, pipeline policy enforcement, and tighter linkage between repository controls and cloud access.

Ephemeral credentials are becoming the right default for delivery systems because static credentials extend the window of compromise. The report’s pattern aligns with the control logic in the 52 NHI Breaches Analysis: authenticated access that outlives its purpose becomes the easiest route into production.

For practitioners

• Inventory AI and MLOps credentials as governed NHI assets Classify model-hosting tokens, inference keys, and service credentials alongside other non-human identities, with explicit owners, purpose, and expiry conditions.
• Rotate exposed secrets and revoke history-backed access paths fast Prioritise exposed secrets in repositories, Git history, and CI/CD logs. Make revocation and downstream validation part of the same workflow, not a separate ticket.
• Block permissive identity patterns in IaC before they ship Use policy checks to stop open network rules, unencrypted storage, and over-broad IAM roles from being deployed through templates.
• Restrict CI/CD tokens to the minimum pipeline scope Separate build, deploy, and release privileges so a single compromised token cannot move from source control into cloud administration.
• Adopt ephemeral credentials for delivery workflows Replace static secrets where possible so access expires with the task and cannot persist as a reusable path into production systems.

Key takeaways

• Application security now includes credential governance, because exposed AI/ML tokens and repository secrets create authenticated access paths into production systems.
• The scale of the problem is clear: 43% exposed AI/ML credentials, 78% running critical packages in production, and 77% retaining severe container flaws for more than 90 days.
• Practitioners should treat secrets rotation, pipeline scoping, and ephemeral credentials as identity controls that stop access from surviving longer than the task.

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.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, logs, commit history, build artefacts, and shared repositories. The risk is not only that a secret is exposed once, but that many recoverable copies remain active long enough to become a durable authenticated entry path.
• Identity blast radius: Identity blast radius is the amount of access a single credential can unlock across systems, pipelines, and cloud services. For non-human identities, it describes how far a leaked token can move before controls detect, revoke, or constrain it, and why scope matters as much as secrecy.
• Infrastructure as code drift: Infrastructure as code drift is the gap between intended security policy and what gets deployed when templates are reused or modified. It matters because the same privilege mistake can be replicated many times, turning one entitlement error into a broad and repeatable access problem.

Deepen your knowledge

AI/ML credential governance, secrets rotation, and ephemeral access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is now carrying delivery-plane identities as well as infrastructure identities, it is worth exploring.

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