The Server Was Up. Its Security Policy Wasn’t.

Lav Kumar Vishwakarma — Thu, 13 Aug 2026 14:08:48 +0000

What CVE-2026-16584 in the AWS API MCP Server taught me about MCP security, fail-open systems, and the controls we place between AI agents and real infrastructure.

On July 23, 2026, AWS published a security advisory for a vulnerability I reported in the AWS API MCP Server. It was assigned CVE-2026-16584, rated High, and given a CVSS v4.0 score of 7.3.

My name appears in the acknowledgement as the independent researcher who reported it. That was a meaningful moment for me. I have spent much of my career building backend systems, and more recently I have been looking closely at the security boundaries around AI agents and MCP servers.

Still, I do not want this post to be a victory lap. The interesting part is the failure itself because it is easy to understand, easy to underestimate, and relevant far beyond one open-source project.

Here is the short version:

The server could start even when the data required to enforce its security policy had failed to load. Once that happened, the policy check could be skipped for the lifetime of the process.

The server was running. The security policy was not.

Disclosure note: This article uses only information available in the public AWS security advisory. I am not publishing a proof of concept, step-by-step reproduction instructions, private communication, internal logs, or details that AWS has not made public.

What does the AWS API MCP Server do?

The Model Context Protocol, or MCP, gives AI assistants a standard way to connect to tools and external systems. The AWS API MCP Server allows an assistant to interact with AWS services through AWS CLI commands.

That is useful, but it also places the server on a sensitive boundary. A model is no longer only producing text. It can request an action against real cloud infrastructure.

The server includes an optional, user-configured security policy. Administrators can use that policy to deny or gate selected AWS operations before they are executed.

In normal operation, the flow is simple:

The server loads the data needed to enforce the configured policy.
A tool request arrives.
The requested AWS operation is checked against the policy.
The operation is allowed, denied, or sent through a gate.

CVE-2026-16584 affected the first step, which then changed what happened at the third.

What went wrong

The AWS API MCP Server loaded its policy-enforcement data during startup. According to the advisory, if that initialization failed, the process could continue running without the enforcement data being available.

When a request arrived later, the policy check could be skipped. When a security policy was configured without fail-closed modes enabled, configured deny and gate rules were not consulted. More importantly, this was not limited to a single request. The server could stay in that weaker state for the lifetime of the process.

Stage	Expected behaviour	Vulnerable behaviour
Startup	Policy data loads	Policy data is unavailable
Readiness	Server becomes ready after its controls are ready	Server keeps running
Request	Policy evaluates the AWS operation	Policy evaluation is skipped
Result	Deny or gate rules apply	That policy layer does not restrict the operation

Initialization failures happen in production. A dependency times out. A file is malformed. Permissions are wrong. Connectivity is degraded. None of that is unusual.

The security question is what the application does after the failure.

In this case, missing enforcement state could lead to permissive behaviour. That is a classic fail-open security problem: a control becomes unavailable, but the protected operation can continue.

The guard was not defeated during a request. It was missing before the request arrived.

Why this matters for AI agent security

When people discuss AI security, the conversation quickly moves to prompt injection, model manipulation, jailbreaks, and malicious tool descriptions. Those are real problems. But this vulnerability was not caused by the model doing something clever.

It was a conventional backend security failure at an AI execution boundary.

That distinction matters. MCP servers sit between an agent’s intent and an external action. If a permission check, approval gate, tenant boundary, tool allowlist, or sandbox is absent, the model does not need to break that control. The application may already be operating without it.

This is why agentic AI security cannot be reduced to better prompts. The full execution path matters:

Which credentials does the agent use?
Which operations are exposed as tools?
Where is authorization enforced?
What happens when enforcement cannot initialize?
Does the server remain healthy when a security dependency is unhealthy?
Can the system distinguish “policy disabled” from “policy failed to load”?

These are software architecture questions, not language-model questions.

What the vulnerability did not bypass

It is important to describe the impact accurately.

CVE-2026-16584 bypassed the optional security-policy layer under the affected MCP server condition. It did not remove AWS IAM permissions from the credentials configured for the server.

If those credentials allowed only read access to a small set of resources, IAM continued to enforce that boundary. If the credentials were broad, the missing MCP policy layer left a much larger set of actions available.

The effective risk therefore depended heavily on credential scope.

This is a practical example of why AWS IAM least privilege matters. Least privilege is not only about preventing an intended user from doing too much. It also limits the damage when another security layer fails in an unexpected way.

An MCP policy can add useful context-specific restrictions, but it should not be the only boundary between an AI agent and a high-impact cloud operation.

The uncomfortable part: what does `None` mean?

The advisory maps the issue to CWE-455: Non-exit on Failed Initialization. The name sounds dry, but the design problem behind it appears in many systems.

Imagine a security component with three possible states:

The policy loaded successfully.
The administrator intentionally disabled the policy.
The administrator configured a policy, but it failed to load.

The second and third states must never be treated as equivalent.

One is an explicit configuration decision. The other is a security failure. If both become the same empty, null, or false-like value in memory, request-handling code can easily interpret “not available” as “nothing to enforce.”

That is not just an MCP concern. The same pattern can affect:

authorization configuration;
tenant context;
policy caches;
tool allowlists;
approval workflows;
audit pipelines;
sandbox initialization; and
secret and identity providers.

A missing value is not neutral when that value decides what a system is allowed to do.

Questions I would now ask in every MCP security review

This finding changed the way I think about reviewing agent infrastructure. I would not only test whether a deny rule works. I would also follow the control through its failure states.

These are the questions I would ask:

If the policy engine cannot initialize, can the server still report itself as ready?
Is “disabled by configuration” represented differently from “failed to load”?
Does the readiness check include security-critical dependencies?
What happens if policy data becomes unavailable after startup?
Are protected requests rejected while enforcement is degraded?
Is a startup error visible only in logs, or does it actually stop unsafe operation?
Do tests cover malformed configuration, timeouts, partial loading, and recovery?
Does the underlying IAM role contain only the permissions required for this agent?

The key test is not only:

Does the security control block the operation?

It is also:

Can the application continue when the security control is unable to block anything?

Fix and recommended action

AWS fixed the issue in awslabs.aws-api-mcp-server version 1.3.47.

Anyone using an affected version, from 0.2.13 up to 1.3.46, should upgrade to the latest version. Forks and derivative projects should confirm that they include the relevant fix rather than assuming their implementation is unaffected.

The AWS advisory also lists two measures for users who cannot upgrade immediately:

Run the server with least-privilege IAM credentials scoped to the specific task.
If the server started during degraded connectivity, restart it after connectivity is restored so the required policy data can load.

I would add one operational check: verify the version actually running in each environment. Updating a dependency declaration is not the same as confirming that every deployed instance has been replaced.

A note on responsible disclosure

I reported the issue privately and worked with AWS through the coordinated vulnerability-disclosure process. The vulnerability was fixed before I wrote publicly about its design implications.

Responsible disclosure is slower than posting a finding immediately, but the sequence matters. Users need a patch and clear mitigation guidance before a researcher turns a vulnerability into public content.

For the same reason, I am keeping this discussion at the architectural level. There is enough information here for engineers to recognize and test the failure pattern without turning the post into an exploitation guide.

I appreciate AWS for investigating the report, shipping the fix, publishing the advisory, and acknowledging my contribution.

The lesson I am taking from CVE-2026-16584

The most memorable security bugs are not always the most complicated ones.

Many reviews focus on finding a clever way around a running control. CVE-2026-16584 points to a simpler question:

What happens if the control never starts?

As MCP adoption grows, we will keep connecting AI agents to cloud platforms, databases, deployment systems, internal APIs, and other high-impact tools. The safety of those systems will depend on much more than model behaviour. It will depend on ordinary engineering details: initialization, state handling, readiness, credentials, error paths, and secure defaults.

My main takeaway is one line:

If the policy is not ready, the server is not ready.

That principle applies to far more than this one AWS API MCP Server vulnerability.

If you are building or reviewing an MCP server, check its startup failure paths. They may tell you more about its real security posture than the happy path does.

References

About the author

Lav Kumar Vishwakarma is a lead backend engineer and independent security researcher working on agentic AI security, MCP permission boundaries, secure tool execution, runtime isolation, and production AI systems. AWS credited him for responsibly reporting CVE-2026-16584.

DEV Community: Lav Kumar Vishwakarma