Cloud Hardening as a Proactive Defense Against Adversarial AI
AI compressed cloud reconnaissance from weeks to minutes. The architectural problems it exploits — tenancy, perimeter, and blast radius — were always there. This guide is about closing them with AWS-native primitives.
It's a Tuesday in 2026. An attacker has 90 seconds.
- 0:00An attacker drops a stolen access key into an LLM-driven agent.
- 0:15The agent enumerates 200+ IAM roles and parses every trust policy.
- 0:35It identifies three service roles with
iam:PassRoleinto a privileged role. - 0:55It generates the exact
aws sts assume-rolechain. Tests it. - 1:20Lateral move complete. Reads from S3 in a sibling account.
- 1:30The defender's GuardDuty finding hasn't fired yet.
This isn't science fiction. Open-source pentest frameworks paired with frontier models can do this work at this pace today. The question isn't whether attackers are using AI — they are. The question is what you do when your detection clock can't keep up.
Three things broke at once.
-
Attackers got AI.
Reconnaissance work that used to take a red team a week — enumerating IAM paths, parsing trust chains, finding misconfigurations — now happens in minutes. LLMs are excellent at parsing JSON IAM policies and chaining valid AWS API calls.
-
Defenders got more credentials.
Non-human identities — service roles, automation, third-party integrations, AI agents — now outnumber human principals 20–50 to 1 in a typical AWS organization. Every new agent is a new credential. Humans become a rounding error in your principal count.
-
Detection economics broke.
Mean-time-to-compromise has collapsed. Mean-time-to-detect, in most organizations, is flat. The gap between them is what attackers live in. Trying to out-detect AI-speed adversaries is a losing race.
Cloud has three structural problems. AI didn't create them — it weaponized them.
If you trace any modern cloud breach back through its stages, you'll find the same three architectural gaps showing up — alone or in combination.
Tenancy
Where is your trust boundary? Cloud accounts are a thin form of isolation — a developer's personal sandbox and an attacker's external account look the same to AWS unless you tell it otherwise.
Perimeter
Network perimeters protect compute. They don't protect the cloud control plane. Cloud APIs are public endpoints; valid credentials work from anywhere on the internet — the credential portability problem.
Blast Radius
What can a compromised identity actually do? AI moves this from an external-attacker problem to an insider one — every NHI and agent is now a potential adversary you've already authenticated.
The cloud trust model is implicitly permissive.
On-prem networks are isolated by default — you draw a network boundary with firewalls and stuff lives behind it. The trust model is physical. Either you're inside the perimeter or you're outside.
Cloud is the inverse. Every API endpoint is reachable from the internet. Every account in the world is one IAM call away from yours. The trust model is logical — and it's expressed entirely through configuration. There are two layers of trust, both implicit unless you make them explicit:
Implicit trust
A valid credential is sufficient. AWS doesn't care where the call came from, what device, what user, what time of day — by default. If the signature checks, the call proceeds.
Explicit trust
Cross-account assume-role, RAM resource shares, federated identity, S3 bucket policies that name external accounts. Every one of these is a deliberate handshake — but it's also a trust boundary you've widened.
Layered on top: the configuration surface itself. AWS has 200+ services, 15,000+ API actions, dozens of policy types, and conditions that interact in non-obvious ways. Most cloud breaches aren't exploits — they're misconfigurations. AI just makes finding them faster.
A compromised credential, end to end.
Here's how a single stolen credential becomes a multi-account data breach. Each step is enabled by one of the three architectural problems.
An EC2 instance with an IAM role is compromised (SSRF, malicious dependency, leaked GitHub key). The session token is exfiltrated to the attacker.
The attacker calls the AWS API from their laptop on a coffee-shop network. AWS accepts the call — there's no condition on source network, source VPC, or source IP. The cloud control plane treats every request the same.
The compromised role has iam:PassRole and sts:AssumeRole. The attacker chains into a more privileged role — one originally meant for the deployment pipeline. Now they're effectively an admin.
The privileged role can assume a role in a sibling production account — there's no organization-level boundary preventing it. The attacker reads customer data from S3 in the prod account. They never touched prod's perimeter directly; tenancy never enforced one.
Detection eventually catches the anomalous behavior. The data is already gone. The clean-up is a six-figure incident response bill plus regulatory disclosure.
Three of the four steps are architectural. None of them require an exploit. They require configuration — or rather, the absence of configuration that would make them impossible.
Where is your trust boundary?
In an on-prem world, tenancy is straightforward — you own the building. Networks isolate by physical reality.
In the cloud, tenancy is multi-layered and mostly logical:
- ▸Physical multi-tenancy — your VM may share hardware with another tenant. Mitigated by AWS, but not your concern.
- ▸Logical multi-tenancy — accounts and Organizations are the boundary. This is your concern.
- ▸External tenancy — every other AWS account in the world is one IAM call away from yours unless you say otherwise.
A developer's personal sandbox account and an attacker's account look identical to your AWS principals. Both are external. Both can be the destination of a cross-account assume-role, an S3 bucket grant, a RAM share. Without explicit organization boundaries, you treat them the same.
The six trust boundary problems of AWS Data Perimeters
AWS's Data Perimeter pattern names three dimensions of trust — identity, resource, and network. Each combines with the right policy mechanism (SCP, RCP, VPC endpoint policy) to close one trust gap. Here are six concrete scenarios — click each one to see which gate blocks it.
Interactive: click a scenario card to see which trust gate blocks the attack and why.
Cloud APIs are public endpoints. Your network perimeter doesn't apply.
When teams move to the cloud, they bring on-prem network thinking with them. They build VPCs. They split public and private subnets. They put WAFs in front of load balancers. All of that protects compute — the workload network surface.
It does nothing for the cloud control plane.
Every AWS API call goes to a public endpoint — s3.amazonaws.com, sts.amazonaws.com. There's no firewall between the internet and AWS. Whoever has the credentials can call them. This is the credential portability problem: a token works equally well from your prod VPC, your developer laptop, or an attacker's coffee shop.
Solution: conditional access via networking constructs
AWS gives you the primitives to bind API calls to network conditions. The pattern: deny any API call that doesn't originate from a VPC, VPC endpoint, or trusted IP range you own.
{
"Statement": [{
"Sid": "EnforceNetworkPerimeter",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddressIfExists": {
"aws:SourceIp": ["10.0.0.0/8", "203.0.113.0/24"]
},
"StringNotEqualsIfExists": {
"aws:SourceVpc": ["vpc-prod"]
},
"BoolIfExists": {
"aws:ViaAWSService": "false"
}
}
}]
}The result: stolen credentials are inert outside your trust boundary. The token still authenticates — but the call is denied at the control plane.
This is especially powerful for non-human identities
Humans are mobile. They work from home, hotels, and conference WiFi. Constraining them by source IP is operationally fragile.
Non-human identities aren't. A Lambda function only ever runs in your VPC. A container service role is always called from your ECS clusters. An automation pipeline calls from known runners. For NHIs, the trusted-network condition is essentially free — and NHIs are 95% of your principals.
AI made blast radius an insider problem.
Here's the shift that's least talked about: even after you've hardened tenancy and perimeter, the threat model itself has changed.
Pre-AI, cloud security focused mostly on external attackers. Detection was about catching the unauthenticated outsider. Once an attacker landed, blast radius was a secondary concern — most NHIs lived inside trusted boundaries and got the benefit of the doubt.
Post-AI, your NHI count exploded — every AI agent, every automation pipeline, every third-party integration is a new credential. Each one is now a potential adversary you've already authenticated. The threat moved inside the perimeter without anyone deciding to let it in.
Which means the question shifts from "how do we keep attackers out?" to "what damage can each principal actually do, and how do we structurally cap that?"
The IAM entitlement audit you're not doing
In a typical AWS organization:
- ▸40-60% of IAM policies grant action wildcards (
s3:*,ec2:*) - ▸Many service roles have
iam:PassRolewithResource: *— a privilege escalation primitive - ▸Third-party SaaS integrations were granted broad access at onboarding and never reviewed
- ▸Cross-account assume-role policies use
Principal: *with vague conditions - ▸Long-lived IAM users coexist with role-based access, both with stale permissions
An AI agent with a stolen credential can map all of this in seconds. The privilege escalation paths Bishop Fox and Rhino Security documented in 2018 still work — and now they're discoverable in real time.
Solution: structurally cap blast radius with SCPs
You can't write perfect IAM policies. You can write a policy of last resort that blocks the privilege escalation paths an attacker would actually use:
{
"Statement": [{
"Sid": "DenyPrivilegeEscalation",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:AttachUserPolicy",
"iam:PutUserPolicy",
"iam:CreateLoginProfile",
"iam:UpdateLoginProfile",
"iam:AddUserToGroup",
"iam:CreatePolicyVersion",
"iam:SetDefaultPolicyVersion",
"iam:UpdateAssumeRolePolicy"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/IAMAdmins*"
}
}
}]
}This SCP makes a whole class of privesc structurally impossible. An attacker with any role except your designated IAM admin role cannot escalate. Doesn't matter how broad their original permissions were — the SCP intersects.
Pair it with a destructive-actions SCP (denies bulk delete, GuardDuty disable, S3 bucket policy modification by non-admin roles), and the worst-case blast radius from any compromised NHI shrinks dramatically.
A five-phase ladder, mapped to the three problems.
You don't need to ship every control at once. The five-phase ladder below is a practical sequence — most organizations have phase 1 done implicitly via Control Tower, then stall. Climb one phase at a time.
| Phase | What it does | Solves |
|---|---|---|
| 1 · Foundation | Protect security services from being disabled (CloudTrail, GuardDuty, Config) | All three |
| 2 · Scope | Deny non-approved regions, services, and public-by-default resources | Tenancy, Perimeter |
| 3 · Hygiene | Mandatory tags, encryption, IMDSv2, no IAM users, no long-lived keys | Tenancy |
| 4 · Depth | Block privilege escalation primitives, restrict destructive actions | Blast Radius |
| 5 · Perimeter | Identity / resource / network trust boundaries (Data Perimeter) | Tenancy, Perimeter |
Every phase is implementable with AWS-native primitives — Service Control Policies, Resource Control Policies (GA late 2024), VPC endpoint policies, IAM conditions. No third-party tooling required to start.
Ten things to check tonight.
- 01Run IAM Access Analyzer against your org. Look at the public-resource and cross-account-access findings.
- 02Audit how many IAM users exist. Plan to delete them.
- 03Audit assume-role trust policies for
Principal: *or wide patterns. Addaws:PrincipalOrgIDconditions. - 04Check whether CloudTrail can be disabled by any non-admin role. Ship the SCP that says no.
- 05List every active AWS region. Deny the ones you don't use.
- 06Require IMDSv2 on EC2 launches. SSRF + IMDSv1 is exactly how Capital One happened.
- 07Block S3 buckets from being made public via SCP — even if a misconfig tries.
- 08Identify your privilege-escalation IAM actions and deny them outside your IAM admin role.
- 09Inventory every NHI. For each, ask: does it ever call AWS from outside our VPC? If no, scope it to your VPCs.
- 10Review your data perimeter. If you don't have one, AWS publishes example policies — start there.
References.
- AWS Data Perimeter — official pattern docs
- aws-samples/data-perimeter-policy-examples — production-ready SCPs and RCPs
- Resource Control Policies (RCP) — GA late 2024, the resource-attached counterpart to SCPs
- Rhino Security: AWS IAM Privilege Escalation — the canonical privesc path catalog
- IAM Access Analyzer — surfaces over-permissive policies and external access
- Pacu — AWS exploitation framework, useful for red-team validation
Written by the team at InstaSecure. We build a guardrails platform for AWS that operationalizes the techniques in this guide — but the techniques themselves are AWS-native and vendor-neutral. Everything here is implementable without InstaSecure. If you'd like help operationalizing it across a real AWS organization, reach out.