AI and cloud secrets exposure is expanding the enterprise attack surface

At a glance

What this is: SentinelOne's report says AI and cloud secrets exposure is growing fast, with AI-specific credentials, shadow AI use, and legacy cloud weaknesses combining into a broader attack surface.

Why it matters: IAM, PAM, and NHI teams need to treat AI keys as governed non-human identities because leakage, reuse, and weak lifecycle controls can turn routine exposure into data theft or model abuse.

Context

AI and cloud secrets exposure is the security problem here, not AI adoption itself. The article argues that once AI keys, cloud credentials, and CI/CD tokens are spread across repositories, SaaS configurations, and internal scripts, the control model stops being a simple secrets inventory problem and becomes a lifecycle and governance problem for non-human identities.

SentinelOne's telemetry across more than 11,000 anonymised customer environments is used to show how AI-specific credentials, shadow AI, and traditional cloud secrets now intersect. The practical issue is that many of these credentials are duplicated, poorly rotated, and used outside sanctioned channels, which makes conventional secrets management insufficient on its own.

The article also ties exposure to exploitability: once attackers gain entry through older cloud weaknesses, reachable secrets can extend access into AI assistants, data stores, payment workflows, and deployment systems. That turns one weak control into a multi-system identity exposure problem.

Key questions

Q: How should security teams govern AI provider keys across multiple dashboards?

A: Security teams should centralise AI provider keys into one inventory, then attach ownership, creation time, status, and usage data so review and revocation decisions can be made consistently. Provider consoles alone are not enough because they fragment the record of what exists. Treat the inventory as part of the control plane, not as reporting after the fact.

Q: Why do exposed AI secrets create more risk than ordinary cloud credentials?

A: AI secrets often sit between data sources, model access, and downstream business systems, so a single key can expose prompts, outputs, and linked datasets while also enabling access to adjacent services. The result is a larger blast radius. Teams should assess not only whether a secret exists, but what systems it can reach.

Q: What breaks when shadow AI is not included in identity governance?

A: When shadow AI is excluded, the organisation loses discovery, ownership, and enforcement at the same time. Unmanaged local agents can access cloud and SaaS resources without being enrolled in policy, which means no one can attest to their privileges or revoke them cleanly. The first failure is visibility, and the second is accountability.

Q: How should organisations respond when a legacy vulnerability and an exposed secret are both present?

A: Treat them as one attack path, not two separate issues. Patch or isolate the external weakness while also revoking or rotating any reachable secrets connected to that host or workflow. That closes the entry point and the lateral move opportunity at the same time.

Technical breakdown

Why AI keys behave like high-value non-human identities

AI keys are not just application configuration values. When an OpenAI or Azure OpenAI key is used across support systems, internal tooling, and product experiences, it behaves like a reusable non-human identity with real access scope, implicit trust, and downstream data reach. The article shows that these keys are often copied into code, SaaS settings, and scripts, which creates multiple control planes for the same credential. That duplication makes ownership, revocation, and monitoring harder than with a single application token. The governance issue is not merely exposure. It is that the same identity is allowed to exist in too many places with too little lifecycle discipline.

Practical implication: Treat AI keys as governed NHI assets with inventory, ownership, and revocation rules rather than as generic secrets.

How shadow AI expands the cloud attack surface

Shadow AI appears when teams use personal or unmanaged LLM keys to process corporate data without security oversight. That matters because the model interaction is not isolated. AI services often sit between CRM, ticketing, analytics, and support systems, so one exposed credential can reveal prompts, outputs, embedded business logic, and related datasets. In practice, shadow AI collapses the separation between sanctioned and unsanctioned access paths. It also makes standard discovery incomplete because the real usage pattern is distributed across business tools rather than a single approved platform. The risk is a governance blind spot, not just an unmanaged application.

Practical implication: Map where AI credentials are actually used, then close the gap between approved tooling and real operator behaviour.

Why legacy cloud vulnerabilities still matter for secrets exposure

The article links exposed secrets to real-world exploit paths that begin with misconfigured external services or older CVEs such as Shellshock and FortiGate SSL VPN disclosure. The mechanism is straightforward: initial access comes from a known weakness, then attackers pivot to reachable secrets, and those secrets open additional services. This is the operational bridge between vulnerability management and secrets governance. If internet-facing weaknesses remain in production, exposed keys become the shortcut from foothold to cloud, data, and AI access. The issue is not theoretical chaining. It is that adjacent control failures turn one compromised entry point into a broad credential-led expansion path.

Practical implication: Correlate vulnerability exposure with reachable secrets so that internet-facing flaws and credential sprawl are remediated together.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed credential or foothold into broader access across cloud, AI, and workflow systems, enabling data theft and control abuse.

1. Entry occurs through misconfigured external services or persistent legacy vulnerabilities that remain exploitable in production environments.
2. Credential access follows when attackers locate exposed cloud, payment, repository, or AI keys in connected systems or repositories.
3. Escalation happens as those reachable secrets are used to pivot into AI assistants, cloud environments, payment workflows, or CI/CD pipelines.
4. Impact includes data leakage, prompt manipulation, infrastructure manipulation, and broader compromise across business systems.

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.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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 credential sprawl is now a governance problem, not a discovery problem. The article shows that AI-specific keys are multiplying across repositories, SaaS configurations, and internal tooling faster than conventional secrets processes can classify them. That means the control gap is no longer whether a secret exists, but whether the organisation can prove where it is issued, who owns it, and where it is allowed to operate. Practitioners should treat AI keys as a distinct NHI class with lifecycle governance, not as ordinary application secrets.

Shadow AI creates an identity shadow zone between approved systems and real usage. Personal or unmanaged LLM keys used in business workflows break the assumption that sanctioned tooling reflects actual access behaviour. Once that assumption fails, recertification and access review processes lose coverage because the effective identity is outside the approved inventory. The implication is a redesign of governance scope, not just tighter policy wording.

High-privilege cloud secrets and AI credentials now share the same blast-radius model. The article's core insight is that an exposed key can reach far beyond one workload, because AI services often sit at the intersection of customer data, internal logic, and operational systems. That makes least privilege a lifecycle question, not just a provisioning question. Practitioners need to govern where a credential can travel, not just what system first receives it.

Legacy vulnerability management and secrets governance can no longer be run as separate queues. The article ties exploit paths to old CVEs and then to reachable secrets, which is the real attack pattern teams must absorb. A host patching programme that ignores exposed keys leaves the attacker one pivot away from cloud and AI access. The practitioner takeaway is to align remediation around reachable control paths, not around isolated findings.

Identity blast radius is the right concept for AI and cloud convergence. When one credential can expose prompts, datasets, deployment systems, and payment flows, the question is not whether access exists but how far it can propagate. That is a broader problem than secret leakage alone and it changes how boards, security teams, and IAM owners should measure exposure. The programme response should be built around containment boundaries, not static secret counts.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

AI credential governance now needs an identity model, not a cleanup project. The article's underlying signal is that AI keys behave like portable access rights across support, analytics, and product systems. That means organisations should stop treating them as incidental secrets and start managing them as non-human identities with ownership, revocation, and usage boundaries.

Shadow AI is the fastest route to policy drift. If unmanaged LLM keys are already processing corporate data, the approved IAM catalogue no longer reflects operational reality. The programme implication is clear: secrets inventory, usage monitoring, and access review must converge around actual runtime behaviour, not just approved architecture.

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers. The scale of leakage is now large enough that exposure management must focus on containment boundaries and blast-radius reduction, not only discovery speed.

For practitioners

• Classify AI credentials as governed NHI assets Create a separate inventory class for AI API keys, map each key to an owner, business service, and approved usage boundary, and make revocation accountable to that owner.
• Collapse shadow AI into the approved inventory Identify where personal or unmanaged LLM keys are being used in support, engineering, and analytics workflows, then require those flows to move onto centrally managed credentials.
• Tie secrets review to internet-facing exposure Correlate exposed keys with misconfigured external services and legacy CVEs so remediation closes the entry point and the reachable secret at the same time.
• Restrict duplicated credentials across systems Find AI and cloud secrets that appear in repositories, SaaS configurations, and scripts, then remove duplicate copies and reduce the number of places each key can be used.
• Monitor for AI prompt and data abuse Add alerting for abnormal AI key usage patterns, unexpected prompt volume, and cross-system access that suggests the key is being used to harvest data or manipulate model output.

Key takeaways

• AI and cloud adoption are converging into one credential-led attack surface where exposure can move from a single secret to multiple enterprise workflows.
• The article links legacy external weaknesses to reachable secrets, showing why patching and secret revocation need to be handled as one remediation path.
• Security teams need governed issuance, rotation, and usage controls for AI keys, because discovery alone does not reduce the operational blast radius.

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.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.