CLOUD

azure-mcp

Microsoft's official MCP server for Azure resources: subscriptions, resource groups, storage, Cosmos DB, Key Vault, Monitor, and more. Workload-aware scopes.

Alive Recommended REVIEWED 2026-05-07
VERDICT

Default for Azure-side agentic infra ops. Microsoft's RBAC + Conditional Access give you the strongest fine-grained access story of any cloud MCP — exploit it.

What it does

Wraps the Azure REST API as MCP tools. Tools cover resource enumeration (list_subscriptions, list_resource_groups, list_resources), per-service operations (Cosmos DB queries, Storage blob ops, Key Vault secret retrieval, Log Analytics queries), and management plane changes (start/stop VMs, update tags).

When you actually need it

If your infra is on Azure and you want an agent that can answer questions or take actions across it. Common patterns:

  1. “What’s running in resource group X right now?” Agent enumerates, returns a structured summary.
  2. Log analytics queries from natural language. Agent translates “why was the API slow yesterday” into a KQL query, runs it, summarises the result.
  3. Tag governance. Agent finds resources missing required tags, drafts the tag updates, waits for approval, applies.
  4. Cost investigation. Agent pulls cost data, identifies anomalies, drafts a writeup.

Setup

Three auth options — pick for your deployment:

  • Azure CLI auth (development): the agent inherits whatever az login produced. Works locally; not for production.
  • Managed identity (preferred for production agents): no secrets at rest, scope via RBAC.
  • Service principal (for CI / cross-cloud): client ID + secret in env. Workable; rotate often.
"azure": {
  "command": "npx",
  "args": ["-y", "@azure/mcp"],
  "env": {
    "AZURE_TENANT_ID":     "…",
    "AZURE_CLIENT_ID":     "…",
    "AZURE_CLIENT_SECRET": "…",
    "AZURE_SUBSCRIPTION_ID": "…"
  }
}

The catch

Azure RBAC is the safety lever. The agent’s permissions are exactly what the auth principal has — no more, no less. Two non-negotiables:

  1. Scope the role assignment narrowly. “Reader on one resource group” for explore-only agents. Custom roles with specific Microsoft.Storage/*/read actions for narrower needs. Never Owner or Contributor at the subscription level.
  2. Pair with Conditional Access. Block authentication from countries you don’t operate in, require trusted networks, require device compliance. The agent’s effective blast radius drops to “what this principal can do, FROM these network locations”.

For agents that write (start VMs, update configurations, write to Key Vault), add a host-level approval gate so destructive Azure ops require explicit per-call confirmation.

▸ MCP SECURITY SCORECARD Methodology v1.0 · Confidence HIGH · Reviewed 2026-05-07 · Next review due 2026-08-07
METHODOLOGY ↗
ADOPT

FOR: Azure infrastructure operations using a managed identity or service principal scoped narrowly via RBAC.

Use it. Azure RBAC is best-in-class for fine-grained scope — exploit it. Managed identity beats service principal where available. Pair with Conditional Access policies. Host-side approval gates for destructive ops.

Maintainer corp

Maintained by Microsoft Azure team.

Licence MIT

Microsoft's standard OSS licence.

Code review yes

Azure team maintains; PRs go through Microsoft internal review.

Secrets handling scoped

Service principal credentials passed via env; managed identity is preferred (no secret at rest).

Sandbox process
Filesystem access none

Server itself doesn't read host filesystem; some tools (blob upload) take a path argument from the agent.

Shell access no

No shell exec tools; Run Command on VMs is intentionally not exposed.

Network egress allow-list

management.azure.com, login.microsoftonline.com, and per-service endpoints (storage, cosmos, etc.) only.

OAuth handling scoped

Azure RBAC + scope is the strongest fine-grained access model in the cloud MCP space — per-resource, per-action, per-condition.

Default permissions moderate

Whatever the auth principal has. With a properly-scoped reader role: small. With Owner: very broad.

Prompt-injection exposure medium

Tool output (resource configs, log content, KV secret values) can carry user-authored content. Lower exposure than browser/filesystem MCPs because most output is structured Azure-resource shape.

Supply chain surface low

Microsoft-maintained Azure SDKs as direct deps.

Dep CVE surface clean
Rate-limit risk medium

Azure APIs throttle per-resource-type. Bulk enumeration on busy subscriptions can hit 429s.

Signed releases yes

npm package with provenance attestations; binary releases via Microsoft's signing infrastructure.

Security policy yes

Microsoft's coordinated vulnerability disclosure applies.

Telemetry opt-in

Microsoft's standard telemetry — disable via env var.

Data residency cloud

Wherever your Azure resources live. Resource data residency is governed by region selection at provisioning.

Credential storage memory

Tokens / secrets live in process env. Managed identity tokens auto-refresh from IMDS.

DESTRUCTIVE TOOLS

5 present · human approval optional

  • start_vm
  • stop_vm
  • update_resource_tags
  • set_keyvault_secret
  • delete_resource

NOT A FORMAL SECURITY AUDIT · Adoption posture based on public-source review · See methodology for what's measured and what isn't