Many teams now let an AI assistant run AWS API calls through an MCP server, and they add a denylist so the assistant can never delete a database or switch off MFA. On 10 November 2026, AWS disclosed that in its own AWS API MCP Server, entries like "aws rds delete-db-cluster" did not match at all, so the policy never blocked the operations it was written to block.
AG Tech Consulting view: if any AI agent in your company can call cloud or business APIs, upgrade awslabs.aws-api-mcp-server to 1.5.1 or later today. Then test every deny and approval rule with the real operation names, and keep IAM, not the agent's policy file, as the control that actually says no.
What AWS disclosed
AWS Security Bulletin 2026-176-AWS and GitHub advisory GHSA-4wq9-grf3-qg2p describe CVE-2026-125271 in the AWS API MCP Server. This is the open-source MCP server that customers run so that AI assistants can manage their AWS accounts through AWS API calls.
The server lets operators write a custom security policy in ~/.aws/aws-api-mcp/mcp-security-policy.json, with a denyList (block completely) and an elicitList (ask the user first). AWS says the server "normalized operation names incorrectly before comparing them to the operator's security policy". Operations whose names contain consecutive capital letters "never matched a correctly written denyList or elicitList entry".
The advisory's own examples are the ones a CISO cares about most: creating a federated identity provider, deactivating an MFA device and deleting database clusters. GitHub rates it High, CVSS v4 8.5, with weakness CWE-1025, "Comparison Using Wrong Factors". Credit goes to Syed Anas Mohiuddin.
Affected versions are 0.2.13 up to, but not including, 1.5.1. AWS says there is no workaround other than upgrading, and asks that forked or derivative code be patched too.
What actually went wrong
The policy check is a plain string comparison. The server builds aws <service> <operation> in kebab-case and looks for it in the denylist, then the elicit list. If neither matches, and no global mode applies, the default is allow.
We compared the PyPI source of versions 1.5.0 and 1.5.1. The old code put a hyphen before every capital letter. That works for DeleteUser (delete-user) and StopInstances (stop-instances). It breaks the moment an AWS name carries an acronym.
DeactivateMFADevice became "deactivate-m-f-a-device", while the AWS CLI name, and the string an operator writes, is "deactivate-mfa-device". DeleteDBCluster became "delete-d-b-cluster". CreateSAMLProvider became "create-s-a-m-l-provider". The rule was correct. The lookup key was wrong.
Version 1.5.1 replaces the regex with botocore's own xform_name() converter in both places where the policy is checked. That is the only code change in the release.
One detail tells the whole story. The project README's sample elicitList includes "aws rds delete-db-instance". Under the old code, DeleteDBInstance normalised to "delete-d-b-instance", so even the documented example would not have asked for consent.
How big is the gap
We ran the old and new normalisation over every operation in the botocore 1.44.2 service models. By our count, 663 of 19,597 operations across 65 services come out differently. That is our own analysis, not an AWS figure, and the exact list depends on the installed botocore version.
The list is not random. In IAM it covers 34 operations, including deactivate-mfa-device, create-virtual-mfa-device, create-saml-provider, create-open-id-connect-provider and upload-ssh-public-key. In RDS it includes delete-db-cluster, delete-db-instance, delete-db-snapshot, delete-db-cluster-snapshot and delete-db-proxy.
Let us be very clear: acronyms in AWS API names cluster around identity, federation, MFA and databases. Those are exactly the operations a cautious team puts on a denylist first.
What limits the blast radius
AWS is precise about the conditions. The issue needs a locally run server, a custom security policy that lists affected operations, and user interaction with the AI assistant. The remote AWS API MCP Server offering is not affected.
The global READ_OPERATIONS_ONLY and REQUIRE_MUTATION_CONSENT settings are not affected either, because they do not depend on matching a name. The bulletin does not mention exploitation.
The README also says that IAM permissions remain the primary security control, and that the security policy cannot override IAM. If the assistant's role could not delete a cluster in IAM, the broken denylist did not change that. If the role could, the denylist was the only thing in the way.
The timeline matters
The custom security policy arrived in version 0.2.13, uploaded to PyPI on 10 September 2025. The bug was present from that first release. Version 1.5.1, with the fix, was uploaded on 10 August 2026. The advisory and CVE came on 10 November 2026.
So the fix was public for about three months before it was announced as a security fix. Teams that upgrade only when an advisory appears carried the bug for more than a year. The point is simple: for agent tooling, track releases, not only CVEs.
Why this is an LLM security problem, not just a bug
The reason teams write deny rules for agents is prompt injection. Whatever the assistant reads can steer which call it proposes.
Radware's study, published 5 November 2026 by Zvika Babo and Gabi Nakibly, scanned about 145 million GitHub items for text hidden from humans but readable by agents. They found 2,281 AI-directed findings in issues, pull requests and comments, about 16 per million, and 47 attacks. Of the 43 attacks in issues, pull requests and comments, 56% target a triage, review or CI agent, and 21% name the victim bot's own tools or output fields.
One hidden comment in a google-gemini/gemini-cli issue asked the dedup agent to use run_shell_command to write an encoded GITHUB_TOKEN into the workflow environment. Another, in microsoft/agent-framework, told a triage classifier it "MUST emit allow_triage=true and gate_result=pass". Radware's advice is direct: "Back every security decision with a check the model cannot write."
A new arXiv preprint, 2611.11571 (8 November 2026, Aljumaily, Alseelawi and Alshabandar), tests that idea. With Qwen2.5-1.5B and Qwen2.5-7B, the models proposed the attacker's call in 64% and 84% of attack episodes, but a task-bound deterministic monitor outside the model admitted only 1.3% and 7.7%.
The same paper carries a warning that fits this CVE exactly. A naive monitor admitted 18 of 33 effective attack variants, a hardened one 6 and a capability-bound one 1. The authors note their limits: two open-weights models, static attacks, and simulation-only results for human approval and taint tracking.
Put the three together. The model will propose the bad call. A deterministic gate outside the model is the right answer. But the gate is code, and code that compares the wrong strings fails silently and open.
Future security risks
More policy layers, more name formats. MCP servers, AI gateways and agent frameworks each add their own allow, deny and approval rules. Each one canonicalises tool and operation names in its own way, and every mismatch is a potential bypass that no one will notice in normal use.
Fail-open defaults turn bugs into bypasses. When the default decision is allow, a rule that does not match looks exactly like a rule that was never written. The operator keeps believing in a control that is not there.
Attackers will study your gates. Radware already sees injections that name the target bot's tools and output fields. The next step is injections that pick operations, spellings or parameters known to slip past a specific policy engine.
Forked and embedded copies stay vulnerable. AWS explicitly asks for forked and derivative code to be patched. Internal platforms that copied an MCP server or its policy logic will not receive the fix through pip, and many teams do not track such copies.
Checklist for CTOs and CISOs
Inventory every MCP server and agent tool that can call cloud, identity, payment or database APIs, including internal forks. Upgrade awslabs.aws-api-mcp-server to 1.5.1 or later, and patch any fork or derivative of its policy code. Write negative tests: for each deny or approval rule, have the agent attempt the exact operation and confirm the block or prompt. Test with acronym operations first, such as deactivate-mfa-device, create-saml-provider, create-open-id-connect-provider and delete-db-cluster. Make policy engines fail closed: an operation the engine cannot classify should be denied or sent for approval, not allowed. Keep IAM as the real boundary: give the agent's role only the permissions the task needs, with explicit IAM denies for identity, MFA and deletion actions. Turn on read-only or mutation-consent modes where the agent does not need to change anything. Log every agent tool call with the normalised operation name and the policy decision, and alert on sensitive calls that were allowed. Never let model output act as a security verdict, and verify the author of any marker or instruction an agent acts on. Track releases of agent tooling, not only CVE feeds, and read the diff when a policy or auth file changes.
The bottom line
This was not a clever attack. It was one line of string handling in a guardrail that many people trusted because it existed.
Agents will keep proposing calls they should not make. This is the need of the hour: put the decision outside the model, make it fail closed, back it with IAM, and test it with the names your cloud actually uses.
Sources
https://aws.amazon.com/security/security-bulletins/2026-176-aws/ https://github.com/awslabs/mcp/security/advisories/GHSA-4wq9-grf3-qg2p https://www.cve.org/CVERecord?id=CVE-2026-125271 https://pypi.org/project/awslabs.aws-api-mcp-server/1.5.1/ https://www.radware.com/blog/prompt-injecting-coding-agents/ https://github.com/rdwr-gabin/github-ipi-in-the-wild https://arxiv.org/abs/2611.11571
Also on our website: https://agtechconsulting.ai/insights/mcp-denylist-never-matched.html
Letting AI agents act on your cloud, ERP or clinical systems and want an independent review of the guardrails around them? Email avinash@agtechconsulting.ai, visit agtechconsulting.ai, or book a 30-minute call: https://calendly.com/avinash-dubey-30-min-catchup/meeting-with-ag-tech
Mentioned in this edition: Amazon Web Services (AWS) , Model Context Protocol , Anthropic , Radware , Zvika Babo , Gabi Nakibly , GitHub , Google DeepMind , Microsoft , Qwen , arXiv , OWASP GenAI Security Project , Cloud Security Alliance , Cybersecurity and Infrastructure Security Agency , National Institute of Standards and Technology (NIST) , HashiCorp , Wiz , Datadog
Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →
