✓ Human-authored analysis; AI used for formatting and proofreading.
On July 9, 2026, AWS introduced OAuth support for the AWS MCP Server. The announcement describes a new action namespace (signin:), new condition keys, and a new resource type. It shipped with a managed policy (AWSMCPSignInOAuthAccessPolicy) ready to attach.
The mechanism is straightforward: an agent authenticates to the AWS Sign-In token endpoint using SigV4 credentials. The same credentials an EC2 instance profile or Lambda execution role already has and receives a short-lived OAuth access token in exchange. The agent then uses that token to access the AWS MCP Server.
The OAuth flow is well-designed. But it changes the IAM surface in ways that deserve immediate attention, because every IAM policy with Action: "*" or Action: "signin:*" now implicitly grants OAuth agent authorization.
The New Actions
Two actions control the OAuth flow:
-
signin:AuthorizeOAuth2Access— interactive authorization code flow (browser-based) -
signin:CreateOAuth2Token— token issuance (authorization code exchange, refresh, or client credentials)
Two more support token lifecycle management:
-
signin:IntrospectOAuth2Token— check token status -
signin:RevokeOAuth2Token— revoke a token
All four target a new resource type:
arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com
The Condition Keys That Matter
AWS introduced two OAuth-specific condition keys:
-
signin:OAuthRedirectUri— where the authorization response is delivered -
signin:OAuthGrantType— which OAuth flows are permitted
The blog post includes a restrictive policy example:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"signin:AuthorizeOAuth2Access",
"signin:CreateOAuth2Token"
],
"Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com",
"Condition": {
"StringLike": {
"signin:OAuthRedirectUri": "http://localhost:*"
},
"StringEquals": {
"signin:OAuthGrantType": [
"authorization_code",
"refresh_token"
]
}
}
}]
}
This is the policy AWS recommends for local development. Notice what it restricts: redirect URI to localhost, grant types to interactive flows only.
What the Managed Policy Does
AWSMCPSignInOAuthAccessPolicy grants the two primary actions. AWS provides it so administrators can attach it without writing custom policy. The question is whether the identities it gets attached to are the right ones.
An EC2 instance role with AdministratorAccess that also has this policy attached can now issue OAuth tokens that carry its full permission scope. The role was already powerful. The OAuth token makes that power delegatable to an agent process that may not have the same operational controls the role was designed for.
The Implicit Grant Problem
Here is the IAM surface change that most organizations will miss.
Before July 9, a policy with Action: "*" granted every AWS action across every service. After July 9, that same policy also grants signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token. The policy did not change. The set of actions it covers changed.
The same applies to Action: "signin:*". Any policy that used the signin: namespace for console-related actions now also grants OAuth agent authorization.
These are not misconfigured policies. They are policies that were correct last week and have a different meaning this week. The identity that has them may not know it can now authorize agents to act on its behalf.
What Defenders Should Check
Which identities have OAuth capability? Audit for signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token including grants via signin:* and *. The identities that have these permissions may not be the ones you want authorizing agents.
Are redirect URIs constrained? Without a signin:OAuthRedirectUri condition, OAuth tokens can be delivered to arbitrary endpoints. This is a token theft vector regardless of which grant type is used.
Is the resource scoped? A policy with Resource: "*" permits authorization against any service principal in the signin: namespace — current and future. Scoping to arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com limits authorization to the MCP Server specifically.
Can anyone revoke tokens? If OAuth tokens are being issued but no identity in the account has signin:RevokeOAuth2Token, compromised tokens cannot be revoked. The same applies to signin:IntrospectOAuth2Token — without it, defenders cannot inspect token status during incident response.
What's the blast radius of delegation? The real risk is not which grant type is used. client_credentials is the intended grant for machine-to-machine flows — an EC2 instance converting SigV4 to OAuth is the documented use case. The risk is when the identity that can delegate has permissions far beyond what the agent task requires. An admin role issuing OAuth tokens creates a path where an agent operates with full admin scope.
The CloudTrail Angle
OAuth authorization events — AuthorizeOAuth2Access, CreateOAuth2Token, token revocations are recorded in CloudTrail. This is good for detection. It also means that if your CloudTrail destination bucket is compromised (the bucket hijacking vector), the OAuth audit trail goes with it.
Organizations that already monitor CloudTrail for IAM credential use should extend their detection to cover the signin: event source. Token issuance patterns — which identities are issuing tokens, how frequently, from which source IPs — are the new signal to baseline.
What This Changes About IAM Reviews
Every IAM review process that inventories dangerous actions needs to add the signin: namespace. The standard lists (iam:*, s3:*, kms:*, sts:AssumeRole) now have a peer: signin:CreateOAuth2Token is a credential-issuance action with the same architectural significance as sts:AssumeRole.
The difference is that sts:AssumeRole has been in every security team's mental model for years. signin:CreateOAuth2Token was introduced this week. The policies that grant it already exist — they just didn't grant it until now.
Automated Detection with Stave
Stave is an open-source CLI that evaluates cloud configuration snapshots against a catalog of security controls. It ships with eight controls purpose-built for the OAuth MCP Server surface, covering each of the checks described above:
Wildcard and implicit grants — Detects identities that acquired OAuth capability through Action: "*" or Action: "signin:*" rather than explicit grants. These are the policies that changed meaning on July 9.
Redirect URI constraints — Flags signin:AuthorizeOAuth2Access grants that lack a signin:OAuthRedirectUri condition, the token-delivery vector that matters regardless of grant type.
Resource scoping — Identifies OAuth grants with Resource: "*" instead of the specific MCP service principal ARN.
Delegation blast radius — Surfaces identities that combine signin:CreateOAuth2Token with admin or elevated permissions — the over-privileged delegation path.
Token lifecycle gaps — Flags accounts where tokens are being issued but no identity has signin:RevokeOAuth2Token or signin:IntrospectOAuth2Token, leaving defenders without revocation or inspection capability during incidents.
Managed policy tracking — Inventories AWSMCPSignInOAuthAccessPolicy attachments so teams can review which identities received the AWS-provided OAuth grant.
OAuth inventory — Surfaces every identity with any signin: OAuth action, giving defenders a complete picture of which identities participate in OAuth delegation.
Stave evaluates these controls against point-in-time snapshots of IAM configuration, so they can run in CI, on a schedule, or as a one-off audit. The controls are declarative YAML. Teams can inspect the detection logic, adjust thresholds, or extend the catalog for their own policies.
Top comments (0)