MCP and AI Cloud Management: What Changes and What to Guard
An assistant that can call your cost platform's tools becomes a query interface. The engineering question is how far to let it act.
AI cloud management, in the MCP sense, means an AI assistant answering operational questions by calling a cloud platform’s tools directly, instead of a person clicking through consoles and pasting results into a chat. The Model Context Protocol makes this a standard integration: the specification describes it as a standard way to integrate additional context and tools into AI applications, with servers exposing tools, resources, and prompts over JSON-RPC, either locally over stdio or remotely over Streamable HTTP. Once a cost platform exposes an MCP server, any compatible assistant can use it without a custom plugin.
What becomes practical
The value is in questions that cross several screens. With read tools over resources, costs, recommendations, budgets, and audit logs, an assistant can chain calls that a person would do by hand:
- “Which accounts had the largest week-over-week cost increase, and what changed in each?” The assistant pulls trends, then drills into the accounts that moved.
- “Which open recommendations belong to resources owned by the payments team?” Recommendations joined with team attribution.
- “Who changed this schedule, and when?” An audit-log lookup scoped to one object.
- “Is anything over budget this month?” Budget status across teams.
In each case the model chooses the tool calls and summarizes the result; the numbers come from the platform, not from the model’s memory.
What does not change
The assistant knows only what the tools return. If allocation is incomplete, it will report the unallocated share as faithfully as a dashboard would, and no better. If a question needs data the platform does not collect, the right answer is “not available”, and it is worth checking that the assistant says so rather than estimating.
The trust model
Two properties of MCP shape the risk. First, the MCP specification tells clients to treat tool annotations, such as a read-only hint, as untrusted unless they come from trusted servers, and says there should always be a human able to deny tool invocations. Second, read tools return text that other people control: resource names, tags, descriptions, and ticket titles. Once write tools are available, that text can act as an instruction to the model. A tag value that reads like a command is a prompt-injection attempt delivered through a read call.
The controls that hold up are server-side and identity-based:
- Least-privilege identity. The assistant should act as a user or token whose role is no broader than the task.
- Server-side authorization. Every call checked against the caller’s live permissions, independent of what the client or model claims.
- Tiered write access. Separate reversible from irreversible actions, and require a deliberate decision to enable each.
- Audit of reads as well as writes. So that what the assistant looked at can be reconstructed.
How ZopNight applies these
ZopNight’s MCP server authenticates with personal access tokens and enforces RBAC at its gateway; the MCP server holds no authorization logic of its own. Organizations start with read tools only; write access is opt-in through tiers from metadata-only through reversible to irreversible, the irreversible tier needs an organization-bound token, and the whole write surface is behind a kill switch that is off by default. Role and member management sit at tier 1 and bulk start and stop at tier 3; organization and cloud-account deletion, credential reads, and org-level role assignment are never exposed as tools. Reads are audited without their response payloads, and tools/list advertises only what the caller may call.
Starting out
Begin read-only. Ask questions whose answers you can check against the app, so you learn where the assistant is reliable. Raise the write tier only for a specific job, with a token belonging to an identity scoped to that job.
Details on tiers and audit are in the ZopNight MCP server; tool mechanics are in MCP tools explained. For controlling the AI spend itself, see LLM cost governance.