[Kusto] Add AZURE_MCP_DANGEROUSLY_ALLOW_ADDITIONAL_KUSTO_HOSTS env var for internal proxies

[tloula]

Summary

Adds an opt-in environment variable AZURE_MCP_DANGEROUSLY_ALLOW_ADDITIONAL_KUSTO_HOSTS (comma-separated hostnames) that extends the Kusto SSRF allowlist to include user-specified hosts. This unblocks scenarios where Kusto queries need to be routed through internal proxies (e.g., a regional fan-out proxy hosted on *.azurewebsites.net) without disabling SSRF protections globally.

Motivation

Our team runs an internal multi-region Kusto proxy that routes queries to the appropriate regional cluster based on context. The Kusto desktop and web explorers support adding trusted hosts via UI, but the Azure MCP server rejects any host outside *.kusto.windows.net / *.kustomfa.windows.net / *.kusto.azuresynapse.net, with no way to override.

Design

• New const AdditionalTrustedHostsEnvVarName in KustoClient.cs.
• IsValidKustoHost now also accepts hosts present in the env var (case-insensitive, trimmed).
• Naming follows existing AZURE_MCP_DANGEROUSLY_* precedent (DISABLE_HTTPS_REDIRECTION, ENABLE_FORWARDED_HEADERS).
• Default behavior is unchanged — variable must be explicitly set.

Changes

• tools/Azure.Mcp.Tools.Kusto/src/Services/KustoClient.cs — env var support.
• tools/Azure.Mcp.Tools.Kusto/tests/.../KustoClientTests.cs — 6 new tests.
• servers/Azure.Mcp.Server/TROUBLESHOOTING.md — new troubleshooting section.
• servers/Azure.Mcp.Server/changelog-entries/1777483696796.yaml — Features Added entry.
• core/.../ClearEnvironmentVariablesBeforeTestAttribute.cs — env cleanup for tests.

Validation

• 70/70 unit tests pass (Azure.Mcp.Tools.Kusto.UnitTests).
• cspell clean.
• Locally built azmcp.exe confirmed working against an internal proxy with the variable set.

Invoking Livetests

Copilot submitted PRs are not trustworthy by default. Users with write access to the repo need to validate the contents of this PR before leaving a comment with the text /azp run mcp - pullrequest - live. This will trigger the necessary livetest workflows to complete required validation.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds an opt-in environment variable (AZURE_MCP_DANGEROUSLY_ALLOW_ADDITIONAL_KUSTO_HOSTS) to extend the Kusto SSRF allowlist with explicitly configured hostnames, enabling routing through internal proxies without disabling SSRF protections globally.

Changes:

• Added env-var-based additional trusted-host validation in KustoClient host allowlist logic.
• Added unit tests covering env var presence, parsing, and case-insensitive matching.
• Documented troubleshooting guidance and added a changelog entry; ensured test env cleanup includes the new variable.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tools/Azure.Mcp.Tools.Kusto/src/Services/KustoClient.cs	Implements env-var parsing and host matching to extend SSRF allowlist
tools/Azure.Mcp.Tools.Kusto/tests/Azure.Mcp.Tools.Kusto.UnitTests/KustoClientTests.cs	Adds unit tests validating behavior with/without env var and parsing edge cases
servers/Azure.Mcp.Server/TROUBLESHOOTING.md	Documents how to use the env var and warns about SSRF/token risks
servers/Azure.Mcp.Server/changelog-entries/1777483696796.yaml	Records the new env var feature in changelog format
core/Microsoft.Mcp.Core/tests/Microsoft.Mcp.Tests/Helpers/ClearEnvironmentVariablesBeforeTestAttribute.cs	Adds new env var to test-time environment cleanup list

[github-actions]

Thank you for your contribution @tloula! We will review the pull request and get back to you soon.

[jongio]

Follows the existing AZURE_MCP_DANGEROUSLY_* convention well. Tests cover the key scenarios (set/unset, comma-separated, case-insensitive, HTTP rejection), and the TROUBLESHOOTING doc update includes a clear security warning.

One thing to flag: GetKustoScope() determines the token audience by inspecting the cluster hostname suffix. Custom proxy hostnames (e.g., kusto-proxy.example.com) won't match any sovereign cloud suffix, so the token always targets the public cloud Kusto endpoint (kusto.kusto.windows.net/.default). This is fine for proxies routing to public cloud clusters but would silently produce the wrong token if someone routes through a proxy to a sovereign cloud (China/US Gov) cluster. Worth a note in the troubleshooting section, or a follow-up to support a scope override env var.

[jongio]

Addresses my previous feedback. The loopback/IP literal guard is the right approach - IPAddress.TryParse catches all literals, and the check runs before the env var read. Troubleshooting note for sovereign scope is clear. Looks good.

[xiangyan99]

Why use environment variables instead of explicit startup options?

I feel like environment variables can get messed with without users even noticing. What do you think?

[tloula]

@xiangyan99 this was my reasoning:

• The codebase already uses AZURE_MCP_DANGEROUSLY_* env vars for similar opt-in security toggles (e.g., AZURE_MCP_DANGEROUSLY_DISABLE_*), so this slots in next to them. Keeping it consistent felt more valuable than introducing a parallel CLI-flag pattern just for this one knob.
• MCP servers are launched from a JSON config block where both args and env are first-class, so from a "user has to consciously edit their config to set this" standpoint they're equivalent.
• It's a deployment-time setting, not a per-call argument. Env vars feel like the natural fit for that vs. polluting the startup arg surface.

[xiangyan99]

@xiangyan99 this was my reasoning:

• The codebase already uses AZURE_MCP_DANGEROUSLY_* env vars for similar opt-in security toggles (e.g., AZURE_MCP_DANGEROUSLY_DISABLE_*), so this slots in next to them. Keeping it consistent felt more valuable than introducing a parallel CLI-flag pattern just for this one knob.
• MCP servers are launched from a JSON config block where both args and env are first-class, so from a "user has to consciously edit their config to set this" standpoint they're equivalent.
• It's a deployment-time setting, not a per-call argument. Env vars feel like the natural fit for that vs. polluting the startup arg surface.

'AZURE_MCP_DANGEROUSLY_DISABLE_' is only used in HTTP mode. If I understand correctly, the new env var you are introducing works for both HTTP and stdio (local MCP server)?

[tloula]

'AZURE_MCP_DANGEROUSLY_DISABLE_' is only used in HTTP mode. If I understand correctly, the new env var you are introducing works for both HTTP and stdio (local MCP server)?

Ah then yeah, the precedent doesn't quite apply here. I could switch to a CLI flag, but since KustoClient reads this at tool-invocation time (not server startup), it'd need plumbing through a config service vs. the self-contained env var lookup. Happy to do it if you think the ergonomics are worth the extra surface area though.