AKS-MCP는 AI 어시스턴트를 가능하게 하는 모델 컨텍스트 프로토콜(MCP) 서버입니다 Azure Kubernetes Service(AKS) 클러스터와 상호작용할 수 있습니다. 이 서비스는 브리지 역할을 합니다 GitHub Copilot, Claude 등 AI 도구들 사이에서 어시스턴트) 및 AKS를 통해 자연어 요청을 AKS 작업으로 변환합니다 그리고 AI 도구가 이해할 수 있는 형식으로 결과를 반환하는 것입니다.

AI 도구는 다음과 같은 기능을 가능하게 합니다:

• 운영(CRUD) AKS 자원
• 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