An engineer asks an Azure agent why an app is slow. Microsoft's threat model asks what else it could do

An on-call engineer opens an incident and asks an AI assistant: “Why is this application slow?” The assistant queries Azure Monitor, reads Log Analytics, inspects the App Service configuration and compares it with a healthy deployment. Work that took several portal blades, CLI commands and Kusto queries happens in one conversation.

Now connect the same assistant with the engineer’s own Azure session. That session can probably restart workloads, change network rules and read Key Vault secrets, across several subscriptions. The question was diagnostic. The authority is not.

That gap is the starting point of a threat model Microsoft published on October 16 for AI assistants connected to Azure through Azure MCP Server. It is guidance, not a product release, and its value is that it is specific to one platform. Generic advice about agents and prompt injection is easy to find; a list of what goes wrong when an agent touches subscriptions, role assignments and Log Analytics workspaces is not.

The read surface and the write surface

A latency investigation needs a small read surface. A borrowed personal session carries a large write surface. Microsoft’s first threat is that mismatch: a model mistake or a compromised client becomes a control-plane risk because the identity can do far more than the task requires.

The recommended controls are ordinary Azure ones: a dedicated or managed identity per workflow, role assignments scoped to the resource group or resource, custom roles when built-in ones are too broad, diagnostic roles separate from remediation roles, and Privileged Identity Management for time-bound elevation. One sentence in the post deserves repeating to every team that configures agent tools: tool filtering is useful, but it is not authorization. Hiding a tool from the agent does not stop the identity from calling the API by another route. The resource provider has to deny it.

The guide also warns that Azure role assignments are additive. Granting a test identity Reader does not remove broader permissions it inherits through a group, a subscription or a management group. An agent’s real authority is its effective access, not the role you just assigned.

Logs are written by strangers

Azure Monitor and Log Analytics hold text from request paths, exception messages, user agents and tickets, and some of it is attacker-controlled. Microsoft’s example is a log line telling the assistant to fetch a Key Vault connection string and send it to an endpoint. That is data, not an instruction from the engineer.

The structural answer is not better prompting. A diagnostic identity should simply lack secrets/get on Key Vault and write access to production, so a manipulated assistant asks and is refused. We made the same argument about agent execution roles deciding the damage on another cloud.

Mistakes that need no attacker

The most practical part of the guide covers failures with no adversary at all: the wrong subscription, two similarly named resource groups, a staging resource ID, “restart the unhealthy instance” read as permission to restart a whole service. Schema validation checks that an argument has the right type. Azure operations also need semantic validation: is this tenant, subscription, resource group and resource the one the workflow is approved for, and is the change window open?

For consequential actions Microsoft proposes a fixed sequence: propose, validate target and arguments, obtain approval, execute, verify the resource state. The approval shows the exact subscription, resource, operation, parameters, expected impact and rollback plan, and if any of those values change, the approval is void. For production, the assistant can prepare a deployment or a pull request while the existing change process executes it.

Two smaller points will save someone an outage. A timeout does not prove an operation failed, so query the operation and resource state before retrying. And the Azure Activity Log typically does not record reads, so an investigation that needs to know what an agent looked at depends on resource diagnostic logs and the MCP server’s own logs.

Interpretation and authority stay in different hands

The assistant

• Reads approved telemetry
• Correlates and explains
• Proposes a change with its exact target

Can be wrong or manipulated

Azure

• Entra identity and RBAC scope
• Read-only server mode and tool selection
• Approval tied to exact target
• Activity, resource and MCP logs

Decides what actually happens

Test the refusals before granting the access

The guide ends with a read-only demo that connects GitHub Copilot in Visual Studio Code to Azure MCP Server with a dedicated test identity, a narrow set of service namespaces and read-only mode. Its most reusable step is the list of requests that must fail: restart the app, read a Key Vault secret, assign Contributor to the agent’s account, query another subscription, follow an instruction planted in a log. Each should be refused by configuration or by RBAC, not by the model’s good sense. If one succeeds, the identity is wrong, and the fix is in Azure, not in the prompt.

That checklist is the right gate for any infrastructure agent on any cloud. Expand access only when the team can show the failure behavior is enforced, the same principle behind agents that never hold a credential. Microsoft also advises against running a local Azure MCP Server with production data or credentials at all; a production deployment needs its own reviewed architecture.