Several MCP servers expose destructive AWS operations as tools with no confirmation parameter — is the gate expected to be IAM?

[VamsiSudhakaran1]

Hi — thanks for maintaining these servers, the coverage across AWS services is genuinely impressive.

I've been building a static analyser for agent tool surfaces and ran it across a set of public MCP servers. I want to be upfront that this is a design question, not a vulnerability report: everything below is intentional, documented API surface. My question is about where the confirmation boundary is meant to live.

What I looked for

Tools registered to an MCP server that perform an irreversible operation — one an agent cannot undo — with no confirm / dry_run / approval parameter in the tool signature or body.

What I found

Server	Tool	Location
healthimaging	delete_patient_studies	src/healthimaging-mcp-server/awslabs/healthimaging_mcp_server/server.py:507
healthimaging	bulk_delete_by_criteria	…/server.py:667
healthimaging	delete_datastore	…/server.py:188
healthimaging	delete_study / delete_series_by_uid	…/server.py:516 / :586
timestream-influxdb	delete_db_instance / delete_db_cluster	src/timestream-for-influxdb-mcp-server/…/server.py:769 / :799
elasticache	delete_cache_cluster	src/elasticache-mcp-server/…/tools/cc/delete.py:26
elasticache	delete_replication_group	…/tools/rg/delete.py:26
amazon-mq	rabbitmq_broker_purge_queue	src/amazon-mq-mcp-server/…/rabbitmq/module.py:288
amazon-mq	rabbitmq_broker_delete_queue	…/module.py:276
iot-sitewise	delete_asset / delete_asset_model	…/tools/sitewise_assets.py:326 / sitewise_asset_models.py:411
ecs	mcp_delete_ecs_infrastructure	src/ecs-mcp-server/awslabs/ecs_mcp_server/modules/delete.py:32

(Full list is longer; these are the representative ones.)

Why I'm raising it

An MCP tool is selected by a model, not a person. A prompt injection in retrieved content, or an ordinary model mistake, resolves to a tool call — and delete_patient_studies or bulk_delete_by_criteria on medical imaging has no undo.

The relevant question isn't "is this code wrong" — it isn't. It's which layer is expected to say no, and whether an operator installing these servers is likely to understand that.

What I'd genuinely like to know

1. Is IAM the intended boundary? That's a completely reasonable design, and if so I think it's worth saying so explicitly in the READMEs — an operator wiring these into Claude Desktop or an agent framework may not realise the tool layer is deliberately un-gated.
2. Would a confirm: bool = False parameter on the destructive subset be welcome? It's a small change that makes the boundary explicit at the point of use, and the model has to affirmatively pass it. Happy to open a PR for one server as a sample if that'd be useful.
3. Is there a documented "read-only mode" for deployments that shouldn't expose mutation at all?

Reproducing

pip install release-gate
release-gate audit path/to/awslabs-mcp --full

It's an open-source static analyser (repo). Relevant to whether it's worth your time: these are graded medium / inferred, not high — the tool explicitly reports that it can only see the absence of a code-level gate and that an out-of-band control may well exist. Accuracy is published as a reproducible benchmark you can re-run rather than a claim.

Entirely possible the answer is "IAM, by design, working as intended" — that's a useful answer and I'll take it. Mostly I'd like the reasoning to be written down somewhere an operator will find it.

Thanks for reading.