Cloud adoption is supposed to help enterprises move faster, but traditional security operating models can quickly stifle that ability to innovate. That’s because they create friction due to reliance on manual approval, late-stage review, or even blanket denial. In an AWS environment, where teams can quickly provision infrastructure and launch workloads, a security team known for blocking progress risks being bypassed.
“We hear a lot about security teams who feel that it’s their role to say no,” said Alon Diamant-Cohen, principal consultant of hybrid cloud security at Stratascale, in a recent BrightTALK webinar. “If a security team develops a reputation for saying no, they’re not practicing security correctly for 2026, and it’s very hard to build bridges and do anything functional,” he said.
Despite this reality, many security teams still follow the “gatekeeper” mindset. That’s hardly surprising, given how they’re often inundated with alerts and expected to protect environments that scale much faster than they can keep up with. However, as Diamant-Cohen argued, security teams need to position themselves as enablers, helping people achieve their goals safely.
The real risk of saying no
The “department of no” model is even riskier now that the cloud is a critical business enabler, and AI-driven innovation increasingly depends on access to cloud resources. In traditional models built on the notion of a secure perimeter, simply blocking access can end up pushing work to less secure channels, such as unapproved tools, accounts or AI services.
“If security says no, someone’s going to find a way around it. Our job, as security practitioners, first and foremost, is to say, ‘Yes, but here’s how we’re going to do it securely,’” Diamant-Cohen said.
Security teams can’t protect what they can’t see. If teams bypass security because official processes introduce excessive friction, the organization loses visibility, accountability and control. Those are the very things AWS adoption needs to scale securely, especially as complexity increases and risk becomes harder to manage reactively.
Fortunately, with a proactive approach, many issues can be prevented. Misconfigurations, access issues and privilege sprawl, for example, can largely be prevented, provided that security teams are involved early enough to shape how teams build, deploy and scale. After all, AWS is a high-velocity environment where guardrails must be embedded from the outset to govern how teams provision and operate.
Governance is how security says yes
Governance may sound bureaucratic, but it’s also the mechanism that allows security teams to approve more activity with less manual intervention. Provided policies are clear and can be enforced using the technical measures available to the organization, security will no longer need to review every decision from scratch.
“There are really two approaches here that enterprises can take: tools before rules or rules before tools,” Diamant-Cohen said. Both approaches are valid, but the right one depends on the organization. “What you need is both a high-level agnostic governance policy that is written for the business, and a technical translation of that policy to your tool of choice where you’re enforcing it.”
In many cases, it’s better to develop a cloud security strategy before going through procurement to identify the best tools to enforce it. Sometimes, however, it makes more sense to procure a platform first and then develop security policies around it, especially when you have a looming deadline that requires certain controls to be ready before the launch of a new project.
Either way, building a secure foundation lets security gain visibility from the start, rather than trying to retrofit after the fact. When scaling AWS adoption, governance has to connect to policy, architecture, operations, and cost visibility. With an enterprisewide governance policy, security controls are also repeatable, and that’s what gives organizations the means to scale safely without security becoming a barrier.
AI raises the stakes for cloud guardrails
The argument that security teams must be enablers isn’t new, but agentic AI has greatly raised the stakes. When AI agents can access systems, call APIs, act across workflows, or support autonomous security and operations processes, governance has to be in place before those actions occur.
That makes secure cloud foundations all the more important. Before teams further expand their cloud workloads, they need a preconfigured environment where core controls for identity, logging, network segmentation, monitoring, and security policy are built in. Cloud teams often refer to that foundation as a landing zone. This foundation is essential because every new workload, including autonomous agents, should inherit the right guardrails before going into production, rather than security having to intervene later.
Security can no longer rely solely on manual review as more systems become autonomous. Diamant-Cohen also noted that agents were nondeterministic, meaning they would not always produce the same answer or take the same path twice. That unpredictability makes it even more important to define what systems and agents are allowed to access, what actions are prohibited, how activity is monitored, and who is accountable when something happens.
“Governance is shorthand for ‘I need to be able to see everything, I need to have a list of allowed actions and forbidden actions, and I need someone to be accountable for every single action that has been taken in my cloud,’” Diamant-Cohen said.
In the agentic era, that definition is the basis for safe autonomy. Landing zones, zero-trust controls, data security policies, and continuous monitoring all give security leaders a way to say yes to AI-driven innovation without surrendering visibility or control.
For organizations building or expanding on AWS, the path to better security starts with discovery: what exists now, what controls are in place, and where governance needs refining. SHI works with AWS customers to turn that assessment into a long-term road map for secure, scalable cloud adoption.
