AKS-MCPは、AIアシスタントを可能にするモデルコンテキストプロトコル(MCP)サーバーです Azure Kubernetes Service(AKS)クラスターとやり取りするために機能します。これはブリッジの役割を果たします GitHub Copilot、Claude、その他のMCP互換AIなどAIツール間で アシスタント)およびAKSを使い、自然言語のリクエストをAKS操作に翻訳します そしてAIツールが理解できる形式で結果を返すこと。

AIツールは以下のことを可能にします:

• AKSリソースの運用(CRUD)
• AKSクラスタ(VNet、サブネット、NSG、ルートテーブルなど)に関連する詳細を取得する
• マルチクラスタシナリオ向けのAzureフリート運用管理

サポートされた展開モデルとセキュリティ上の考慮事項

**AKS-MCPは、単一の信頼できるユーザーによってローカルでブリッジとして実行されるよう設計されています そのユーザー自身のAIアシスタントと自身のAzure/AKSリソースの間で、 プロジェクトがサポートし強化する唯一のデプロイメントモデルです。

信頼の境界線

AKS-MCPはコマンドラインツールを実行します — az、kubectl、helmなど、 cilium、およびhubble — 実行するプロセスの単位を用いる。それは 発信者ごとの承認は行わず、サンドボックスも試みません 実行されるコマンド。したがって:

AKS-MCP

The AKS-MCP is a Model Context Protocol (MCP) server that enables AI assistants to interact with Azure Kubernetes Service (AKS) clusters. It serves as a bridge between AI tools (like GitHub Copilot, Claude, and other MCP-compatible AI assistants) and AKS, translating natural language requests into AKS operations and returning the results in a format the AI tools can understand.

It allows AI tools to:

• Operate (CRUD) AKS resources
• Retrieve details related to AKS clusters (VNets, Subnets, NSGs, Route Tables, etc.)
• Manage Azure Fleet operations for multi-cluster scenarios

Supported Deployment Model and Security Considerations

AKS-MCP is designed to be run locally, by a single trusted user, as a bridge between that user’s own AI assistant and their own Azure/AKS resources. This is the only deployment model the project supports and hardens for.

The trust boundary

AKS-MCP executes command-line tools — including az, kubectl, helm, cilium, and hubble — using the identity of the process it runs as. It does not perform per-caller authorization, and it does not attempt to sandbox the commands it runs. Therefore:

Anyone who can invoke AKS-MCP tools effectively has the full Azure and Kubernetes privileges of the identity AKS-MCP is running under.

This includes the ability to obtain reusable credentials. For example, in readwrite or admin mode a caller can reach Azure Resource Manager and AKS with the server identity’s full authority, and kubectl or helm can be used to read Secrets, mint service account tokens, or deploy arbitrary workloads into the cluster. This is an inherent consequence of exposing a CLI execution surface — it is not prevented by --access-level.

Specific credential-returning Azure CLI commands (such as az account get-access-token and az aks get-credentials) are rejected by an explicit denylist. That denylist reduces accidental exposure — it is not a security boundary, it does not cover the kubectl, helm, cilium, or hubble surfaces, and it must not be relied upon to contain an untrusted caller.

Treat the ability to call AKS-MCP as equivalent to handing over a shell that is already logged in as the server identity.

Network exposure and local authority

Removing HTTP/SSE transports and the official remote deployment artifacts removes the supported network-reachable service and its remote-caller threat model. In the supported configuration, AKS-MCP has no listener that accepts requests from the network.

This does not make the local MCP client, its prompts, or --access-level an authorization boundary. A person or process that controls the local client, its server configuration, or AKS-MCP can normally run the same CLI commands under the same identity without AKS-MCP. Protecting the workstation, client