AWS cloud security governance gets urgency as AI agents spread

Stratascale principal consultant Alon Diamant-Cohen is arguing for stronger AWS cloud security governance as enterprises expand cloud workloads and begin using agentic AI in operational workflows. In a recent BrightTALK webinar, Diamant-Cohen said security teams that rely on late approvals, manual reviews or outright denials risk being bypassed by cloud teams that can provision infrastructure quickly.

The point is operational, not philosophical. In AWS environments, developers and platform teams can move faster than traditional review processes. If security becomes a bottleneck, Diamant-Cohen said teams may shift work into unapproved tools, accounts or AI services, reducing the organization’s visibility into what is being built and who is accountable for it.

The discussion, presented by SHI/AWS, did not include customer counts, spending figures or incident data. It framed the issue as a governance problem for enterprises already using or expanding AWS, where scale, AI adoption and cloud autonomy make ad hoc security review harder to sustain.

What is AWS cloud security governance?

AWS cloud security governance is the set of policies, technical controls and operating practices that determine how teams provision, secure and monitor cloud resources. In practice, it includes rules for identity, logging, network segmentation, policy enforcement, monitoring and accountability across AWS environments.

Diamant-Cohen said enterprises need both business-level policy and a technical version of that policy that can be enforced through the tools an organization uses. That enforcement layer is what lets security approve more activity without reviewing every infrastructure decision from scratch.

Why security teams get bypassed

Diamant-Cohen described a common failure mode: security teams act as gatekeepers because they are flooded with alerts and are responsible for environments growing faster than their processes. The result can be a reputation for blocking work rather than enabling it under defined conditions.

That model is more brittle in cloud than in perimeter-based infrastructure. When the official path is too slow, teams can create resources elsewhere, use unsanctioned services or adopt AI tools outside central oversight. Security then loses the data it needs to manage misconfigurations, access issues and privilege sprawl before they become harder to correct.

His recommended shift is to involve security earlier in the build process, so controls are embedded before workloads go live. For AWS teams, that means guardrails should shape how infrastructure is provisioned and operated, rather than being added after deployment.

AI agents make the control problem harder

Agentic AI raises the stakes because agents can access systems, call APIs and take actions across workflows. Diamant-Cohen noted that agents can be nondeterministic, meaning they may not produce the same response or follow the same path each time.

That unpredictability increases the need to define allowed actions, blocked actions, monitoring requirements and accountability before autonomous systems are connected to production workflows. Manual approval alone is a poor fit when systems are designed to act without waiting for a human reviewer.

Cloud teams often use landing zones as the preconfigured foundation for this type of control. A landing zone gives new workloads a standard environment with core security settings already in place, so applications and agents inherit guardrails before launch.

Tools first or policy first

Diamant-Cohen said enterprises can start by defining rules and then selecting tools, or by buying a platform first and building policies around it. He described both approaches as workable, depending on the organization and deadline pressure.

The strategic risk is treating governance as paperwork. In AWS environments, governance is the mechanism that connects policy, architecture, operations and cost visibility. For security leaders, the near-term task is to make the approved path fast enough that cloud teams have fewer reasons to create their own.

This story draws on original reporting from CIO Dive.