[Feature]: Shouldn't this be some kind of Opt-In and not enabled by default by using a first-party App ID ?

### Problem Statement / Motivation

- Although the Azure MCP server will wield the access rights of the user. This relies on a "perfect" RBAC configuration.
- We might want want to "gate" this tool into our organization to begin with.
- As the tool will very quickly allow a user to "exploit" any RBAC overprovisioning and deploy resources or even child resources, in an unwanted unapproved way.
- I don't think this is a purely theoretical concern.
- It's suggested that we deploy Azure policy to **prevent** the app ID from performing ARM template deployment. But this is not my point.

### Proposed Solution

- I am not sure of the best way to "gate" this tool into our organization.

### Alternatives Considered

- Is there some kind of administrator approval gate for deployments that I haven't thought of

### Additional Context

- I feel very wary about this and whether ARM is not a place I want any of our administrators playing with AI at all.

Start by reviewing how the Azure MCP server uses its first-party App ID and how Azure RBAC currently authorizes ARM template deployments. Compare the proposed opt-in, Azure Policy, and administrator-approval approaches. Done should mean a clearly defined organization-level gate that prevents unapproved use while preserving intended access.

Written by the indexing model from the issue text.