A FinOps MCP server's safety property is the absence of a write handler

Token scope and prompt text fail as controls for different reasons, and the difference matters when you are the one writing the server. A scoped token still authorises exactly what it authorises, so it holds only up to the boundary someone drew when they issued it. A prompt instruction is a string a stochastic caller can weight low. Neither produces a refusal. The dev.to author's contract is three clauses: read-only tools over costs, resources and recommendations; mutation attempts rejected inside the server regardless of the token held or what the prompt claims; every call audited ^[2]. A server with no mutate handler refuses because there is no code path to reach, which is a different kind of statement from a model promising to be careful ^[5].

The reason to hold that line is the input path. Assistants read web pages, tickets and docs, and any of those can carry injected instructions, so the session itself is untrusted input [c13a]. The author's warning about adding "just one" write tool follows directly: the moment a mutate handler exists, every document the assistant ingests becomes a potential caller of it ^[10].

The clause I would put first, though it is listed last, is the credential. A warehouse role with SELECT on the billing schema and nothing else makes read-only a property of the database rather than a promise in application code ^[9], and because the server sees only what its credential sees, existing RBAC keeps meaning something once the assistant is attached ^[7]. It should be the server's own least-privilege identity, revocable in one step, and never a human's personal token ^[14]. Borrow an engineer's credential and you cannot cut the server off without cutting the engineer off.

The sketched surface is four functions: cost summary by service, account or team; a daily trend for a scope; idle resource findings above a monthly threshold; untagged spend by account ^[8]. Four read paths, zero mutate handlers ^[1]. That is the entire enforcement story, which is also why the author can call an internal build a weekend project for teams already landing billing exports in a warehouse ^[16]. The weekend goes on parameterised queries; the safety property is inherited, not written.

Per-call logging with caller and arguments is what turns "what did the assistant look at" from a mystery into a query someone can actually run ^[6]. And the step teams ask for next, letting the assistant stop the idle database it found, is handled as proposal rather than action: the assistant files a pending approval record, a human reviews it and executes through the normal audited path, so the finding and the prepared action survive while mutation authority stays in systems that carry approvals, preconditions and rollback, none of which a chat session has ^[11][12]. Worth being clear about the evidentiary status: this is one practitioner's design argument on dev.to, not a postmortem. No incident is cited, and the whole case rests on the claim that an ungrounded model will answer bill questions confidently and wrongly ^[3].