Issue #269

Monday · July 13, 2026

🥖 Palate Cleanser

I wouldn't typically share this but because it was an "isolated matter" and "there is no impact to Accenture operations", I thought it was safe to do so. Apparently Accenture had 35 GB of data walked, (allegedly) including Azure PATs (personal access tokens) and Azure Storage access keys. Since this is an AWS newsletter I can only assume those credentials are unimportant to operations. 🙃

AWS added OAuth support to its MCP Server this week to meet agents' need to act on a user's behalf without being handed long-lived AWS credentials, so now they trade SigV4 creds for a short-lived, scoped OAuth token. OAuth drags in its own vocabulary of authorization codes, refresh tokens, scopes and service principals, and getting it wrong hands someone a token that acts as one of your identities. One of this week's Chef's Selection picks walks through how the four new signin: actions quietly reshape what your existing IAM policies already permit, so this is the week to learn the concepts.

A couple of weeks back we introduced ASD's The Top 10 AWS Security Research of 2026 and asked for nominations. We already have 12 nominations but we need more. Keep them coming.

📋 Chef's selections

The Two Mitigations for the Service Account Confused Deputy in the Cloud

by Kat Traxler

A confused deputy is just some service with more access than you, tricked into doing the thing you couldn't do yourself. Kat walks through the only two places you get to stop it: at attach time, by controlling who can bind an identity to a workload (iam:PassRole in AWS), or at call time, by making the provider verify the request itself (Forward Access Sessions, aws:SourceAccount). The part people miss is that iam:PassRole is a one-shot check. It fires when the role gets attached and never again, so from then on the workload just pulls tokens from the metadata endpoint and nobody re-asks whether that was ever OK.

AWS Just Added OAuth to the MCP Server. It Silently Changed the Meaning of Your Existing IAM

by Bala Paranj

When AWS gave the MCP Server OAuth support it also shipped four signin: actions for issuing and revoking tokens, and this post makes the uncomfortable point that they landed inside a namespace your policies already cover. Any statement granting signin:* or a bare * now silently authorizes minting an OAuth token via signin:CreateOAuth2Token against the aws-mcp.amazonaws.com service principal, no policy edit required. It ships with a detection tool (Stave) and CloudTrail detection guidance to find who can already do this in your account, which is more homework than most "the sky is falling" posts bother with.

Agent Solves All 122 of Pathfinding.cloud Labs

by Eduard Agavriloae

Eduard (organizer of the Top 10 AWS Security Research) built an autonomous offensive agent, handed it the near-empty starting hand of sts:GetCallerIdentity and iam:GetUser, then turned it loose on all 122 of Datadog's Pathfinding Labs, a public set of deliberately broken AWS environments. It captured every flag, averaging nine turns a lab, and it wasn't a frontier model doing the work: a ~35B open-weight model grounded in the team's offensive knowledge graph was enough. The labs that took longest were the ones without public exploitation playbooks (SageMaker, Cognito Identity, App Runner, Batch), which doubles as a fair map of where the non-obvious privesc paths still hide.

🥗 AWS security blogs

🍛 Reddit threads on r/aws


🤖 Dessert

Every machine-tracked change this week. Nobody else assembles this.

🧁 IAM permission changes

No changes this week.

🍪 API changes

🍹 IAM managed policy changes

☕ CloudFormation resource changes

🎮 Amazon Linux vulnerabilities

📺 AWS security bulletins

🚬 Security documentation changes

Get every AWS security change,
on a plate every Monday.

6,700+ engineers, builders and CISOs let us diff the AWS changelog every week.