I analyze cloud environments for a living, which means I’ve seen the inside of enough of them to notice the patterns that repeat. Not the exotic, conference-talk vulnerabilities. The ordinary ones, the kind that are sitting in your account right now because they never quite made it to the top of anyone’s list. Here are five of them, and how Act can help with each.

1. Far too many identities can do far too much

Identities pick up managed policies because it’s the fastest way to unblock someone, and nobody circles back to narrow them. AdministratorAccess when one service would have done. AmazonS3FullAccess when one bucket would have done.

The real question isn’t whether everyone is trustworthy. It’s whether a single disgruntled person, a compromised laptop, or a leaked CI token should be able to do real harm to production, because that’s exactly what those policies quietly grant.

How Act can help: Act compares configured access against observed access for every identity, so you can rightsize the unused half in one move instead of reviewing roles one at a time.

2. Vendors you stopped using still have access

Off-boarding a vendor is one of those tasks everyone agrees is important and almost nobody actually does. The contract ends, the integration stays, and a third party you forgot about a year ago still holds an active role into your environment. The reflex defense is “it’s only read-only,” and that’s the part worth pushing back on. Read-only is read-everything. A stale read-only integration can still pull your data and sell it, and you’d never see a permission denied because nothing was denied. Go through your third-party roles and external access grants and ask, for each one, whether that relationship still exists. The ones that don’t should lose their access today.

How Act can help: Act uncovers every active third-party and cross-account role and flags the ones with no recent use. Then it turns that into a guardrail at the source: an SCP that denies sts:AssumeRole from every external account except the short allow-list of vendors you actually still work with.

3. Production is living in your management account

Migrations are a hassle, so production resources often get set up in the root account “just for now.” Before you know it, “now” becomes forever. The problem is that the management account is the one with the keys to everything else, so anything that goes wrong there doesn’t stay contained, it spreads to every account underneath it. It’s also the one account your guardrails can’t reach: service control policies don’t apply to the management account, so the boundaries that contain blast radius everywhere else simply aren’t there. You don’t have to fix this overnight. You do have to stop adding to it, and start moving the most sensitive production workloads into their own accounts with their own boundaries, so a bad day in one place doesn’t become a bad day everywhere.

How Act can help: Act maps what in the management account can actually reach production, then ring-fences those workloads behind boundaries of their own, so an attack in the root account can’t spill into every account underneath it.

4. The backups don’t get the same protection as the data

Teams put real effort into protecting production data and then leave the backups of that same data sitting with weaker controls, broader access, and no monitoring. Attackers know this, which is why backups are a favorite target: it’s the same data, guarded like it’s less important. Treat your backups as production. Lock down who can read, copy, and delete them, turn on the immutability and object-lock features your provider already offers, and make sure deleting a backup is at least as hard as deleting the thing it backs up.

How Act can help: Act finds every identity that can read, copy, or delete your backups and cuts that down to a small, named allow-list, so only known identities can touch them. When needed, it also guides you through moving backups into a dedicated account with its own guardrails, so a foothold in production can’t reach the copy that’s meant to save you.

5. You watch what comes in. You ignore what goes out

This is the one I saved for last, and it’s the one most worth changing how you think. Almost all the attention goes to ingress, what’s allowed into the environment, and almost none goes to egress, what’s allowed out. But the breach you actually care about ends with your data leaving, and if nothing is watching the exits, the most damaging step happens in silence. Start treating outbound paths as something you design on purpose: restrict where workloads can send data, log it, and get suspicious about traffic heading somewhere it has no business going. You have to start thinking like an attacker, and the attacker’s whole plan ends at the door marked out.

BTW, I’m not the only one saying this. It’s a standard that cloud providers are actively urging teams to adopt. In fact, AWS published a comprehensive guide, Prevent data exfiltration: AWS egress controls for cloud workloads, which echoes this exact urgency. They lay out a multi-layered blueprint designed explicitly to lock down data perimeters and ensure that even if an attacker or a compromised AI agent gains ingress, your data remains securely trapped inside the room.

How Act can help: Act maps every outbound path your workloads actually have, then turns “where data is allowed to go” into an enforced rule instead of a hope: egress limited to destinations you approved, held in place with your own network controls and SCPs, so traffic heading somewhere it has no business going can’t leave in the first place.

Five problems, one through-line

Notice what these have in common, because it isn’t the trigger. It’s not really five problems. It’s one, wearing five outfits. Every single item is about access, who and what can reach your data, and where it’s allowed to go once they have it. The over-powered admin, the forgotten vendor, the tangled management account, the soft backups, the open exits: none of them is an exploit. They’re all reach. They decide, before any attacker ever shows up, how far a single foothold gets to travel.

So the useful reframing is simple: stop chasing the endless list and start shrinking what any one identity, human, agent, or machine, can reach. Each of the five above is a place to begin this week, by hand and for free. When the list grows past what you can work through one role at a time, that’s where Act comes in.