AI cyber risk is expanding faster than enterprise controls

At a glance

What this is: This is a research analysis of how AI cyber risk is expanding as attackers abuse exposed credentials, compromised models, and agentic integrations.

Why it matters: It matters because AI systems increasingly sit inside identity-governed environments, so failures in secret handling, access scope, and runtime control can turn AI into an insider-like threat.

👉 Read HiddenLayer's research on the expanding AI cyber risk landscape

Context

AI cyber risk now includes the identity layer around models, tools, and integrations, not just prompts or outputs. When API keys are exposed, models are overprovisioned, or agentic systems can reach data and workflows directly, the security problem shifts from model misuse to access abuse and blast-radius expansion.

For IAM, NHI, and security architecture teams, the important question is not whether AI is useful, but whether the controls around it assume stable, human-paced access patterns. Once AI systems can be reached through leaked credentials or chained tool access, conventional governance breaks down at the same seam that matters for workload identity and privileged access.

Key questions

Q: How should security teams govern AI systems that use API keys and tokens?

A: Treat them as non-human identities with documented ownership, explicit scope, and revocation paths. AI service credentials should be inventoried, rotated, and limited to the smallest set of tools and data sources they need. If a key can reach multiple systems, compromise of that key becomes a broad access problem, not a single-app issue.

Q: Why do exposed AI credentials create such a large security risk?

A: Because exposed credentials turn AI services into legitimate entry points. Attackers can use valid API keys or tokens to access models, trigger workflows, and reach connected systems without breaking authentication. That makes the risk an identity and access problem, where the blast radius depends on what the credential can touch.

Q: What do organisations get wrong about agentic AI risk?

A: They often focus on the model and ignore the permission chain behind it. Agentic systems are risky because they can combine tools, retrieval, and downstream actions in one runtime flow. If those permissions are broad or shared, compromise can extend well beyond the model endpoint.

Q: How can teams reduce the damage if an AI system is compromised?

A: Limit the AI system's delegated access, isolate tool connections, and separate sensitive workflows into different trust zones. The goal is to prevent one compromised model or agent from exposing unrelated datasets, applications, or operational actions. Identity scope should be narrow enough that a single failure cannot become enterprise-wide exposure.

Technical breakdown

Exposed API keys turn AI services into legitimate attack entry points

AI services are often accessed through API keys, tokens, or embedded credentials that behave like any other non-human identity. When those credentials are exposed in repositories or applications, attackers do not need to break the model itself. They simply inherit legitimate access and can invoke costly or sensitive AI capabilities under the cover of valid identity. This is an identity problem first, because the model is being consumed through standing credentials rather than controlled session-based authorisation. The risk rises when the same key can reach multiple tools, data sources, or workflow endpoints.

Practical implication: treat AI service credentials as high-value NHIs and reduce their standing reach before they become reusable access paths.

Agentic AI expands the attack surface through tool chaining and RAG pipelines

Agentic AI changes the access model because an AI system can combine tools, retrieval sources, and external actions in one runtime flow. That creates a broader attack surface than a single model endpoint. Interactions between MCP tools, retrieval augmented generation pipelines, and downstream systems become high-value targets because compromise in one layer can cascade into the rest of the chain. The key issue is not just that AI can answer questions, but that it can execute work across systems. Once those connections exist, the security boundary is no longer the model itself, but the permissions behind every tool it can reach.

Practical implication: map every tool, data source, and workflow an AI system can touch, then constrain each connection independently.

Compromise by extension makes AI a blast-radius multiplier

When an AI system is compromised, the real loss often comes from everything it is allowed to access. That includes data stores, internal applications, and operational workflows that were never intended to be exposed through a single AI control plane. This is why AI compromise behaves like an identity concentration risk: the model becomes a pivot point that inherits broad reach through delegated access. In practical terms, the model is not the asset being stolen. The asset is the access it already holds. That is why runtime identity scope matters more than model novelty.

Practical implication: segment AI permissions so that compromise of one model or agent cannot expose unrelated systems or datasets.

Threat narrative

Attacker objective: The attacker wants to turn enterprise AI infrastructure into a cheap, stealthy execution layer that expands access into data, tools, and workflows.

1. entry via exposed API keys or stolen credentials that allow attackers to use AI services as legitimate users.
2. escalation through agentic tool access, where the compromised AI can call connected systems, retrieval pipelines, or workflow endpoints.
3. impact through compromise by extension, exposing data, workflows, and operational systems reachable from the AI environment.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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 identity risk is becoming an access governance problem, not just a model security problem. The article's core claim is that attackers increasingly abuse exposed keys, model access, and agentic toolchains rather than attacking AI in isolation. That shifts the center of gravity from prompt safety to non-human identity governance, where standing credentials and delegated permissions define the real blast radius. Practitioners should treat AI systems as governed identities with measurable access scope, not as abstract software features.

Leakage of AI credentials creates a reusable identity surface that traditional app security often misses. API keys embedded in code or applications behave like durable machine identities, which means compromise can persist long after the original exposure is discovered. This is exactly where OWASP NHI and NIST CSF align: the issue is not only detection, but inventory, ownership, and scoping of machine credentials that can be abused at runtime. The practitioner conclusion is simple: if you cannot inventory AI credentials, you cannot govern AI access.

Compromise by extension is the named concept security teams should track. Once an AI system is trusted with access to data, tools, and workflows, compromise of the model becomes compromise of everything downstream it can reach. That is a blast-radius problem, not a model-quality problem, and it applies across NHI, IAM, and privileged access programmes. The implication is that AI governance must be built around reachable systems and delegated scope, not around the model as a standalone asset.

Agentic AI makes identity boundaries more dynamic, which is why static access assumptions break down. The article points to interactions between agents, MCP tools, and RAG pipelines as the new attack surface. Those relationships matter because they create chained access paths that are harder to reason about in classic approval and review cycles. For practitioners, the field-level lesson is that identity governance must follow the runtime path, not just the account record.

The market signal is clear: AI security is converging with NHI governance. As models, agents, and tools become operationally intertwined, security programmes that treat AI as a separate domain will miss the access patterns that matter most. This does not eliminate model security work, but it does re-rank it beneath credential control, scope limitation, and lifecycle governance. Practitioners should expect AI security to be measured increasingly through identity controls, not only through content or model policy.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter have faced multiple attacks.
• The governance response is to pair identity inventory with lifecycle control, as outlined in Ultimate Guide to NHIs.

What this signals

Compromise by extension is the operational pattern security teams should now expect whenever AI is wired into data and workflow layers. The question is no longer whether a model is safe in isolation, but whether its access can be contained if the surrounding identity is abused. With 72% of organisations already reporting or suspecting NHI breaches according to our 2024 ESG Report: Managing Non-Human Identities, the governance gap is already structural.

AI programmes should be reviewed as access architectures, not just deployment projects. The more the model can call tools, retrieve data, and trigger actions, the more lifecycle governance has to follow the runtime path. Teams that still manage AI access as a static application permission set will struggle to contain blast radius when exposed credentials or overbroad delegation appear.

Compromise by extension should become a board-level metric for AI security maturity. If a single AI identity can touch sensitive systems without tight segmentation, the organisation has created an internal pivot point, not a controlled assistant. That is why identity boundaries, not model novelty, are becoming the primary indicator of AI security readiness.

For practitioners

• Inventory AI credentials as governed NHIs Build a complete register of API keys, tokens, certificates, and embedded credentials used by AI systems. Assign ownership, document where each credential is accepted, and identify which data sources or tools it can reach.
• Reduce standing reach on AI toolchains Limit each model, agent, and retrieval pipeline to the minimum systems it needs. Separate read paths from write paths, and avoid giving a single AI service broad access to internal workflows, data stores, and execution endpoints.
• Segment blast radius across agentic integrations Treat MCP tools, RAG sources, and downstream applications as distinct trust zones. If one component is compromised, the others should not inherit access automatically or via shared secrets.
• Tie AI access review to real runtime scope Review what an AI system can actually invoke at runtime, not just what the account was intended to use. Revalidate tool access, data reach, and delegated actions whenever the system design changes.

Key takeaways

• AI security risk is increasingly an identity problem, because exposed keys and delegated access let attackers use enterprise systems as legitimate entry points.
• The scale of the issue is already visible in NHI breach data, which shows that compromised non-human identities are a common enterprise failure mode.
• The most effective control shift is to narrow runtime scope, separate trust zones, and govern AI credentials as high-value non-human identities.

Key terms

• Non-Human Identity: A non-human identity is a machine, workload, service, or AI credential that authenticates and accesses systems without a person behind every action. In practice, it includes API keys, tokens, certificates, service accounts, bots, and agent identities that need ownership, scope, rotation, and offboarding.
• Compromise by Extension: Compromise by extension is the downstream exposure that occurs when an identity with broad permissions is abused and everything it can reach becomes reachable too. For AI systems, the model is often only the front door. The real risk is the attached access to data, tools, and workflows.
• Agentic AI Attack Surface: The agentic AI attack surface is the set of tools, data sources, retrieval paths, and execution points an autonomous or semi-autonomous AI system can use at runtime. It grows quickly when systems chain actions across services, because each connection becomes a potential abuse path.
• Delegated Access Scope: Delegated access scope is the set of permissions an identity is allowed to use on behalf of a system or user. In AI environments, scope has to be measured at runtime, because a broad delegated path can turn one exposed credential into multi-system compromise.

What's in the full report

HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:

• Examples of how attackers use exposed API keys to access AI services at scale.
• Discussion of agentic AI attack surface growth across MCP tools and RAG pipelines.
• Source examples on supply chain risks, leaked keys, and compromise by extension.
• The vendor's framing of AI deployments as attacker pivot points inside enterprise environments.

👉 HiddenLayer's full research covers exposed keys, agentic attack surface growth, and compromise by extension.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.