On 14 October 2026 Microsoft announced that Azure MCP Server 3.0 was stable, with the release itself dated 12 October. The headline is easy to summarise: more tools, across more Azure services, available to more agents. An engineer can now ask an assistant in an editor or a terminal about backup vaults, failover readiness, Advisor recommendations, monitor queries or Terraform modules, and the assistant can call Azure to answer.
That is genuinely useful. It is also a change in kind, not just in scale. A year ago most MCP servers were developer conveniences: a way to look something up without leaving the editor. An MCP server that can reach backup policies, recovery plans, virtual machines and databases is part of how the cloud is operated. It sits on the path between a sentence typed by a person and an API call against a subscription.
So the governance question changes. It is no longer "can the agent find the right tool?" It is "what did we authorise this agent to do, under whose identity, in which subscription, and how would we prove what it did?" This series is about answering that question for MCP servers in production. Azure MCP Server 3.0 is the timely anchor; the control questions apply to any cloud or enterprise tool server.
What version 3.0 adds to the operational surface
Microsoft's release post describes 3.0 as the stable result of 50 beta iterations, building on the self-hosted remote support introduced in 2.0. Read with an operator's eye, four groups of change matter.
New operational toolsets. Azure Backup tools inspect vaults, policies, recovery points and jobs, and cover protection controls such as soft delete, immutability and Resource Guards. Azure Resilience Management tools cover goals, recovery plans, readiness checks, failover validation and drills; the post advises planning and reviewing failover actions before invoking them. An Azure SRE Agent toolset covers investigations, incidents and remediation plans. Note that the SRE Agent tools sit on a resource provider with "Preview" in its name: a stable MCP server does not make the services behind it generally available.
Infrastructure-as-code support. Terraform tools look up provider documentation, explore Azure Verified Modules, export existing resources with aztfexport and validate with conftest. Advisor tooling summarises recommendations, and the post is explicit that applying an Advisor recommendation through the server returns rules for an infrastructure-as-code change rather than changing live resources.
Clearer tool contracts. Input schemas are richer, unknown parameters now return errors, structured output is available as an opt-in mode, and a new operationPlane field labels each operation as data plane, control plane, both or not applicable. Missing resources return 404 and invalid input returns 400.
Safer defaults for new resources. Storage accounts created through the server disable Shared Key authentication, Event Hubs namespaces disable local authentication, Recovery Services vaults disable public networking, and NFS file shares use root squash and encryption in transit. The post states plainly that these defaults do not reconfigure existing resources on upgrade. A better default for tomorrow's storage account does nothing for the ones you already have.
Tool discovery is not permission to act
The most common misunderstanding about MCP is that the tool list is the permission model. It is not. The list tells the model what it could ask for. Whether the call succeeds is decided further down: by the identity the server uses, by the role assignments that identity holds in Azure, by the scope of the subscription and resource groups, and, for databases, by the permissions of the database login.
Microsoft says this directly. The release post recommends starting with --read-only, a development subscription and an identity limited to the permissions the workflow needs, reviewing target resources and the approval process before enabling write tools, and it warns that a natural-language prompt "isn't a substitute for access controls." That sentence should be printed on the wall of every platform team experimenting with agents.
Each of the server's controls solves a different problem:
| Control | What it does | What it does not do |
|---|---|---|
--read-only | Hides the tools the server classifies as changing resources | Stop the agent reading sensitive data it is allowed to read |
--tool filtering | Exposes only the tools you name | Limit what an exposed tool can reach |
| Workload identity with narrow RBAC | Limits what any call can do in Azure | Decide which calls are sensible |
| Subscription and resource-group scope | Contains mistakes to an environment | Protect production if the identity also has production roles |
| Approval gate | Puts a person between proposal and execution | Help if the reviewer cannot see the exact change |
None of these substitutes for another. A read-only server running as an identity with Owner on the production subscription is one configuration change away from being a write server with Owner. A narrowly scoped identity with every tool exposed will still waste time and tokens choosing among irrelevant tools. The layers work together or not at all.
MCP connects capability, it does not establish trust made this point about the protocol. Version 3.0 makes it concrete for cloud operations.
Four authority checkpoints
CloudNala's authority ladder for cloud operations agents uses six levels, from "explain only" to "execute within policy". When an organisation introduces an MCP server, four checkpoints on that ladder need an explicit decision, because each one changes what the server must be allowed to reach.
Inspect. The agent lists resources, queries bounded metrics or reviews backup status. Required: read-only mode, a least-privilege identity, a development or non-production scope to start, and audit logs. The worst outcome is a sensitive read, which Part 2 deals with.
Recommend. The agent explains an Advisor recommendation or proposes a change in words. Required: the evidence it used, stated cost and risk assumptions, and a human technical reviewer. The worst outcome is bad advice that someone acts on.
Prepare change. The agent exports configuration, produces a Terraform plan or drafts a remediation. Required: an isolated workspace, policy validation, a diff a person actually reads, approval and a rollback plan. This is the most valuable rung and the most dangerous one, because the change can look finished when nobody has properly reviewed it. A plan that is approved because it was long and looked plausible is not a reviewed plan.
Execute change. The agent resizes compute, changes application state, runs a database query or invokes recovery actions. Required: an explicitly scoped write identity, allow-listed tools, change authority, runtime guardrails, complete evidence and incident response. Most organisations should keep production execution out of reach for a long time and route changes through the same pipeline as human-written ones.
A worked example at Sedgefield Freight
Sedgefield Freight is fictional, and its systems and figures are illustrative. Sedgefield is a George-based road-freight operator with a small platform team, an Azure estate split across development, test and production subscriptions, and a backlog of Advisor recommendations nobody has time to read.
A developer installs Azure MCP Server locally and connects it to an editor assistant. On day one it runs under the developer's own credentials, which include Contributor on the production subscription from an incident two years ago. Every tool is exposed. Nothing has gone wrong, but everything could.
The platform lead makes four decisions before anyone else installs it:
- The server runs with
--read-onlyand a short--toollist covering Advisor, Monitor, Backup inspection and the Terraform documentation tools. - It runs as a dedicated identity with Reader on the development subscription only, not as a person.
- Advisor recommendations are turned into Terraform changes in a separate workspace, reviewed as pull requests and applied by the existing pipeline. The agent prepares; the pipeline executes.
- The server version, configuration and tool list are recorded in the platform repository, so an upgrade is a reviewed change (Part 5).
In this illustrative scenario, the team can work through the low-risk recommendations without the agent ever holding write access, because the change itself still travels through the pipeline.
Database tools and upgrades are different
Two parts of the release deserve their own warning.
First, databases. Microsoft states that the MySQL and PostgreSQL query tools are "destructive, non-idempotent, and non-read-only", that SQL-verb filtering was removed, and that least-privilege database permissions should be used. In other words, the server will not save you from a DELETE the database login is allowed to run. Part 4 covers this in detail.
Second, upgrades. Version 3.0 renames some commands and tool prefixes, changes response wrappers, moves configuration namespaces and, for custom HTTP clients using the newer MCP protocol version (2026-07-28), requires additional headers. Saved calls that relied on removed options will fail. An MCP server upgrade can break an agent's behaviour without breaking anything a conventional test would catch. Part 5 treats it as a production change.
Why this matters in South Africa
Many South African platform teams are small. The same three or four engineers run identity, networking, pipelines and on-call. That makes an assistant that can query the estate attractive, and it makes standing privilege more likely: the engineer who installs the tool often holds broad rights because there is nobody else to hold them. Running the server under a person's identity quietly gives the agent everything that person can do.
Data handled through these tools is also subject to POPIA. A monitor query that returns log lines with customer identifiers, sent to a model provider in another jurisdiction, is a processing decision, not just an engineering convenience. The questions to ask before AI touches your data apply to the tool path as much as to the chatbot.
A 30-day adoption plan
| Week | Do this | Evidence at the end |
|---|---|---|
| 1 | Inventory who already runs an MCP server against Azure, under which identity | List of installations, identities and subscriptions |
| 2 | Stand up one read-only server, dedicated identity, development subscription, short tool list | Configuration in the repository; role assignments exported |
| 3 | Run one real workflow end to end: Advisor recommendation to Terraform pull request | Pull request, plan output, reviewer, pipeline run |
| 4 | Write the authority decision: what may be inspected, prepared and executed, where, by whom | Signed authority matrix; date for the next review |
Do not enable write tools until that authority decision exists. Do not treat the stable label as a security review.
Next: Part 2, Read-only is a starting architecture, not a governance programme. All parts are on the series page.
How CloudNala can help
In an MCP readiness review, CloudNala would inventory the MCP servers already connected to your cloud, map the identities and scopes they run under, set up a read-only pilot in a development subscription, and help you write the authority matrix that decides what an agent may inspect, prepare and execute. The output is a configuration in your repository and a decision record your security and change teams can sign.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Readiness Review or write to us at consult@cloudnala.co.za