AI is expanding the cloud attack surface faster than defenses adapt

At a glance

What this is: SentinelOne argues that AI is expanding cloud risk through leaked secrets, permissive defaults, dependency confusion in MCP, and AI-assisted attacker behaviour, even as it improves defender speed and analysis.

Why it matters: IAM, PAM, and cloud security teams need to treat AI services, agent tooling, and AI-assisted development as access-control problems as much as tooling problems, because identity scope now shapes both exposure and detection.

Context

AI is expanding cloud attack surface because it connects more data, tools, and automated actions to privileged systems than most governance models were designed to handle. In practice, that means secrets leakage, permissive service roles, and weak inventory of AI services can become direct paths into cloud workloads and data.

The identity question matters here because AI services, MCP-connected tools, and cloud-native AI platforms all depend on credentials, entitlements, and trust relationships. When those identities are overbroad, hard to inventory, or embedded in development workflows, the same access assumptions that already strain cloud security become easier for attackers to abuse.

Key questions

Q: What breaks when AI workloads inherit broad Azure permissions?

A: Effective permissions can become much wider than the AI project boundary, so identities that look narrow on paper can still reach data, logs, secrets, or network paths. The practical failure is scope drift: assignment review says one thing while actual access says another.

Q: Why do leaked credentials create more risk when AI agents can chain findings?

A: Leaked credentials matter because they often provide the first trusted foothold, and an agent can rapidly test where that access works next. If credentials authenticate across multiple apps or services, a single leak can become lateral movement. The risk is not the leak alone. It is the reuse and reach of the identity behind it.

Q: How can security teams tell whether AI posture management is actually working?

A: It is working when teams can answer four questions quickly and consistently: who owns the agent, what it can access, which guardrails apply, and when access changed. If those answers depend on manual log-chasing, the control is too weak. Effective posture management produces usable evidence, not just a dashboard view.

Q: Should organisations manage AI tool access separately from cloud identity governance?

A: No. AI tool access should sit inside cloud identity governance because the risk comes from the same sources: credentials, roles, secrets, and delegated trust. Separate review processes usually miss how a connector, notebook, or agent permission can extend into production data or administrative functions. Governance works best when AI access is treated as part of the broader entitlement model.

Technical breakdown

How MCP and AI tooling reintroduce dependency confusion

Model Context Protocol lets LLMs discover and invoke external tools at runtime, which makes tool identity a security control rather than a convenience layer. If a malicious tool later appears with the same or a similar name as a trusted tool, the model may select it because the current context favours what is available now, not what was previously approved. That creates a moving trust boundary that resembles dependency confusion but operates inside agent workflows and AI jobs. The governance problem is not just package integrity, but tool inventory, naming discipline, and runtime approval of what the model can call.

Practical implication: treat AI tool registries and MCP connectors as governed identity surfaces, not informal integrations.

Why leaked secrets and permissive cloud roles amplify AI risk

The article ties AI-enabled development to leaked credentials, JSON Web Tokens, API keys, and cloud secrets, then shows how permissive defaults in services such as SageMaker can turn that exposure into broader compromise. A notebook role that can read metadata, delete data, or enumerate unrelated secrets turns a local AI workload into a platform-wide access problem. This is classic entitlement sprawl, but AI increases the speed at which bad code, bad prompts, and bad permissions collide. The result is a wider blast radius from a single leaked token or default role.

Practical implication: scope AI workload identities tightly and remove default permissions that bridge into other domains.

How AI changes cloud detection, alert triage, and response

Defenders are also using AI to compress detection and response cycles, especially where false positives and analyst workload slow action. The article describes AI-SPM as an inventory and attack-path layer for AI assets, paired with CIEM to monitor who and what can interact with cloud-native AI services. That combination matters because AI security is not only about model behaviour, but also about who can reach the model, what they can query, and which downstream systems they can influence. Better detection only helps if entitlement data and asset inventory are accurate enough to support it.

Practical implication: connect AI posture monitoring to entitlement telemetry so detection can see both assets and access paths.

Threat narrative

Attacker objective: The attacker wants to convert AI-connected trust relationships into cloud access, data exposure, or poisoned business decisions at scale.

1. Entry occurs through leaked credentials, permissive cloud defaults, or a malicious tool that is accepted into an MCP or AI development workflow.
2. Credential access or abuse then lets the attacker invoke cloud AI services, enumerate secrets, or gain access through overbroad default roles.
3. Escalation follows when those permissions expose unrelated secrets, data stores, or cross-domain access paths, enabling lateral movement and data manipulation.
4. Impact comes from data poisoning, exfiltration, account hijacking, or broader cloud compromise, with AI accelerating both attacker actions and defender response.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

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 has become an access-control problem before it becomes a model-risk problem. The article shows that the most practical cloud failures still begin with leaked credentials, overbroad defaults, and tool trust decisions. In other words, AI does not replace entitlement risk, it multiplies the consequences of weak identity governance. Practitioners should therefore treat AI adoption as a control-scope expansion, not a separate security programme.

Model Context Protocol creates a new form of runtime trust debt. Tool selection inside an AI session can drift from the intended trusted path if naming, inventory, and approval are not governed tightly. That makes the integrity of AI tool registries and connector lifecycles a first-order control issue for cloud and IAM teams. The practical conclusion is that agent tool access needs lifecycle governance, not just sandboxing.

AI-SPM only matters if it is paired with identity telemetry. Inventorying AI services without entitlement context leaves security teams unable to see who can touch what, and how a notebook, token, or secret becomes a cloud-wide path. The article makes clear that cloud AI risk is produced by the intersection of posture and permissions. Practitioners should align AI posture management with CIEM and service identity governance, not run them as separate views.

Cloud AI risk is exposing a governance gap in how organisations classify non-human access. Service roles, secrets, and AI tooling are being treated as implementation details when they now behave like material identities with their own blast radius. That gap is exactly where attackers gain leverage, whether through dependency confusion, secret leakage, or permissive notebook roles. The field needs to move from asset-centric AI security to identity-centric AI governance.

AI improves defenders most when it reduces noise and shortens decision time, not when it replaces control design. The survey data in the article shows that practitioners value faster detection and better risk scoring, but those gains still depend on accurate posture data and entitlement boundaries. AI can amplify analyst effectiveness, yet it cannot compensate for an ungoverned access model. Security leaders should read this as a call to modernise control architecture, not just tooling.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).

What this signals

MCP and AI connectors are now part of the trust boundary. Security teams should assume that every tool an LLM can select or call is an access path that needs inventory, ownership, and removal logic. The governance question is no longer whether the model is allowed to think, but whether its runtime tool choices are constrained to approved identities and approved destinations.

Cloud AI security is converging on entitlement hygiene. The article shows that leaked secrets, default roles, and broad service permissions are still the common failure modes, even when the trigger is AI rather than a traditional workload. That means cloud and IAM teams should evaluate AI services with the same rigor they apply to privileged workloads, while adding dedicated posture checks for connectors, notebooks, and model tooling.

For practitioners

• Harden AI service roles and defaults Review default permissions on cloud AI services such as notebooks and managed model platforms, then remove access paths that allow metadata reads, cross-domain secret discovery, or data deletion.
• Inventory MCP connectors and tool trust paths Track every external tool, job, and connector that an LLM can invoke, and require naming controls and approval steps for new tools before they enter live context.
• Tie AI-SPM to CIEM Connect AI asset inventory to entitlement monitoring so security teams can see which users, roles, and service identities can reach AI services and related secrets.
• Scan development workflows for secret leakage Look for API keys, JSON Web Tokens, and cloud credentials in AI-assisted coding outputs, repositories, and deployment pipelines before those artefacts reach production.
• Separate model risk from access risk Use distinct review paths for model behaviour, service posture, and access scope so AI governance does not collapse into a single undifferentiated approval step.

Key takeaways

• AI is widening cloud attack surface because it turns tools, credentials, and service roles into faster paths to misuse.
• The same reports show defenders gaining from AI as well, especially in faster detection, triage, and response.
• The practical challenge is governance, because AI security now depends on controlling identity scope across services, connectors, and development workflows.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• AI-SPM: AI Security Posture Management extends security visibility into AI models, prompts, outputs, and supporting workflows. It gives teams a way to identify risky AI usage, check policy alignment, and monitor how AI systems interact with data and identity controls over time.
• Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management focuses on who has access to what in cloud systems, especially excessive or unused permissions. It helps reveal overprivileged identities, but it does not automatically remove them. In practice, it is most useful when tied to policy enforcement and access expiry mechanisms.
• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security practitioners connect identity controls to real-world cloud and AI access patterns.