The report
An operator could forbid a particular AWS API action in an MCP custom policy yet have the same underlying action reached under a differently normalized name. AWS disclosed and fixed that mismatch in awslabs.aws-api-mcp-server 1.5.1 on November 10.
A check was applied to the wrong spelling
The affected server translates structured MCP requests into AWS operations. For operation names with consecutive capital letters, its normalization could produce a name different from the one listed in the operator's denyList or elicitList. The tool dispatcher could then attempt an AWS call that the custom policy was intended to deny or put behind an approval step. That is an application policy bypass, not a bypass of the AWS identity and access management service.
The AWS advisory specifies affected versions from 0.2.13 up to, but not including, 1.5.1. It applies to the locally run server using a custom security policy. AWS says the remote offering, READ_OPERATIONS_ONLY and REQUIRE_MUTATION_CONSENT are not affected. Real-world reachability still depends on the tool being usable and the underlying AWS credential having permission to perform the API operation. The Case records these conditions.
The company lists operations such as creating an identity provider, deactivating MFA or deleting database clusters as high-impact examples if a broad IAM principal makes them available. No disclosed production victim or executed destructive request is established by the advisory. CVSS severity expresses a vulnerability classification, not an observed loss.
The correction must happen before dispatch using one canonical operation identifier for policy lookup and execution. Upgrading to at least 1.5.1 closes this documented normalization route; IAM policies should independently restrict the runtime credentials. Reviewing real CloudTrail effects then checks whether the operations a model could name matched the actions its credential actually performed.