Cloud security best practices in 2026 centre on identity and control

At a glance

What this is: This is a cloud security best-practices guide that argues identity, logging, encryption, and governance remain the core controls, with AI agents adding new requirements around scoped access and tool control.

Why it matters: It matters because cloud and AI workloads now behave like actors, so IAM, PAM, and governance teams need to treat machine and agent identities as first-class controls, not side effects of infrastructure security.

By the numbers:

• The Cloud Controls Matrix v4.1 holds 197 control objectives in 17 domains.
• The CSA AI Controls Matrix adds 243 control objectives across 18 domains for AI workloads.

Context

Cloud security only works when the control plane matches the operating model. In practice, the provider secures the underlying infrastructure while the customer owns data, configurations, identities, and workload access, which is why a good programme starts with shared responsibility rather than a tool stack.

This guide is not just about hardening cloud infrastructure. It also shows how AI agents change the security equation because they behave like non-human actors that need scoped identity, controlled egress, and auditable tool use.

Key questions

Q: How should teams implement cloud security without over-trusting the provider?

A: Start with the service model and draw ownership lines for identities, configurations, data, logging, and recovery. The provider secures the underlying platform, but customer teams still control what runs, who can access it, and how it is monitored. If those boundaries are unclear, governance fails before the first control is enforced.

Q: Why do short-term credentials reduce risk compared with manually managed cloud access keys?

A: Short-term credentials reduce risk because they limit how long an access token can be abused and remove much of the manual handling that leads to leakage. When credentials are generated for a specific session and expire quickly, attackers have less time to exploit them, and administrators have a smaller window for unauthorized reuse or lateral movement.

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: What should security teams do when cloud workloads start acting like agents?

A: Treat them as delegated identities with bounded authority, not as passive software. That means separate identities, per-action authorization, controlled egress, and audit logs that record what was called, when, and under which approval path.

Technical breakdown

Why shared responsibility still defines cloud control boundaries

Cloud security failures often start with a false assumption that the provider secures more than it does. In reality, service models change which layers you own, but customer responsibility almost always includes identities, data, configurations, and access control. That means cloud governance is not just about platform hardening; it is about knowing which controls move with the service and which remain yours. For IAM and PAM teams, the practical issue is not abstraction but accountability: every service choice changes where identity enforcement must happen, and those boundaries need to be explicit in policy and review cycles. See the Cloud Security Guide.

Practical implication: Map each cloud service to its real control boundary before assigning access, logging, and recovery ownership.

Why temporary credentials matter more than static keys

Cloud workloads fail most often when long-lived credentials outlive the task they were meant to serve. Federation and temporary credentials reduce blast radius because access is issued for a bounded session rather than stored as a reusable secret. That changes the security model from possession-based trust to time-bound authorization. The same logic applies to service accounts, workload identities, and agent runtimes: if a credential can be copied, cached, or reused indefinitely, it becomes an attacker’s persistence layer. IAM teams should treat credential lifespan as a control variable, not a convenience choice. See the AI Agent Authorisation Guide.

Practical implication: Prefer federated, short-lived credentials wherever a workload or agent can authenticate without static secrets.

How AI agents change cloud security assumptions

AI agents sit on top of cloud controls but can act faster and more variably than traditional workloads. They call tools, touch data, and select actions, so the key question becomes not whether they are authenticated, but what they are allowed to do at each step. That creates an identity problem, a logging problem, and a delegation problem at once. If the agent inherits broad defaults, prompt injection or misuse can turn a normal cloud permission into a high-impact action path. The right model is not to trust the model itself, but to bind each agent to a scoped identity and enforce authorization outside the LLM. See the Agentic AI Security Guide.

Practical implication: Bind every AI agent to a narrow identity and enforce downstream authorization for each tool or data action.

Threat narrative

Attacker objective: The attacker wants to convert a legitimate cloud or agent identity into broad, reusable access that can be used to steal data, invoke tools, or expand control across the environment.

1. Entry occurs when an over-permissioned cloud workload or AI agent receives broad default access through a standing credential or inherited service account.
2. Credential abuse follows when the attacker or malicious prompt uses that identity to reach storage, APIs, or other tools the workload was never meant to access.
3. Escalation happens when the compromised identity can move laterally across cloud resources, pull secrets, or trigger additional actions without per-request checks.
4. Impact is data exposure, unauthorized action, or infrastructure misuse that persists until the credential, policy, or trust relationship is revoked.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

Cloud security is now an identity governance problem, not just a posture problem. The guide’s strongest point is that data, configurations, and identities remain customer-owned even when infrastructure is provider-managed. That means cloud governance must extend beyond CSPM-style misconfiguration checks into access modelling, entitlement review, and identity lifecycle control. For practitioners, the discipline is to govern who or what can act in the cloud, not just whether the cloud is configured correctly.

AI agents create a new class of cloud workload risk because they behave like delegated operators. The article is right to treat agents as actors that need scoped identity, tool boundaries, and loggable actions. That is an important expansion of agent authorisation thinking into cloud operations, where a model prompt can become an execution path. The practical implication is that agent access must be designed as a governance layer, not an exception layered onto existing workloads.

Secrets sprawl becomes a cloud security failure mode when machine identities outlive their task. The article’s emphasis on temporary credentials, secret scanning, and key protection reflects a simple reality: any reusable credential becomes a persistence mechanism once it leaves the intended workflow. That is why cloud teams should measure not only where secrets are stored, but how long they remain valid and how widely they can be reused. The practitioner conclusion is to treat credential lifetime as a control objective, not an implementation detail.

Cloud control frameworks are converging on governance, but the operational risk sits in execution. The use of NIST CSF, CSA CCM, and AI control models shows that the market is moving toward integrated control maps across infrastructure, identity, and AI workloads. Yet the article also shows the gap between framework coverage and day-to-day enforcement, especially where agent permissions, logging, and delegated access are concerned. Practitioners should use frameworks to organise control ownership, then verify that identity enforcement actually happens at runtime.

From our research library:

• Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
• Read next: AI Agent Authorisation Guide

What this signals

Scoped identity is becoming the control point that separates cloud automation from cloud abuse. When a workload or agent can act only within a narrow, time-bound identity, the security programme gains a meaningful enforcement boundary instead of a broad trust assumption. That is why identity scoping should sit beside posture monitoring in cloud governance, not behind it.

AI agents force cloud teams to move enforcement downstream. The important change is not that agents use APIs, but that they can decide when to call them and with what context. That makes downstream authorization, tool allowlisting, and action logging the real control plane for agentic workloads, not the model prompt or the interface layer.

According to the 2026 Infrastructure Identity Survey, 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege. That pattern is a warning sign for cloud programmes: once an agent inherits excess privilege, every other cloud control becomes easier to bypass rather than harder to reach.

For practitioners

• Map shared responsibility per service Document who owns patching, configuration, logging, access control, and recovery for each cloud service model you use.
• Move all workloads to short-lived credentials Replace static API keys and shared service accounts with federated identities and temporary credentials that expire after the task ends.
• Scope every AI agent to a dedicated identity Assign one identity per agent, remove shared service accounts, and restrict each agent to the smallest set of tools and data it needs.
• Separate logs from the systems they describe Centralise identity, control-plane, network, and application logs in a protected store with retention and role separation for log administration.
• Test incident playbooks for leaked keys and rogue agents Rehearse token revocation, account isolation, and tool-access shutdown for compromised workloads before you need those steps in production.

Key takeaways

• Cloud security programmes still fail most often at ownership boundaries, not only at configuration errors.
• AI agent workloads extend the identity problem into runtime decision-making and tool access.
• The practical fix is to combine cloud governance with scoped identities, short-lived credentials, and auditable execution.

Related NHI Mgmt Group resources: Cloud Security Guide · Agentic AI Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• STS Temporary Credentials: STS temporary credentials are short-lived AWS credentials issued after a session or role exchange. They reduce exposure compared with long-term keys because they expire automatically and can be scoped to a narrower set of actions. They are a common fit for agent workflows that should not retain persistent access.
• Scoped identity: An identity that is constrained to a specific task, workflow, or service boundary. For AI systems, the concept is essential because it ties access to purpose, limits blast radius, and makes revocation and audit meaningful.
• Downstream Authorization: The access decision a backend system makes after a server or agent leaves the initial login boundary. In MCP environments, this is the part that determines what the server can actually do in SaaS, cloud and database systems, and it often carries more risk than the front-door authentication step.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that complements cloud and AI control design. It is built for practitioners who need to connect identity governance to operational security decisions across modern environments.