Azure MCP Server

In its default local (stdio) mode the server signs in with whatever Azure identity the user already has (VS Code, Azure CLI, environment, managed identity or an interactive browser login) and every tool uses that one identity, so it can do anything the user can do across all their subscriptions and tenants. There is no narrower identity, no per-tool credential and no authorization check of its own beyond Azure RBAC; local helper processes (azd, azqr) inherit the full environment. When deployed as an authenticated remote HTTP server it instead exchanges each caller's token on-behalf-of that user, checks the tenant and fails closed, which is a much better design but is not the default deployment.

The server has a real, server-side confirmation step: commands marked destructive or secret-handling trigger an MCP elicitation asking the user to approve or reject, the run is refused if the client cannot show the prompt, and command metadata defaults to destructive when a developer forgets to set it. But in the default namespace mode the tools the host sees carry no read-only or destructive hints, the prompt names the tool without showing its arguments, about 60 state-changing commands are marked non-destructive and run without confirmation (sending email and SMS, uploading local files to blob storage, writing SRE Agent memory and scheduled tasks), and proxied tools from other MCP servers (ARM, Foundry, azd) skip the gate. One tool, SRE Agent 'investigate_yolo', is marked non-destructive and automatically grants every pending SRE Agent approval request in the user's name, so the model can satisfy another agent's human-approval gate.

Tools are typed commands with named options rather than a generic HTTP or shell tool, and many service endpoints pass through an allowlist-based SSRF validator (HTTPS only, Azure domain suffixes, private-IP and DNS checks). SQL and KQL tools accept raw queries filtered only by single-statement, no-comment and management-command denylists; the blob upload tool reads any local file path without containment; validation is per tool rather than one central policy. A --read-only switch and --namespace/--tool filters exist, but by default every service area including write tools is exposed against all of the user's subscriptions.

The server does not run a shell, but model-influenced text is interpreted in several places: raw SQL and KQL queries run on remote databases under the user's identity, the azqr tool launches an external process whose argument handling is not strict, and the azd MCP server is launched as a local subprocess. None of this runs inside any isolation boundary: subprocesses run as the user with the server's full environment, including any Azure credentials in environment variables. No sandbox, container or restricted runtime exists in the code.

The server returns results as a JSON envelope (status, message, results) that separates data from metadata, but nothing marks returned content (blob data, Cosmos items, log rows, SRE Agent messages, proxied MCP results) as untrusted, and the server's own description and some error responses carry instructions to the model mixed with returned content. The read-only mode that would remove the state-change leg is off by default. If the host model is hijacked by content it reads, it can exfiltrate data through ungated tools such as email or SMS send without any human prompt, while destructive Azure operations still require the user's approval through elicitation.

The server itself keeps no long-term memory (caches are in-memory) and loads its settings only from its install directory, environment variables and command-line flags, never from the user's workspace. However, it exposes SRE Agent tools that write to that agent's persistent knowledge base, common prompts and scheduled tasks; these are marked non-destructive, so they run without any confirmation, and whatever the model writes there is retrieved by the SRE Agent in later investigations for every user of that agent and can trigger its actions. Poisoned content read in one session can therefore become a durable instruction for another agent.

Besides its own tools, the server proxies other MCP servers listed in a registry file compiled into the binary: Microsoft Learn docs, Foundry and ARM remote servers, and the azd CLI, which it launches locally from whatever 'azd' is first on PATH with only a minimum-version check. This proxying is on by default with no consent prompt, nothing is pinned or integrity-checked, and remote tool definitions are fetched at runtime without detecting changes. The workspace cannot add servers, but the launched azd process runs as the user with the server's entire environment.

The server stores no API keys of its own and relies on Azure Identity for tokens. Secret-returning tools (Key Vault secret get, app settings) are flagged and require user confirmation before secret values are sent to the model, and SRE Agent connector secrets are redacted in results. Usage telemetry is on by default and goes to Microsoft; it records tool names, parameter names (not values), the subscription ID and exception stack traces. There is no general redaction layer for logs or tool results, and spawned processes inherit the full environment.

By default the operator gets no local record of tool calls: the stdio host logs only to an in-process EventSource, and per-call logging is at Trace level. Each call does produce a structured telemetry span (tool, parameter names, status, subscription), but by default it goes only to Microsoft. Operators can opt in to sending these spans and logs to their own Application Insights or an OTLP collector, which gives an off-host, correlated record, though it never includes argument values and export is best-effort.

The server enforces some bounds on its own work: Azure SDK retries, delays and network timeouts are clamped to hard ceilings (10 retries, 60 s delay, 300 s timeout) that callers can't exceed unless the operator passes a dangerously-named flag, external processes time out after 300 s and are killed on timeout or cancellation, and query tools cap length and rows. There is no rate limiting on side-effecting tools and no overall cap on how many calls run, and long-running Azure operations continue in Azure after a call is cancelled.