Tool annotations such as readOnlyHint and destructiveHint describe tools but do not enforce account authorization. The reported client forced a model call to a visible tool, sometimes a write, when the task needed only a read or no matching tool was available. Four hosted models, mock tools based on public MCP interfaces and an additional AgentDojo comment…
Inspect the ClaimsCase · DiggingBeagle record
Forced MCP tool selection caused unauthorized simulated writes without task-scoped allowlisting
An MCP specification discussion reports 460 of 816 forced-tool trials triggered out-of-task writes, versus five without forcing; task-specific gating suppressed writes in the test.
Results come from reported mock-tool and benchmark trials; no production side effects or independently reproduced rate are established.
Assessment profile
Assessment method- Setting
- simulation
- Exploitation
- demonstrated
- Evidence
- Grade D
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-MCP-FORCED-TOOL-AUTH-A · Model Context Protocol specification issue 3492: forced tools and annotations
At a glance
No model-level hint can substitute for a host-side permission check tied to the exact user task.
Read the implicationsResults come from reported mock-tool and benchmark trials; no production side effects or independently reproduced rate are established. The issue does not establish an independent real-service reproduction or a normative spec resolution for empty authorized tool sets.
Limits and uncertaintyFull account
Tool annotations such as readOnlyHint and destructiveHint describe tools but do not enforce account authorization. The reported client forced a model call to a visible tool, sometimes a write, when the task needed only a read or no matching tool was available. Four hosted models, mock tools based on public MCP interfaces and an additional AgentDojo comment support a task-scope distinction, not a field abuse rate. The unresolved specification edge is what a forcing client should do when the authorized tool set is empty.
The MCP issue tests a client that forces the model to choose among advertised tools, including tools labelled read-only or destructive without binding those labels to the current user request. In the reported mock evaluation, forced choice produced 460 unauthorized writes in 816 trials, compared with five without forcing; task-class allowlisting reduced that test count to zero. These are synthetic outcomes under particular tool inventories and models, not measured writes against real users. The safe behavior when no authorized tool exists must be explicit rather than falling back silently to any available write capability.
Mechanism and trust boundary
- 01
Offer broader MCP tools than the task needs
The model sees mutating operations that the user did not authorize.
Boundary: Tool discovery into potential mutation authority
- 02
Force tool selection
The client compels a tool call rather than allowing an abstention.
Boundary: Model choice into execution decision
- 03
Execute a mutating tool
Without task-based filtering the synthetic unauthorized write can complete.
Boundary: Requested information retrieval into state change
Claims & evidence
CLM-2026-NOV02-MCP-FORCED-TOOL-AUTH-AThe reporter measured 460 unauthorized simulated writes among 816 runs when model calls were forced to select from a tool set not restricted by the user request; restricting eligible tools to the request-authorized class produced zero in the same setup.supported
Basis: reported finding
- supportsModel Context Protocol specification issue 3492: forced tools and annotationsprimary disclosure
MCP GitHub issue 3492, examples and 816-trial results, later AgentDojo comment
CLM-2026-NOV02-MCP-FORCED-TOOL-AUTH-BIn an issue author's mock-tool tests, forced tool selection yielded 460 unauthorized writes in 816 trials versus five without forcing; request-class allowlisting yielded zero in the same 816 trials.supported
Basis: reported finding
- supportsModel Context Protocol specification issue 3492: forced tools and annotationsprimary disclosure
Issue 3492, synthetic forced-tool-choice tests and request-class allowlist comparisons
Implications
No model-level hint can substitute for a host-side permission check tied to the exact user task.
Controls and mitigations
- Constrain eligible tools and parameters per request; if none is authorized, fail closed or ask for explicit approval instead of forcing a write.
- Filter candidate tools by the current request's authorization before forcing a tool call; reject if the authorized set is empty rather than coercing a write.
Unknowns and contradictions
- Results come from reported mock-tool and benchmark trials; no production side effects or independently reproduced rate are established.
- The issue does not establish an independent real-service reproduction or a normative spec resolution for empty authorized tool sets.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214