AWS API MCP ignored a custom denyList for alternate command name spellings

The AWS API MCP server offered a custom denyList to prevent an agent from using particular AWS operation names. Some requests reached the same underlying operation through differently normalized or aliased spellings, while the denyList validation compared an insufficiently normalized representation. The result was a policy gap between the apparent blocked command and the command that the server dispatched under its configured AWS credentials.

The advisory identifies affected releases before 1.5.1 and a correction in 1.5.1. The ability to call a denied operation still depends on the server's AWS IAM identity having permission for that API. The flaw does not bypass AWS authorization, user confirmation or read-only tool controls in every adapter configuration. It specifically weakens deployments that counted on a custom denyList for an additional operation boundary.

AWS API MCP deployments using a custom denyList against an agent or user who can supply an alternate operation name; backend AWS IAM remains effective.

No in-the-wild victim, credential theft or unrestricted cloud-account compromise was established. The advisory does not support claims that normal IAM permission boundaries were bypassed.

Exact normalization failure. The affected adapter used a different spelling for AWS API operations containing consecutive capital letters when checking its custom denyList and elicitList than when dispatching them. A policy could visibly list the operation as blocked or approval-gated while the MCP command handler still routed a permitted cloud API call. The vulnerable Python package range was 0.2.13 through versions before 1.5.1; the advisory identifies 1.5.1 as patched.

The bypass requires a locally operated MCP server with an affected custom policy and a caller interacting with the assistant. The backend IAM principal still decides whether the cloud operation itself is authorized. That makes a deliberately narrow role a second boundary, whereas a highly privileged role protected only by a string-based denylist remains exposed. The relevant regression test must compare every advertised tool name, normalized operation and effective IAM permission.