Cloud adoption is intended to help organizations accelerate, but traditional security operating models can quickly stifle that innovation. The reason is that these models rely on manual approvals, post-hoc reviews, or even outright denial, creating friction. In AWS environments, teams can quickly provision infrastructure and launch workloads, and if the security team is known for hindering progress, they risk being bypassed.

"We often hear that security teams believe their job is to say 'no,'" said Alon Diamant-Cohen, principal consultant for hybrid cloud security at Stratascale, in a recentBrightTALK webinar. "If security teams are notorious for saying 'no,' then they are not practicing security the way it should be practiced in 2026, and it becomes difficult to build bridges or do any effective work," he said.

Despite this reality, many security teams still hold a 'gatekeeper' mindset. This is not surprising, as they are often overwhelmed by alerts and need to protect environments far larger than they can handle. However, as Diamant-Cohen argues, security teams should position themselves as enablers, helping people achieve their goals securely.

The real risk of saying 'no'

The 'department of no' model is riskier today because the cloud has become a critical business enabler, and AI-driven innovation increasingly relies on access to cloud resources. In traditional models based on security perimeters, simply blocking access may push work toward insecure channels, such as unapproved tools, accounts, or AI services.

"If security says 'no,' someone will always find a way around it. As security practitioners, our primary task is: 'Yes, but let's do it securely this way,'" Diamant-Cohen said.

Security teams cannot protect what they cannot see. If teams bypass security because official processes are too cumbersome, the organization loses visibility, accountability, and control. These are exactly the security elements needed for AWS expansion, especially in the context of increasing complexity and risks that are difficult to manage passively.

Fortunately, many issues can be prevented through a proactive approach. For example, misconfigurations, access issues, and permission sprawl can mostly be avoided if security teams engage early to shape how teams build, deploy, and scale. After all, AWS is a high-speed environment, and guardrails must be embedded from the start to govern how teams configure and operate.

Governance is how security says 'yes'

Governance may sound bureaucratic, but it is also the mechanism that allows security teams to approve more activities with less manual intervention. As long as policies are clear and can be enforced through technical measures available to the organization, security teams do not need to review every decision from scratch.

"Organizations really have two approaches: tools first then rules, or rules first then tools," Diamant-Cohen said. Both approaches work, but the right choice depends on the organization. "What you need is: a high-level, technology-agnostic governance policy written for the business, and a technical translation of that policy into the tools you choose to enforce it," he said.

In many cases, it is best to develop cloud security policies before procurement to determine the best enforcement tools. But sometimes, it makes more sense to procure a platform first and then build security policies around it, especially when deadlines are looming and certain controls need to be in place before new projects launch.

Either way, building a security foundation gives security teams visibility from the start rather than retroactive fixes. When scaling AWS adoption, governance must be connected to policy, architecture, operations, and cost visibility. With enterprise-level governance policies, security controls can be repeatable, which is how organizations can scale securely without making security a barrier.

AI raises the stakes for cloud guardrails

The argument that security teams must become enablers is not new, but agentic AI greatly increases the stakes. When AI agents can access systems, call APIs, operate across workflows, or support autonomous security and operations processes, governance must be in place before these behaviors occur.

This makes a secure cloud foundation even more important. Before teams further expand cloud workloads, they need a pre-configured environment where core controls such as identity, logging, network segmentation, monitoring, and security policies are built in. Cloud teams often call this foundation a landing zone. This foundation is critical because every new workload—including autonomous agents—should inherit the right guardrails before production, rather than requiring security teams to intervene afterward.

As more systems become autonomous, security can no longer rely solely on manual review. Diamant-Cohen also noted that agents are non-deterministic, meaning they do not always produce the same answers or take the same paths. This unpredictability makes it even more important to define what systems and agents are allowed to access, what actions are prohibited, how activities are monitored, and who is accountable when incidents occur.

"Governance is shorthand for 'I need to be able to see everything, I need to have a list of allowed and prohibited actions, and I need someone to be accountable for every action taken in the cloud,'" Diamant-Cohen said.

In the agentic era, this definition is the foundation of secure autonomy. Landing zones, zero-trust controls, data security policies, and continuous monitoring all provide security leaders with a way to say 'yes' to AI-driven innovation without giving up visibility or control.

For organizations building or expanding on AWS, the path to better security begins with discovery: what currently exists, what controls are already in place, and how governance needs to improve. SHI works with AWS customers to turn this assessment into a long-term roadmap for secure, scalable cloud adoption.