AWS MCP Server OAuth 2.1 dropped the proxy on 9 July 2026, and dropped cross-account profile switching with it

Summary. AWS announced OAuth support for the AWS MCP Server on 9 July 2026, and the managed policy behind it, AWSMCPSignInOAuthAccessPolicy, was created at 06:57 UTC the same day and has not been edited since. OAuth-compatible clients now connect straight to https://aws-mcp.us-east-1.api.aws/mcp with no mcp-proxy-for-aws and no uvx in the loop. Access tokens last 1 hour, refresh tokens up to 12 hours, and both are rotated single-use. The catch sits in a boxed warning inside the Agent Toolkit guide: "Multi-profile switching requires SigV4 authentication with the MCP Proxy for AWS. OAuth authentication does not support this feature." For any team that works in more than one AWS account, that is the whole feature. A second gap matters just as much: AWS's other managed MCP server, Partner Central agents, is documented as SigV4 only, in us-east-1 alone, with a sendMessage rate limit of 2 requests per minute and 48-hour sessions. Two AWS MCP servers, two authentication models, and the docs disagree on how many OAuth condition keys exist.

What changed on 9 July 2026

Before this, connecting an MCP client to the AWS MCP Server meant running the MCP Proxy for AWS locally, which signed each request with SigV4 credentials from your ~/.aws/config. OAuth removes that hop. AWS Sign-In now acts as the OAuth authorization server, issuing scoped bearer tokens that the AWS MCP Server accepts directly.

The client list is specific: Claude Code, Cursor, Cline, Gemini CLI, Kiro and GitHub Copilot are named in the Agent Toolkit guide as OAuth-compatible. Kiro CLI needs version 2.11 or later. Clients that do not implement OAuth discovery need ?oauth=initialize appended to the endpoint URL.

Two flows exist. The interactive flow is OAuth 2.1 authorization code with PKCE, and it issues both an access token and a refresh token. The non-interactive client credentials flow authenticates with existing SigV4 credentials and issues an access token only, with expiresIn reported as 3597 seconds in AWS's own sample response. No refresh token is issued for that flow, so headless agents re-request a token every hour.

Permissions are two IAM actions, signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token, both granted by the managed policy. The AWS Sign-In User Guide adds one line worth reading twice: "If you authenticate as the AWS account root user, no additional IAM permissions are required."

The cross-account gap

The multi-profile feature exists because agents get asked cross-account questions. AWS's own documented use cases are "Compare Lambda invocation costs between my dev and prod accounts", "Check all S3 buckets across my three accounts for public access", and "Count EC2 instances across all my accounts."

That feature works by having the proxy inject an aws_profile parameter into the tool schema for call_aws, run_script, get_presigned_url and get_tasks, then strip it before forwarding, so the AWS MCP Server never sees it. Profiles are allowlisted at startup through --profile or AWS_MCP_PROXY_PROFILES, and it requires mcp-proxy-for-aws version 1.6.0 or later.

None of that survives the move to OAuth. The Agent Toolkit guide states that with OAuth "each session is bound to a single IAM role and switching accounts requires re-authentication."

Capability	OAuth 2.1 via AWS Sign-In	SigV4 via MCP Proxy for AWS
Local proxy required	No	Yes (mcp-proxy-for-aws 1.6.0+)
Per-call account switching	No	Yes, via aws_profile
Token lifetime	1 hour access, 12 hour refresh	Standard AWS credential lifetime
Client compatibility	OAuth 2.1 clients only	Any client that can run the proxy
Governed by	5 OAuth condition keys plus IAM	IAM only
Best fit	One developer, one account	Consultancies, MSPs, multi-account estates

For a services organisation that works inside client accounts, the second column is not legacy. It is the operating model. Read the announcement on its own and you would conclude the proxy is obsolete; read the multi-profile page and you find it is load-bearing.

The docs disagree about the condition keys

Governance is where the two AWS guides diverge outright.

The Agent Toolkit OAuth page lists four OAuth condition keys: signin:OAuthClientId, signin:OAuthRedirectUri, signin:OAuthGrantType and signin:OAuthClientAuthentication. It gives the last one three values: none, client_secret_basic and client_secret_post.

The AWS Sign-In condition keys reference lists five, adding signin:OAuthTokenType with values access_token and refresh_token, which is the key you need to scope revocation and introspection. For signin:OAuthClientAuthentication it says: "Currently supported value: none".

A policy written from the Agent Toolkit page that allows client_secret_basic would match nothing. Write your OAuth policies from the AWS Sign-In reference, not the Agent Toolkit page, and check the availability-by-action table there before you assume a key applies. signin:OAuthGrantType, for instance, is available only on signin:CreateOAuth2Token, so blocking the client credentials grant has to be written against that action alone.

Revoking a token does not stop the agent

This is the operational detail most teams will discover during an incident rather than before one.

AWS Sign-In auto-revokes refresh tokens when an IAM policy attached to the principal changes, when an IAM user or root password changes, or when the sign-in session is explicitly revoked. The RevokeOAuth2Token API revokes a refresh token. What it does not do is kill live access tokens. The AWS Sign-In troubleshooting section is direct about it: "Revoking a refresh token immediately prevents new access tokens from being issued. Existing access tokens remain valid until they expire (up to one hour)."

For immediate containment AWS tells you to write a deny policy on the aws:SignInSessionArn global condition key against the affected sign-in session. If your agent-compromise runbook says "revoke the token", it currently buys you a delay of up to 60 minutes, not a stop. Add the session-ARN deny statement to the runbook now, and rehearse it, because the CloudTrail CreateOAuth2Token event carries the signInSessionArn you will need to paste into it.

Dynamic client registration is allowlisted, which limits the blast radius in a useful way. AWS publishes 12 approved redirect URI patterns, and the list is a reasonable map of where agent traffic is expected to come from: localhost and 127.0.0.1, https://claude.ai/*, cursor://anysphere.cursor-mcp/oauth/callback, vscode://*, https://chatgpt.com/*, https://replit.com/, https://lovable.app/* and https://api.v0.dev/v1/mcp-servers/oauth/callback among them. Agents outside that list have to contact AWS support to register.

Partner Central agents MCP Server is a different animal

AWS now runs more than one managed MCP server, and they do not share an authentication story.

Property	AWS MCP Server	Partner Central agents MCP Server
Authentication	OAuth 2.1 or SigV4	AWS Signature Version 4 only
Endpoint	https://aws-mcp.us-east-1.api.aws/mcp and other Regions	https://partnercentral-agents-mcp.us-east-1.api.aws/mcp
Regions	Multiple	us-east-1 only
Managed policy	AWSMCPSignInOAuthAccessPolicy	AWSMcpServiceActionsFullAccess
Session lifetime	1 hour token, refreshed	48 hours absolute, not inactivity-based
Write safety	IAM permissions	Human-in-the-loop approval on every write

The Partner Central server has real limits that shape what you can build on it. The sendMessage operation is capped at 2 requests per minute sustained with a burst of 10; everything else gets 10 per minute with a burst of 20. Exceed either and you get error -32004. Uploads are capped at 3 files per message, 3.75 MB for images and 4.5 MB for documents, into an ephemeral write-only S3 bucket, and the S3 URI must carry a versionId. AWS's own sample query is "List my open opportunities with expected revenue over $50K", which at 2 requests per minute is a conversation, not a reporting pipeline.

The Partner Central docs also disagree with themselves. The getting-started page shows "protocolVersion": "2025-03-26" in its _meta example and "protocolVersion": "2024-11-05" in the clientInfo example a few paragraphs later, and it names two different hostnames, partnercentral-agents-mcp.us-east-1.api.aws and mcp.partnercentral.aws, for the same service. Pin the version your client sends and test it rather than copying whichever block you scrolled to first.

The one genuinely good pattern here is the approval gate. Every write operation raises a tool_approval_request SSE event and waits. That is the control we would want on any agent with CreateOpportunity and SubmitBenefitApplication in its permission set, and it is worth copying into MCP servers you build yourself. Our notes on MCP server hardening cover the rest of that checklist.

What to do this week

Decide which authentication model each agent needs before you migrate anything. If a single engineer works in a single account, OAuth is a clean simplification and you can delete the proxy. If your agents touch more than one account, keep the proxy, pin mcp-proxy-for-aws to a version at or above 1.6.0, and declare a read-only profile first in the list so an unqualified call signs with the least dangerous credentials.

Write the governance policy from the AWS Sign-In condition keys reference. Restrict signin:OAuthRedirectUri to localhost patterns if your agents run locally, restrict signin:OAuthClientId to the DCR ARNs you have approved, and use signin:OAuthGrantType on signin:CreateOAuth2Token if you want to forbid headless client-credentials access outright. Then confirm the policy actually fires, because the troubleshooting guide flags condition keys silently not applying to the action being evaluated as a known failure.

Update the incident runbook for the 60-minute access token window. And turn on the CloudTrail correlation: OAuth-authenticated API calls carry aws:SignInSessionArn, which is what lets you tie an unexpected s3:DeleteObject back to the agent session that issued it. The same discipline applies to any partial-consent OAuth model you are adopting elsewhere.

India-specific considerations

The Partner Central agents MCP Server runs in us-east-1 only, so an Indian partner using it for pipeline work is sending opportunity records, customer names and uploaded meeting transcripts to N. Virginia. Uploaded files land in an ephemeral write-only S3 bucket that AWS states is not retained permanently, but the transfer still happens. Where those documents contain personal data, treat the upload as a cross-border processing decision under the Digital Personal Data Protection Act 2023 and record it. AWS's own security note is worth taking literally: do not upload files containing credentials, secrets or other sensitive information.

FAQ

When did AWS add OAuth to the AWS MCP Server?

AWS announced OAuth support on 9 July 2026. The managed policy that grants it, AWSMCPSignInOAuthAccessPolicy, was created at 06:57 UTC on 9 July 2026 and remains at version 1 with no edits since. It grants two actions, signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token.

Can I switch AWS accounts in one OAuth session?

No. The Agent Toolkit guide states that multi-profile switching requires SigV4 with the MCP Proxy for AWS, and that OAuth sessions are bound to a single IAM role. Switching accounts under OAuth means re-authenticating. Teams working across client accounts should keep the proxy rather than migrate.

How long do the tokens last?

Interactive access tokens are valid for up to one hour and refresh automatically while the refresh token is alive. Refresh tokens last up to 12 hours, rotate on every use, and are single-use, so replaying one invalidates every token in that session. Client-credentials tokens last one hour with no refresh token.

Does revoking a token cut off a compromised agent immediately?

No. Revocation stops new access tokens being issued, but existing access tokens stay valid until they expire, up to one hour. AWS recommends applying a deny policy using the aws:SignInSessionArn global condition key against the affected sign-in session for immediate containment.

How many OAuth condition keys are there?

The two AWS guides disagree. The Agent Toolkit page lists four. The AWS Sign-In condition keys reference lists five, adding signin:OAuthTokenType for revocation and introspection, and it also narrows signin:OAuthClientAuthentication to a single supported value, none. Use the Sign-In reference.

Does the Partner Central agents MCP Server support OAuth?

The current Partner Central documentation describes SigV4 authentication only, with service name partnercentral-agents-mcp, in us-east-1, over TLS 1.2 or higher. It uses the AWSMcpServiceActionsFullAccess managed policy and the aws:IsMcpServiceAction condition key rather than the AWS Sign-In OAuth actions, so the two AWS managed MCP servers currently need two separate client configurations and two separate permission models.

What are the Partner Central rate limits?

The sendMessage operation allows 2 requests per minute sustained with a burst of 10. All other operations allow 10 per minute with a burst of 20. Exceeding either returns error code -32004, LIMIT_EXCEEDED. AWS advises exponential backoff with jitter. Sessions expire 48 hours after creation regardless of activity.

How eCorpIT can help

Agent authentication is where most MCP projects quietly acquire risk, because the convenient path and the governable path are rarely the same one. Our senior engineering teams design and harden MCP integrations, write the IAM and OAuth condition-key policies that actually fire, and build the approval gates that keep write operations reviewable. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified. If you are connecting agents to production AWS accounts, our MCP server development and integration work starts with the access model, not the tools. Contact us to talk it through.

References

1. OAuth support for the AWS MCP Server, AWS What's New, 9 July 2026.
2. OAuth 2.1 authentication for AWS MCP Server, Agent Toolkit for AWS User Guide.
3. AWS MCP Server, AWS Sign-In User Guide.
4. Sign-In with OAuth 2.0, AWS Sign-In User Guide.
5. AWS Sign-In condition keys reference, AWS Sign-In User Guide.
6. Multi-profile support, Agent Toolkit for AWS User Guide.
7. AWSMCPSignInOAuthAccessPolicy, AWS Managed Policy Reference.
8. Partner Central agents MCP Server, AWS Partner Central API Reference.
9. Getting started with the Partner Central Agent MCP Server, AWS Partner Central API Reference.
10. Configuration reference, AWS Partner Central Developer Guide.

Last updated: 21 August 2026.