Cloud Hardening Starts With Outcomes, Not Controls

What Changed in This Year's Planning Season

Most of my conversations with security leaders over the past few weeks have followed the same thread. Teams are building their 2027 plans, and they are planning against a threat model that looks nothing like last year's.

For the first time, the fastest-moving threats to the enterprise are machines, and they are operating both outside the organization and inside it. From the outside, attackers are using AI to find vulnerabilities and assemble novel attack chains at a pace that human-speed response cannot match. Patching and remediation processes were not designed for that clock, and that is assuming a finding is even surfaced. From the inside, autonomous agents act with their user's identity. They do not need to be malicious to be dangerous. An agent with a broad role and an ambiguous instruction can delete a database or open a path to sensitive data, and it can do it in a single API call.

Both cases produce the same problem. There is no time to respond. Once an issue surfaces, you are already in recovery mode.

This changes the fundamental playbook. Security teams know they have to move from watching to preventing, and the questions I hear now reflect that:

• "How do we stop an agent before it causes downtime?"
• "How do we make sure privileged actions only happen when they are necessary, and only after the reviews we require?"
• "When we are attacked, how do we keep the attacker contained so they cannot reach our sensitive data?"

These questions land at the worst possible moment, because security teams are also under real pressure from engineering. The same AI systems that create these risks are being adopted quickly, and for good reason: they are genuinely accelerating roadmaps. Slowing that adoption is not a viable strategy. A security team that becomes the reason AI adoption stalls becomes irrelevant. The only workable answer is to make the adoption safe, and do so quickly.

So the priorities are shifting. The same commitments keep appearing in every 2027 plan I see. Bake preventative controls into the cloud so accidental exposure cannot happen. Enforce least privilege so agentic identities cannot take destructive actions. Contain blast radius so an attacker who gets in cannot reach the systems that matter. Take ownership of the architecture.

Those commitments have a name. Some teams call it cloud hardening, others cloud security architecture, others secure-by-design cloud. Whatever the label, it is the initiative I see rising to the top of the list for 2027.

The Four Families of Controls You Already Have

The cloud's great advantage is flexibility. It hands enterprises thousands of building blocks that combine into almost any application you can imagine, and it lets teams move at a speed no data center ever allowed.

That flexibility has a cost. Building blocks assembled incorrectly leave enterprises and their data exposed. Which is why hardening is real work: you have to configure, manage, and operationalize the boundaries around and inside your cloud to reduce exposure and increase resilience.

The providers have already given you the material. Across identity, network, resource, and AI, there are hundreds of native controls built for exactly this purpose.

They are not switched on by default for a simple reason: every enterprise uses its cloud differently, so every enterprise needs different boundaries. And configuring them once is not enough either. Your use of the cloud changes as the business changes, and the providers keep shipping new services and new primitives. Hardening is an ongoing program.

So before starting, it is worth getting a clear picture of the four families of controls in your possession, and what each one actually governs.

Identity controls govern permissions and authentication: which actions each actor is allowed to take. They span human and non-human actors alike, agentic identities included.

Network controls govern reachability and connectivity: what can reach what, and what can be reached from the internet.

Identity and network are the familiar pair. Both predate the cloud, and most teams already have a working mental model for them.

Resource controls are newer, and less well understood. Cloud providers expose a data plane that sits outside your network path. Reading an object through a public S3 URL, for example, never traverses your VPC, and there is no caller identity in your account to evaluate. The request arrives over an AWS-managed network as an anonymous or externally authenticated caller. Resource controls govern that path: requiring authentication, restricting access to specific source IPs, or blocking public access outright.

AI controls are the newest of the four. They govern how agents behave and what information they can process: whether a given action can be invoked through an MCP server, for instance, or whether sensitive data can be passed in a prompt. Like the other three families, they are deterministic. That is precisely the point: they let you put fixed boundaries around systems whose behavior is probabilistic.

Combining the Families Into Outcomes

Think of the four families as raw ingredients. A dish takes several of them working together, and so does almost every hardening outcome worth stating in a sentence.

Two examples.

Restricting internet access to sensitive data. Network controls are the obvious starting point, and they close the network path. But the provider's data plane is exposed to the internet too, so resource controls are needed to close that path as well. And for the outcome to hold over time you need identity controls on top, because otherwise nothing stops someone from creating a new resource with permissive access tomorrow.

Preventing databases from being deleted through MCP servers. The obvious starting point here is an AI control. On AWS you can use the aws:ViaAWSMCPService condition key to deny actions arriving through any AWS-managed MCP server. But this key only sees AWS-managed MCP servers. Third-party and self-hosted servers do not set them. Covering those requires identity controls on the agentic identities behind them, because that is where every API call ultimately gets authorized.

This overlap is why the obvious control is so often not enough. Teams install one, believe they are protected, and remain exposed.

In my conversations, that failure almost always traces back to the same root cause: the program is organized around the controls that are available rather than the outcomes the team wants. When a security engineer picks up a ticket titled "enforce aws:ViaAWSMCPService," they will enforce that condition key. They are not going to go hunting for the third-party MCP server the key never sees. The ticket gets closed and the gap stays open. The same pattern shows up in internet accessibility, and in plenty of other places.

Outcome-first programs avoid this by construction. When the ticket reads "databases cannot be deleted through MCP servers," the engineer has to begin with research. Find every path that reaches the outcome, and only then choose a control for each path. It is more work up front, but it is the only way to get enforcement you can actually rely on.

That is the case for making outcomes the starting point. It also raises the obvious problem: mapping every outcome your environment needs is hard in itself, and a map with holes in it defeats the purpose.

A Model for Mapping Hardening Outcomes

From our work with cloud security teams at enterprises of every size, we have landed on a model that makes the mapping tractable. Two components that every cloud environment is built from, and three patterns of outcomes to apply to them.

Mapped properly, the two produce a detailed cloud security standard covering all of your hardening requirements, plus an architectural diagram of your cloud that shows visually which access patterns are permitted and which are not.

Actors and Zones

An actor is anything that acts in or on your cloud. An identity, a workload, a network path. A partner that assumes a role in your account. A vendor with third-party access. Or even an AI agent accessing databases. A group of related actors makes up an application: the virtual machine running the code, the database holding the data it needs, the VPC through which it reaches the internet.

A zone is a logical grouping of actors that share a property you care about: "production accounts," "HR systems," "PCI workloads." A zone can hold many actors, and your environment is a collection of zones, each of which may span one provider or several.

Perimeter, Segmentation, and Baselines

Perimeter outcomes govern external access: which vendors may connect into your cloud, whether internet access is permitted, and to what.

Segmentation outcomes govern access between the components you mapped. Zone-to-zone rules, like "production may never communicate with non-production," are macrosegmentation. Actor-to-actor rules are microsegmentation.

Baselines define the floor: the minimum configuration required inside each zone, and the actions each actor may and may not perform. This is where most agentic-identity outcomes live.

Zones Nest, and So Do Guardrails

Zones nest. Production may contain Finance, which may contain the payments applications. Guardrails should inherit downward, with exceptions that are explicitly scoped and time-bound. That is the mechanism that keeps a standard from decaying into a list of one-offs.

Nesting also gives you a natural order of work. Start broad, with perimeter access and the hard configuration baselines that should hold everywhere. Then refine perimeter rules and baselines zone by zone. Add segmentation between zones. Finish with granular, actor-level controls.

Baseline controls at the actor level are also known as least privilege. These are the controls that ensure that agents are not allowed to run wild, while segmentation restricts lateral movement, and perimeter restricts inbound and outbound access. Only together can cloud attacks be fully stopped.

That order matters, because it gives you coverage early and precision later, instead of spending six months on microsegmentation while the perimeter is still open.

Why Hardening Programs Stall

Cloud hardening is hard, and the reason is worth naming. The controls are not the missing piece. The providers have shipped them, and they keep shipping more. The difficulty is that the space of possible outcomes is large, the controls that deliver any one outcome are scattered across four families and multiple providers, and nothing tells you when your map has a hole in it. That is what makes hardening feel unbounded, and it is why so many programs quietly collapse into whichever controls happen to be easiest to turn on.

Constructs are what make it bounded. Once you can name your actors and draw your zones, and once every requirement is written as a perimeter, segmentation, or baseline outcome, the work stops being an open-ended search and becomes a finite grid: each pattern applied to each zone, and down to each actor. You can see which cells are filled and which are empty. You can hand the map to an auditor, an engineering lead, or a new hire and have them understand it. And when the business changes, you add a row rather than restarting the program.

The map is what turns a pile of controls into a cloud you can reason about. If you are building your 2027 plan around this, I would like to hear how you are approaching it, and how you map all potential hardening outcomes. That is where every team I talk to spends the most time.

If you are mapping hardening outcomes for your own 2027 plan, you can see how we approach actors, zones, and the enforcement behind them here.