AI and cloud secrets exposure is expanding the enterprise attack surface

At a glance

What this is: AI adoption is driving a sharp rise in exposed AI and cloud secrets, with the report tying that exposure to broader data leakage, account takeover, and supply chain risk.

Why it matters: IAM, NHI, and cloud security teams need to treat AI keys like high-value credentials because unmanaged issuance and duplication can turn a single secret into cross-system compromise.

By the numbers:

• AI-related secrets such as OpenAI API keys and Azure OpenAI API keys increased by approximately 140% in a span of one year.
• Almost 88% of organizations now leverage AI in at least one business function.

👉 Read SentinelOne’s report on AI and cloud secrets exposure

Context

AI and cloud secrets are now tightly coupled because the same credentials often secure models, application workflows, and supporting infrastructure. When those keys are duplicated across repositories, scripts, SaaS settings, and developer tooling, the problem stops being isolated secret sprawl and becomes an identity governance issue for non-human access.

The report argues that shadow AI and unmanaged keys create a larger blast radius than traditional cloud secrets because a single exposed AI credential can reveal prompts, outputs, internal logic, and data flowing through adjacent systems. That is a familiar NHI pattern with a newer payload, and many programmes are still treating it as an application problem rather than an identity control problem.

Standard secrets management is not enough when AI credentials are issued informally, reused across functions, and left outside normal ownership and rotation workflows. For teams building NHI governance, this is the same failure mode seen in other machine identities: visibility without lifecycle control still leaves exploitable access behind.

Key questions

Q: How should security teams govern AI API keys as non-human identities?

A: Treat AI API keys as governed non-human identities with named ownership, scoped permissions, time-bound access, and revocation authority. Do not allow personal keys or informal sharing across teams. The control objective is to make every AI credential traceable from issuance to retirement, because reused keys create hidden access paths across data, applications, and pipelines.

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 do teams get wrong about shadow AI and credential sprawl?

A: They treat shadow AI as a usage problem instead of a credential governance problem. The real issue is unmanaged issuance, duplication, and ownership loss. If a key appears in scripts, repos, or personal tooling, security teams need to assume the organisation has already lost lifecycle control over that access path.

Q: Who is accountable when an AI key is copied into multiple systems and later abused?

A: Accountability sits with the team that issued, approved, or tolerated the unmanaged credential path, not with the attacker who exploited it. Governance teams need clear ownership for AI credentials, documented approval chains, and revocation responsibility so that copied keys do not become nobody’s problem.

Technical breakdown

Why AI keys behave like high-blast-radius NHIs

AI API keys are non-human identities because they authorise software to act on behalf of a system, not a person. The report shows these keys are often used across customer support, financial tools, internal automation, and product experiences, which means one credential can cross organisational boundaries inside the enterprise. Unlike a single-purpose service token, an AI key often sits at the intersection of content access, model invocation, and downstream system interaction. That intersection creates a larger blast radius when the key is copied into multiple repositories or workflows.

Practical implication: Treat AI keys as high-value NHI credentials with explicit ownership, scope, and revocation paths.

Why exposed secrets turn AI adoption into a compound cloud risk

The report’s verified exploit path analysis shows attackers prefer practical entry points such as misconfigured services and old vulnerabilities, then pivot to reachable secrets. In that model, a cloud compromise is not the end state. It is a bridge to AI services, payment systems, or CI/CD pipelines that accept the same or related credentials. That is why AI adoption increases cloud risk: the AI layer inherits the trust structure of the underlying environment, including weak secrets hygiene and overbroad access.

Practical implication: Map AI credentials to the systems they can reach and remove any cross-service trust that is not essential.

Shadow AI is an identity governance failure, not just an IT usage issue

Shadow AI appears when teams use personal or unmanaged LLM keys outside approved channels, often to move faster than governance processes can keep up. The issue is not merely that tools are unsanctioned. It is that the enterprise loses control of issuance, rotation, monitoring, and accountability for credentials that can process corporate data. Once those keys appear in scripts, repos, or SaaS configs, standard secret scanning may find them but not restore ownership or lifecycle control.

Practical implication: Require centrally managed AI credentials and enforce lifecycle control before allowing production use.

Threat narrative

Attacker objective: The attacker wants to turn one exposed credential into broad access across AI, cloud, and delivery systems, then exfiltrate data or manipulate the workflows those credentials protect.

1. Entry occurs when attackers exploit misconfigured external services or legacy CVEs, then reach environments where AI and cloud secrets are stored or reused.
2. Escalation follows when exposed AI keys, cloud provider keys, or CI/CD tokens let the attacker move from one system into adjacent services and data flows.
3. Impact is achieved through data exposure, prompt manipulation, model poisoning, account takeover, or source code and deployment pipeline compromise.

Breaches seen in the wild

• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
• GitHub Action tj-actions Supply Chain Attack — Compromised tj-actions/changed-files GitHub Action leaks thousands of CI/CD secrets from 23,000 repositories.

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 keys are now governed as non-human identities, not as ordinary application settings. The report shows these credentials are copied, reused, and embedded across business workflows, which means their risk profile is closer to a service account than to a feature toggle. That shifts the governance question from where the key sits to who owns it, how it is scoped, and whether lifecycle controls exist at all. Practitioners should treat AI credentials as first-class NHI assets.

Shadow AI is really shadow credential management. When teams rely on personal or unmanaged LLM keys, the enterprise loses the ability to enforce least privilege, rotation, and revocation. The report’s 140% growth in AI-related secrets is a warning that the problem is scaling faster than informal governance can absorb. Practitioners should assume that every unsanctioned AI integration creates an unmanaged identity relationship.

Verified exploit paths matter because they collapse the distance between secret exposure and compromise. SentinelOne’s telemetry shows attackers prefer reachable, well-understood paths rather than elaborate chains, which means exposed AI and cloud credentials are not theoretical risk indicators. They are operational shortcuts into data, code, and infrastructure. Practitioners should prioritise the credentials that connect multiple systems, not just the ones with the highest nominal privilege.

Centralised AI credential governance is the named control gap this report exposes. AI credentials were designed for controlled service use, with stable ownership and known distribution. That assumption fails when the same key is duplicated across scripts, SaaS settings, and personal tooling, because the actor can no longer be governed as a single identity instance. The implication is that current approval and review models understate where AI access actually exists.

Identity blast radius is the right concept for this market shift. A compromised AI key can reveal prompts, internal logic, and linked datasets, while also opening a path into adjacent cloud and delivery systems. That makes credential location less important than credential reach. Practitioners should evaluate whether each AI key can be traced from issuance to every downstream system it can touch.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• The same report says only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• OWASP NHI Top 10 is the right next lens for teams assessing agentic exposure, privilege boundaries, and tool-use risk.

What this signals

AI credential governance now needs to sit alongside workload identity and secrets management in the core programme backlog. Once AI keys are reused across repositories, SaaS configurations, and internal tooling, the enterprise loses a clean boundary between sanctioned and unsanctioned access. Teams that already struggle with service account sprawl should expect the same failure pattern to appear faster in AI adoption unless ownership and rotation are enforced at issuance.

Identity blast radius will become the primary design variable for AI-enabled environments. The report shows that a single exposed key can affect data access, prompt behaviour, and delivery pipelines, which means security teams need to model downstream reach rather than just inventory secrets. For practitioners, the practical question is no longer whether AI is in use, but whether each AI identity has a bounded trust envelope that can actually be governed.

With 80% of organisations already seeing AI agents act outside their intended scope, according to the AI Agents: The New Attack Surface report, governance teams should prepare for more than credential rotation. They need continuous controls that detect shadow AI, block uncontrolled key reuse, and connect secret discovery to an ownership decision before the next workflow inherits that access.

For practitioners

• Classify AI keys as governed NHI assets Assign explicit owners, business purpose, and expiration rules to every AI credential, including keys used in support, finance, analytics, and product workflows.
• Eliminate personal and duplicated AI credentials Replace unmanaged or personal LLM keys with centrally issued credentials and block reuse across repositories, scripts, and SaaS configurations.
• Tie secret scanning to revocation and rotation Use discovery to trigger revocation or rotation when AI keys appear in code, pipeline variables, or exposed configuration files, rather than treating detection as the endpoint.
• Review cross-system trust paths around AI services Map which cloud, payment, ticketing, and CI/CD systems each AI key can reach, then remove access that is not necessary for the task.
• Build shadow AI detection into governance Monitor for AI usage outside approved channels so unsupported credentials do not become permanent access paths for corporate data and workflows.

Key takeaways

• AI adoption is now expanding the secret landscape faster than many governance programmes can absorb.
• The most dangerous failure mode is not secret exposure alone, but exposed AI credentials that can pivot into multiple enterprise systems.
• Security teams need lifecycle control, ownership, and cross-system reach mapping if they want AI keys to stay governable.

Key terms

• AI Credential: An AI credential is a secret that authorises software to access model APIs or related AI services. In practice, it behaves like a non-human identity because it can be reused, copied, and embedded in tooling, which makes ownership, scope, and rotation critical governance requirements.
• Shadow AI: Shadow AI is the use of AI tools or credentials outside approved governance channels. It becomes an identity problem when teams rely on personal keys, unmanaged integrations, or copied secrets that security cannot inventory, rotate, or revoke with confidence.
• Verified Exploit Path: A verified exploit path is a realistic sequence of misconfigurations, vulnerabilities, and exposures that an attacker can use to move from entry to impact. It matters because it focuses security attention on reachable compromise routes, not on theoretical weaknesses with no practical path.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and workflows exposed when a credential is compromised. For AI and cloud secrets, it is shaped less by the secret itself than by every service and dataset that secret can reach during its lifespan.

What's in the full report

SentinelOne's full report covers the operational detail this post intentionally leaves for the source:

• Telemetry-backed breakdown of how AI-specific secrets are distributed across customer environments
• Exploit path examples showing how exposed keys connect to cloud services, AI systems, and CI/CD pipelines
• Control recommendations for continuous surface monitoring, DevSecOps automation, and AI credential governance
• Examples of the specific legacy CVEs and misconfigurations that attackers use as entry points

👉 The full SentinelOne report includes the telemetry breakdown, verified exploit paths, and remediation guidance.

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.