AWS MCP Server Now Supports OAuth: How to Stop Your AI Agents Running on Long-Lived AWS Keys

Every engineering team that wired an AI coding agent into AWS over the last eighteen months solved the credentials problem the same way: they put an access key on a laptop and moved on. It worked, it took ten minutes, and it quietly created the worst kind of security debt, the kind that does not page anyone. GitGuardian’s State of Secrets Sprawl 2026 found 24,008 unique secrets exposed in MCP-related configuration files on public GitHub, and 2,117 of them were still valid credentials at the time of testing. Those are not hypothetical keys in a threat model slide. Those are live credentials sitting in agent config files that someone committed by accident. On 9 July 2026, AWS shipped the fix, and it is worth twenty minutes of your week.

The short answer: AWS Sign-In now supports industry-standard OAuth 2.0 for the AWS MCP Server, which means an AI agent such as Claude Code, Kiro, Codex, or Gemini can authenticate to AWS through a browser sign-in using your existing IAM identity instead of a long-lived access key stored on disk. AWS Sign-In issues short-lived access tokens and refresh tokens, manages the refresh automatically, and records every authorisation and token event in CloudTrail. Critically, authorising an agent grants it no additional AWS permissions. Every request it makes is still evaluated against your existing IAM policies, SCPs, RCPs, and permission boundaries. Alongside it AWS added OAuth-specific IAM condition keys, token introspection and revocation APIs, dynamic client registration, and a headless flow for agents running without a browser. It is available now and it works with the IAM setup you already have.

The Numbers Behind the Problem

Long-lived credentials are not a new complaint. What changed is that AI agents multiplied the number of places those credentials live, and the data now shows it clearly. Here is what the primary sources say as of July 2026.

Read the AWS row and the GitHub row together, because that is where the story is. The share of AWS access keys older than three years went up, from 21 percent to 25 percent, and the share older than five years went up from 8 percent to 10 percent. Meanwhile the volume of secrets hitting public GitHub grew 34 percent in a single year. The keys are getting older and the number of places they can leak is growing. Those two curves moving in the same direction is the whole problem in one sentence.

The line that should worry any engineering leader is the 3.2 percent figure. Commits made with AI assistance leak secrets at roughly double the rate of the baseline. That is not an argument against AI-assisted development, and I am not making one. It is an argument that the credential model you used before agents does not survive contact with agents. When a tool is generating and committing config at machine speed, a static key in a file is going to escape eventually. It is a matter of throughput, not discipline.

And the 59 percent CI/CD runner figure kills the comfortable assumption that this is an endpoint problem. Most of the compromised machines holding secrets were shared build infrastructure, not somebody’s MacBook. You cannot solve that with laptop hygiene.

What AWS Actually Shipped

The mechanics matter, so here is what happens. You attach the new AWSMCPSignInOAuthAccessPolicy managed policy to your role. You add the MCP server endpoint to your agent, for example with claude mcp add --transport http aws-mcp https://aws-mcp.us-east-1.api.aws/mcp. The first time the agent needs AWS access it discovers the AWS Sign-In OAuth server, registers itself as a client using Dynamic Client Registration, and opens a browser. You authenticate the way you always do, whether that is IAM Identity Center, a federated provider like Okta or Ping, or a plain IAM user. You approve the request. AWS Sign-In issues short-lived tokens and handles refresh from then on, so nobody is signing in every hour. If you already have an active console session from earlier in the day, it reuses it.

Nothing long-lived lands on the developer’s machine. That is the entire point, and it is a bigger deal than it sounds. The 59 percent of AWS IAM users carrying an access key older than a year did not get there because engineers are careless. They got there because there was no ergonomic alternative, and a static key in ~/.aws/credentials is the path of least resistance. Removing the reason to create the key is how you actually fix the number, not another rotation policy that nobody follows.

For agents running in CI or any headless context, there is a client credentials flow. An application that already holds AWS credentials calls aws signin create-oauth2-token-with-iam and gets back a bearer token that expires in 3,600 seconds. Given that 59 percent of compromised secret-bearing machines were CI/CD runners, this is arguably the more important half of the launch, and it is the half that will get less attention.

The Governance Controls Are the Real Story

Short-lived tokens are table stakes. What makes this launch usable in a regulated or audited environment is the control surface AWS wrapped around it.

OAuth grants are modelled as IAM resources, addressed as arn:aws:signin:REGION:ACCOUNT:service-principal/aws-mcp.amazonaws.com, which means they respond to ordinary IAM policy. Two new actions gate the flows: signin:AuthorizeOAuth2Access for interactive sign-in and signin:CreateOAuth2Token for token exchange. On top of that there are OAuth-specific condition keys. The one worth writing into your policy today is signin:OAuthRedirectUri, which lets you restrict token delivery to http://localhost:* so an agent cannot hand a token to an untrusted redirect URI. Pair it with signin:OAuthGrantType constrained to authorization_code and refresh_token and you have closed off the flows you did not intend to allow.

There is also a containment story, which is what you want at three in the morning. The aws:SignInSessionArn global condition key lets you deny everything associated with one specific sign-in session without touching other active sessions. The token revocation API lets you kill an individual refresh token with the same surgical scope. If you have ever had to rotate an access key and found out afterwards which six things it silently broke, you will appreciate the difference.

The audit trail is complete in a way these launches often are not. CloudTrail records authorisation requests, token issuance, revocation, and introspection, and captures the OAuth client, the redirect URI, the authorisation flow, and the sign-in session. Better still, AWS API calls made with an OAuth access token carry the aws:SignInSessionArn context, so you can correlate what the agent actually did back to the sign-in that authorised it. That is the question every incident responder asks about agent activity and, until now, could not answer cleanly.

Why This Is Not Just a Security Story

Compromised credentials were the initial access vector in 22 percent of breaches in Verizon’s 2025 DBIR, out of 9,891 breaches where the vector was known. That is the headline risk. But the operational cost of long-lived keys is the part founders underrate, because it never shows up as an incident.

It shows up as the offboarding checklist nobody trusts. It shows up as the six-hour outage caused by rotating a key that turned out to be load-bearing in a Lambda somebody left in 2023. It shows up as the SOC 2 auditor asking which humans and which machines can reach production, and your team spending a fortnight building a spreadsheet to answer. GitGuardian’s finding that more than 64 percent of credentials confirmed valid in 2022 were still valid in January 2026 is a measurement of exactly this. Those keys are not still live because anyone decided they should be. They are live because revoking a credential you cannot trace is scarier than leaving it alone.

Short-lived, session-attributable tokens make that whole category of problem go away. Not because they are more secure in the abstract, but because they expire by default. The safest credential is the one that stops existing without anyone filing a ticket.

What to Do About It

Start by finding out how bad it is, because most teams are wrong about their own number. Run a credential report across your accounts and count access keys older than 365 days. If you land near the 59 percent industry figure, you are normal, which should not be reassuring. Then grep your repos and your agent configuration directories for AWS keys, and check Slack and Jira too, because GitGuardian found roughly 28 percent of secret incidents originate outside repositories entirely.

Next, move your agent connections to the OAuth path. Attach AWSMCPSignInOAuthAccessPolicy, point your agents at the AWS MCP Server endpoint, and confirm the flow works for one team before you roll it wider. Write the redirect URI restriction into policy on day one rather than promising to add it later, because later does not arrive. Then handle CI separately with the headless client credentials flow, since that is where the majority of exposed machines actually were.

Only then start deleting keys. Use CloudTrail to confirm a key is genuinely unused before you revoke it, and revoke it rather than just deactivating it, because a deactivated key is a key somebody re-enables in a hurry at some point. Finally, make the new default stick. If creating a long-lived access key still requires no justification in your organisation, you will be reading the same 59 percent figure next year with your own name on it. An SCP that denies iam:CreateAccessKey outside a break-glass role is a blunt instrument, and blunt is exactly what this needs.

If your team is running AI agents against AWS and you are not certain what credentials they are holding, or you are staring at an IAM estate that grew organically and now nobody wants to touch, HAZERCLOUD can help. We run identity and access reviews, agent security assessments, and AWS migration and modernisation work for businesses across the UK, Europe, and the US, and we do it as practitioners who have had to clean up these estates rather than as auditors handing over a findings list. Get in touch for a free consultation and we will tell you honestly whether this is a weekend of work or a quarter of it.

Jobin Joseph

View all posts by Jobin Joseph

hazercloud.com