Topic starter
10/06/2026 12:14 am
TL;DR: 43% of organisations have exposed AI or machine learning credentials, while 78% run packages with critical vulnerabilities in production and 77% retain high or critical container flaws for more than 90 days, according to Orca Security’s 2026 State of Application Security Report. The data shows AppSec now has to govern identities, pipelines, and runtime exposure together, not as separate queues.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “2026 State of AppSec: When Development Velocity Outpaces Security”.
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.
Key questions
Q: What breaks when AI/ML credentials are exposed in production?
A: The failure is immediate authenticated access.
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.
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.
Practitioner guidance
- 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.
Bottom line: AI/ML credentials now create a direct identity and access exposure in production, not just a code-quality issue.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
11/06/2026 1:56 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI/ML credentials expose a new AppSec blind spot in production
12/06/2026 3:31 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI/ML credentials expose a new AppSec blind spot in production
This post was modified 18 hours ago by NHI Mgmt Group