Three perimeters, six questions

AWS frames the data perimeter as three boundaries, each enforced in two directions. The identity perimeter: only trusted identities can access your resources, and only trusted identities are allowed from your network. The resource perimeter: your identities can access only trusted resources, and only trusted resources can be reached from your network. The network perimeter: your identities can reach resources only from expected networks, and your resources can be reached only from expected networks. Six control objectives, enforced with three policy types — SCPs on the identity side, RCPs on the resource side, and endpoint policies on the network side.

Trusted has precise definitions. Trusted identities are the principals in your accounts, plus AWS services acting on your behalf. Trusted resources are the resources your accounts own. Expected networks are your VPCs and on-premises ranges. The example policies express those definitions with organization IDs, account lists, VPC IDs, and corporate IP ranges — the values you substitute in when you deploy them.

Why writing it is not proving it

A deployed perimeter is not one policy. It is an SCP at one organizational unit, an RCP at another, an endpoint policy on each VPC, a resource policy on the buckets that predate RCP support, and a web of conditions and exception tags threaded through all of them. The guardrails interact, they span every account in the organization, and several of them turn on values that exist only at request time — the source VPC, the source IP, a principal tag, a resource tag. Reading two hundred policy statements does not tell you who actually slips through the seams where they meet.

This is the same wall the conditional-access label runs into: a scanner that reads policies at rest sees the conditions but cannot resolve them, so the cross-cutting result comes back as conditional rather than as a list. The way through is to stop reading the policies and start asking the perimeter questions as queries — evaluating the whole chain, across accounts, with the runtime values supplied.

Prove each boundary with a query

Take the boundaries one at a time and pair each with the question that proves it. Start with the identity perimeter — only trusted identities should reach your resources. The proof is the empty result to its inverse: every principal that can read a sensitive bucket, filtered to those whose account is outside your organization.

Identity perimeter: external identities that can reach your data

Compute everyone who can read the buckets, then keep only the principals whose account is not in your organization. An empty result is the identity perimeter holding; any name is an external identity the resource-side controls did not stop.

readers = who-can(
    action: "s3:GetObject"
    resource: var:sensitive-buckets
)

readers where self.account() not in var:org-accounts

The resource perimeter is the mirror image of that query — your own identities reaching a resource outside the organization — proven the same way, with the populations flipped. The network perimeter is a different shape: it turns on a condition, the source network, so it becomes a parameter. Pin a source that is not one of your VPCs and ask who still gets through.

Network perimeter: access from outside the expected network

The network perimeter policies turn on aws:SourceVpc and aws:SourceIp. Supply a source that is not one of your VPCs and the chain is re-evaluated under it. Names on the list are principals the network perimeter does not actually constrain.

who-can(
    action: "s3:GetObject"
    resource: var:sensitive-buckets
    env: {"aws:sourcevpc": "vpc-untrusted"}
)

The governance trap: who can leave the perimeter?

The example policies carve out exceptions with tags — a principal tagged dp:exclude:identity is exempt from the identity perimeter, dp:exclude from all of it. That is a deliberate and necessary feature. It is also the biggest blind spot in the perimeter, because the exception is only as strong as control over the tag. A principal that can set dp:exclude on itself can walk straight out of every boundary you built. The AWS governance policy examples exist precisely to lock those tags down, which makes the audit question simple: who can write them?

Who can tag a principal out of the perimeter

The governance SCP is meant to restrict the exclusion tags to perimeter administrators. This proves it: everyone who can tag a role, minus the administrators who are supposed to. Anyone left is a way out of the perimeter.

perimeter-admins = principals where self.Tags has (
    self.Key == "team" & self.Value == "admin"
)

taggers = who-can(
    action: "iam:TagRole"
    resource: roles
)

taggers where self not in perimeter-admins

Every boundary, one verdict

Each boundary the example set defines becomes a query whose empty result is the proof and whose non-empty result is the exact gap: an external identity that still reads your data, one of your own roles that can push to a resource you do not own, a principal that reaches you from an unexpected network, an account that can tag itself out of the perimeter. Save each one as a monitor and the verdict is re-checked on every refresh — so the perimeter is something you can prove holds today and know the moment it stops.

What the perimeter does not cover

Two honest boundaries. First, a data perimeter is a set of IAM authorization controls — AWS is explicit that it does not cover network traffic inspection or encryption, and neither does evaluating it. Proving the authorization side holds is not the same as proving a packet cannot leave; the network and data controls AWS keeps separate are still yours to run. Second, the perimeter inherits the health of your fundamentals — account structure, tagging discipline, change management. A query proves that the policies you have evaluate the way you intend; it cannot invent a guardrail you never wrote.

The takeaway

A data perimeter is the rare control that is genuinely preventive — it stops the access instead of alerting on it afterward. That is exactly why it is worth proving rather than assuming. You already did the hard part of writing the policies. Turn each boundary into the question it is meant to answer, evaluate it across the whole organization, and read the verdict: empty, or the precise list of what still gets through.

Why the graph stops at "conditional access"

Graph-based CSPMs ingest cloud state on a schedule. At ingest time they capture the permissions of each principal and the conditions attached to them, and they label the resulting graph edge accordingly. The trouble is that conditions resolve against values that only exist at request time: the actual MFA state of the session, the source IP, the request or object tag, the encryption context. None of those exist when the graph is built, so the graph cannot say whether the condition would pass. The safest thing it can report is "access exists, conditional on X" — and leave you to work out by hand which principals actually have access in which contexts.

For an access review or a regulator, that is not an answer. "Conditional access" is a deferral, and under time pressure it gets rounded to "probably blocked." The cases where it would not have been blocked are precisely the ones that become incidents.

Evaluate the decision, do not store it

The alternative is to compute the authorization decision at query time instead of reading it off a snapshot. In that model a condition is not an ingested fact — it is a parameter you supply. Whocan does this with an env: argument: you pin the condition value you care about, the full policy chain is re-evaluated under that assumption, and the result is a definitive list of principals rather than a label.

Ask the question the graph deferred — who can read this bucket from outside our corporate IP range — and pin the source IP as the value to test:

Access from an untrusted source IP

The source IP is supplied as a parameter; the chain is re-evaluated as if the request came from there. An empty result means the IP condition holds. Names on the list are the gap.

external-ip = "203.0.113.42"

who-can(
    action: "s3:GetObject"
    resource: var:critical-bucket
    env: {"aws:sourceip": external-ip}
)

The same mechanism answers every other condition family — what if MFA were absent, what if the request came from outside the production VPC, what if the session carried a different principal tag. The condition is just a value you set.

The tags the graph never indexed

Two of the conditions a static graph handles worst are the ones modern architectures lean on hardest: resource tags and object-level tags. A reachability graph can only search what it ingested, and it does not index per-object S3 tags — a bucket can hold billions of objects, and a tagging-API call per object does not scale. So tenant isolation and data classification built on object tags collapse to "conditional access" too. The tool reads the bucket policy correctly, sees the s3:ExistingObjectTag condition, and stops there, because it cannot know the tags on any given object.

Who can read objects of one classification

The object tag is supplied as a parameter, so no per-object scan is required. Change the value to compare classifications — the difference between the two results is your access boundary.

project-tag = "Secret"

who-can(
    action: "s3:GetObject"
    resource: var:sensitive-bucket
    env: {"s3:existingobjecttag/project": project-tag}
)

DynamoDB row-level isolation between tenants

The textbook multi-tenant pattern. An empty result is audit-grade proof that the principals of tenant A cannot read the rows belonging to tenant B — the answer a "conditional access" label can never give.

foreign-tenant = "tenant-b"

who-can(
    action: "dynamodb:GetItem"
    resource: var:multi-tenant-table
    env: {"dynamodb:leadingkeys": foreign-tenant}
)

The shift is the whole point: a query engine does not try to know your data, it knows your authorization rules. A tag value is an input to the decision, not a fact to be scanned. The same machinery that answers the MFA question answers the object-tag question, because both are values supplied at evaluation time.

The same gap, organization-wide

The conditional label has a structural cousin one level up. The AWS data perimeter — the SCPs, RCPs, and endpoint policies that keep access inside trusted identities, trusted resources, and expected networks — is enforced across every account in an organization, and whether it actually holds is the same cross-account, condition-dependent question. It is large enough to deserve its own treatment, which it gets in the companion post, "You wrote the data perimeter. Can you prove it holds?"

What "conditional access" becomes

Every condition family is a parameter, not a label: MFA presence, source IP, source VPC, principal and resource tags, S3 object tags, DynamoDB leading keys, KMS encryption context. Pin the value you care about and the answer is an exact list — empty means the control holds, a name means it does not. Save any of these as a monitor and the question is re-checked on every refresh, so the answer stays current instead of aging with the last scan.

Where a graph still wins

This is a deliberate boundary, not a claim to do everything. A graph-based platform that scans workloads, network, and data gives you things a query engine does not: agentless vulnerability scanning across the fleet, end-to-end attack-path visualization spanning network, workload, and identity, data classification, and a single multi-cloud view. Whocan is an IAM authorization specialist — it answers who can actually do this, given these exact conditions, with a precision a reachability graph structurally cannot, and it is AWS-deep today rather than broad across clouds. The two are complementary: reach for the platform when the question spans the whole stack, and for the engine when the question is an authorization decision that turns on a condition.

The takeaway

"Conditional access" is the polite form of "we cannot tell you." For anyone who has to produce a yes or a no — an access reviewer, an auditor, a regulator — that label is the difference between an answer and an investigation. The conditions are not a footnote to the question; they are the question. Supply the value, evaluate the decision, and read the list.

Bedrock removes the safety net you rely on everywhere else

On S3, an over-broad identity policy can still be stopped by a restrictive bucket policy. On KMS, the key policy has the final say. Those resource-side controls are the reason a single mistake on the identity side is usually survivable — something else gets a vote. Per the AWS IAM documentation, Bedrock has none of that: no resource-based policies, no ACLs, no resource-side control that could veto an over-broad grant. What a principal can do to a model or an agent comes down to its identity policies, the SCPs above it, and the conditions on the request, and nothing else.

That is an unusually clean problem for identity-side analysis to own. There is no second policy layer to reconcile, no question of whether the bucket policy or the IAM policy wins. The question of who can invoke a given model resolves from the same chain Whocan already evaluates for human users — identity policies, permission boundaries, SCPs, and conditions — to the decision AWS itself would make.

Three questions to ask about every agent

Bedrock agents run under customer-managed service roles: IAM roles you create and hand to the agent. AWS warns against editing them casually, because changing their permissions can break the agent — but nothing warns you about a role that was over-granted the day it was created. These three questions give every agent role a list it can be reviewed against.

Who can invoke Bedrock models?

There is no model-side policy to backstop you. This is the full set of principals, human and non-human, that can reach a model — computed from identity policies, SCPs, and conditions alone.

who-can(
    action: "bedrock:InvokeModel"
)

Which agent roles have human-grade privileges?

An agent role should be scoped to the few actions its task needs. Any agent that computes to admin, or holds a privilege-escalation sequence, is a non-human identity with far more reach than its job requires.

agent-roles = roles where self.Tags has (
    self.Key == "workload" & self.Value == "ai-agent"
)

admin-agents = agent-roles
    where self.Entitlements.Abilities includes "iam-admin"
privesc-agents = agent-roles
    where self.Entitlements.Abilities includes "iam-privilege-escalation"

admin-agents union privesc-agents

Who can both rewrite and run an agent?

AWS splits the Agents API into a build-time plane and a runtime plane. A principal holding both can rewrite the action group an agent runs, then trigger it — inheriting everything that agent role can do. It is the Lambda-code-injection pattern, moved to agents.

agent-builders = who-can(
    action: "bedrock:UpdateAgentActionGroup"
)

agent-invokers = who-can(
    action: "bedrock:InvokeAgent"
)

agent-builders where self in agent-invokers

Same engine, new principals

Each of these runs through the identical authorization chain Whocan uses for human IAM — every SCP, every condition, every role hop. An agent that can read a production secret, a service role that quietly computes to admin, a build-plus-runtime toxic combination: all of them are standing facts, knowable before the agent makes its first call. Save any of these as a monitor and the answer is re-checked on every refresh.

AWS tells you to build the wall. It cannot tell you if there is a door.

The Bedrock hardening guidance is good and worth following. Route model and agent traffic through PrivateLink interface endpoints; scope those endpoints with a policy that allows only the actions you intend; and for model-customization jobs, lock the training-data buckets behind a Deny-unless-it-comes-from-your-VPC bucket policy keyed on aws:sourceVpc. Each of those is a wall.

A wall is only as good as the absence of a door around it. The question worth asking is not whether you wrote the Deny policy — it is whether any principal still reaches this bucket from outside the VPC, through a path the policy did not anticipate. That is conditional and context-dependent: it turns on the source VPC, on which role is asking, on the conditions attached at every layer in between. Source-VPC, MFA, and request context are exactly what who-can factors in, so whether the wall actually holds is something you can ask directly instead of inferring from the policy text.

The takeaway

An AI agent is not just a feature you ship — it is an IAM principal you create, with standing access that outlives any single request. Treat it like one. Before it makes its first call, ask what its role can reach, whether anyone can rewrite and re-run it, and whether the perimeter you drew around its data actually holds. Bedrock gives you no resource-side net to catch these later; the identity side is where the question lives, which makes it where the answer is too.

What happened

As reported by BleepingComputer in March 2026, the attacker exploited a React2Shell vulnerability in a frontend ECS container and pulled the task role credentials from the instance metadata endpoint. That part is routine — containers get compromised. What turned a contained incident into a 3.9 million record breach was what that role was allowed to do.

1. A React2Shell vulnerability was exploited in the frontend ECS container.
2. Task role credentials were read from the metadata endpoint.
3. secretsmanager:GetSecretValue worked against every secret in the account.
4. 53 secrets were retrieved in plaintext, including the Redshift master credential.
5. The attacker connected to Redshift with that master credential.
6. 536 tables and 3.9 million records were exfiltrated — about 2 GB.

A rendering layer was granted account-wide access to the secrets store. That is not a flaw you patch on a Tuesday — it is a permission someone granted, and it sat there waiting for any code path into that container.

The blast radius was a standing fact

Blast radius is the set of things a principal can reach if it is compromised. For this task role it was the entire Secrets Manager store, and through the Redshift master credential, 536 production tables. None of that required predicting React2Shell. It is computable at rest, from the permissions alone — the only question you had to ask was what each service role can touch.

Three questions would have put this role on a list it had no business being on.

Who can read production secrets?

The single query that would have prevented the breach.

who-can(
    action: "secretsmanager:GetSecretValue"
    resource: secrets
)

Non-admin roles reading secrets

A frontend app role should never appear in this result.

admin-roles = roles where self.Entitlements.Abilities includes "iam-admin"

secret-readers = who-can(
    action: "secretsmanager:GetSecretValue"
    resource: secrets
)

secret-readers where self not in admin-roles

Who can reach the Redshift master credential?

Only DBAs and the Redshift service role belong here.

who-can(
    action: "secretsmanager:GetSecretValue"
    resource: secrets where self.Name ~ /redshift|master|prod/i
)

What Whocan would have surfaced

The frontend task role shows up in the secret-readers set and is flagged as a non-admin role reading production credentials. Its blast radius — every secret, then the Redshift master credential, then 536 tables — is computed as an entitlement before any exploit. And a continuous monitor on secrets access fires the moment any new role is granted GetSecretValue, so the over-grant is caught when it is made, not after the leak.

Least privilege is a blast-radius question

The lesson is not patch faster. You should patch faster, and you should also assume the container will fall anyway. The durable fix is to shrink what a compromised role can reach: scope the task role to the one or two secrets the application actually uses, and every other secret becomes unreachable even after the container is owned. Least privilege is not a paperwork exercise — it is the difference between an incident and a breach.

• ECS task role with broad secrets access — who-can(action: "secretsmanager:GetSecretValue").
• Non-admin role reading production credentials — entitlement analysis with admin exclusion.
• Access to the Redshift master credential — scoped who-can on specific secrets.
• Blast radius of an ECS role compromise — entitlement computation for task roles.
• New secret access granted — continuous monitor on secrets access.

The takeaway

Assume every internet-facing service will be compromised at some point. The question that decides whether that is a shrug or a headline is what its role can reach. Ask it before the attacker does: who can read production secrets, and does anything on that list have no reason to be there?

What happened

The entry point was mundane: long-lived credentials sitting in a public S3 bucket alongside RAG training data. From there the attacker did not exploit a vulnerability in the usual sense. It used permissions that were already granted.

1. Found credentials in a public S3 bucket (RAG data).
2. Used lambda:UpdateFunctionCode to inject code into an existing Lambda function.
3. Called iam:CreateAccessKey to mint keys for an admin user.
4. Moved laterally across 19 principals — 5 users, 6 roles, 14 sessions.
5. Assumed the cross-account OrganizationAccountAccessRole.
6. Created a backdoor admin user and launched GPU instances for LLMjacking.

Sysdig caught the activity at runtime — that is what runtime detection is for, and it worked. But by the time an alert fires, the attacker is already inside the path. The more interesting question is the one you can ask before any of this: who could have walked this route?

The path was queryable before there was an attacker

Each step above corresponds to a permission relationship that was true at rest. A principal that can rewrite the code of a Lambda inherits whatever that function execution role can do. A principal that can create access keys for another user inherits the privileges of that user. Chain those together and you have a privilege-escalation sequence — one that no single policy review reveals, because no single policy is wrong on its own.

These are exactly the questions Whocan is built to answer. Three of them would have surfaced the entire route.

Who can modify Lambda code?

The initial escalation vector — and a known, enumerable attack path.

who-can(
    action: "lambda:UpdateFunctionCode"
    resource: lambdas
)

Who can create access keys for other users?

Every principal that can mint new long-lived credentials for someone else.

who-can(
    action: "iam:CreateAccessKey"
    resource: users
)

Full privilege-escalation chains

The Lambda-plus-execution-role chain, flagged as a critical sequence rather than two unrelated permissions.

users where self.Entitlements.Abilities includes "iam-privilege-escalation"
    map { Name, Arn, Sequences: self.Entitlements.Sequences }

What Whocan would have surfaced

The Lambda-to-admin escalation chain appears as a single critical sequence, before exploitation — not as five separate permissions that each look reasonable in isolation. The cross-account OrganizationAccountAccessRole assumption shows up in the transitive assume-role graph, and a new backdoor admin trips the admin-population drift monitor the moment it is created.

Detection and prevention are different jobs

Whocan does not replace runtime detection — it closes the IAM gap before runtime detection ever has to fire. Mapped against the attack chain, every step was knowable as a standing access fact:

• User with Lambda write access — who-can(action: "lambda:UpdateFunctionCode").
• Lambda-to-admin escalation chain — critical sequence detection.
• CreateAccessKey for other users — credentials-access entitlement.
• Cross-account role assumption — transitive assume-role graph.
• Backdoor admin user created — admin population drift monitor.

The takeaway

Eight minutes is not a lot of time to respond. The good news is you do not have to win that race if you have already closed the path. Audit the route, not the alert: ask who can reach admin, through which hops, before an attacker asks the same question with worse intentions.