Add a365 network vnet for linking an Azure VNet to Agent 365

[Lala Sushant Srivastava (lasrivas)]

Adds a365 network vnet link|unlink|status.

Why

The documented subnet-injection flow (Learn) ends with Enable-SubnetInjection from the Microsoft.PowerPlatform.EnterprisePolicies module, which takes an -environmentId. Agent 365 provisions a managed Power Platform environment per tenant and does not publish its id, so admins cannot finish the flow today.

These subcommands replace only that last step. Everything before it — creating the subnets, delegating them to Microsoft.PowerPlatform/enterprisePolicies, and New-SubnetInjectionEnterprisePolicy — is unchanged.

The one non-obvious decision

The policy systemId read stays in the CLI rather than in MCP Platform. It is a plain ARM GET against a resource the admin already owns, and doing it client-side with the admin's own az login means the platform needs no delegated ARM user_impersonation consent grant, no ARM endpoint configuration per cloud, and no new security review. The platform side is pure S2S to BAP.

ArmApiService.GetEnterprisePolicySystemIdAsync tries 2020-10-30 then falls back to 2020-10-30-preview; the PowerShell module uses Get-AzResource without an explicit version and the two are both attested in different places.

What a reviewer should check

• VNetLinkService.WaitForCompletionAsync — 10s poll, 10min default ceiling, Stopwatch-based.
• Exit codes: 1 on Failed or request error, 0 otherwise, including a still-running operation when --wait is absent. That last case is deliberate.
• --swap semantics: relinking the same policy is a no-op that succeeds without the flag; a different policy is a conflict unless --swap is passed.

Dependencies

Requires the server side, MCP-Platform PR #3655, which adds POST /agents/vnet/link, /unlink, and GET /agents/vnet/status. The CLI app also needs consent for the new AgentTools.VNet.* scopes.

Review feedback addressed

• ARM URL injection. --policy-arm-id was concatenated onto https://management.azure.com (no trailing slash) while the ARM bearer token is a default request header, so --policy-arm-id "@evil.example/x" made management.azure.com userinfo and sent the token to the attacker's host. Now shape-checked against an explicit /subscriptions/{guid}/resourceGroups/../providers/Microsoft.PowerPlatform/enterprisePolicies/.. pattern.
• NotStarted counts as in-flight. IsRunning matched only Running, so a queued operation looked terminal to --wait.
• Tokens are tenant-targeted. The Agent 365 token was acquired with a login hint but no tenant, leaving the authority at common; the Windows broker ignores the hint and can return a different account -- on a tenant-wide setting that means changing the wrong tenant.
• --tenant-id and --yes. Explicit tenant override (blank is rejected rather than silently falling back), and confirmation on every mutating path: vnet link (with or without --swap) and vnet unlink. status is not gated, being read-only. (Superseded the earlier narrower gating -- see the sixth round below.)
• CommandNames.Network is now used instead of a duplicate literal.
• Tests no longer shell out to az. VNetLinkService takes the repo's existing loginHintResolver seam. Handler bodies are now invoked directly (tenant resolution, service calls, exit codes), not just ReportAsync; 8 of the new cases are malicious --policy-arm-id inputs.
• CHANGELOG trimmed to one sentence with the PR reference.

Second review round (2e6d896)

• The --wait ceiling now bounds an in-flight poll. The stopwatch only limited the gap between completed polls, so a poll starting inside the budget could run to the HttpClient's two-minute timeout and overshoot. The ceiling is armed on each request's token; a timeout mid-request reports the last known state, a caller's Ctrl+C still propagates.
• ArmApiService no longer swallows cancellation. Its broad catch converted the OperationCanceledException that RetryHelper deliberately rethrows into null, so Ctrl+C read as "could not read the policy" and link carried on as if it did not exist.
• docs/commands/network.md claimed az login was used "only to read the enterprise policy". It is the source of two defaults -- the tenant and the signed-in account -- and --tenant-id overrides only the first. No token is borrowed from Azure CLI; both the ARM read and the Agent 365 call acquire their own.
• Test helper fix worth flagging: FakeAuth configured GetAccessTokenAsync with matchers for 7 of its 8 parameters, omitting the CancellationToken. That pinned the setup to ct == default, so any call carrying a real token missed it and returned null -- no cancellation path was reachable in a test at all.

One finding from that round is not actioned, because I believe it is incorrect: RequiredClientAppPermissions is the CLI app's Microsoft Graph permission list, resolved against the Graph SP's oauth2PermissionScopes, so an Agent 365 Tools scope cannot go in it. Reasoning in this comment.

Third round (fcfa121, 419e2f3)

• VNetLinkService.SendAsync no longer rethrows HttpClient's own timeout as cancellation. It surfaces as an OperationCanceledException with no token cancelled, so a bare link, unlink or status threw at the caller instead of returning the documented null and logging the failure. Now rethrows only when the supplied token is actually cancelled, which still covers Ctrl+C and the wait ceiling firing on its linked token — the same shape as the ArmApiService fix in 2e6d896. Found on Add a365 network gsa enable|disable|status #497, which carries the identical code; not flagged here.

• A per-request HttpClient no longer disposes a handler it does not own. HttpClientFactory.CreateAuthenticatedClient built the client as new HttpClient(handler), which defaults to disposeHandler: true, so a service that holds one handler as a field and builds a client per request lost that handler to the first client's disposal. Every later request, including every poll after the first, would have failed with ObjectDisposedException against any handler with real disposal semantics. A supplied handler now stays owned by the supplier; a handler the factory creates itself is still disposed with the client.

Fourth round (c6d9f7b)

• The enterprise policy ARM id pattern was too strict in one direction and too loose in another. ARM ids are case-insensitive and the portal, CLI and ARM responses emit different casings, so legitimate ids spelled resourcegroups or microsoft.powerplatform were rejected; the pattern is now IgnoreCase, which does not weaken the host pin (that comes from the ^/subscriptions/ anchor). Dot segments were accepted and normalized to a different resource path, so both name segments now carry a ./.. lookahead. The anchor moved from $ to \z, but note that \z alone did not reject a trailing newline — [^/?#]+ absorbed it as part of the policy name; excluding whitespace from both segment classes is what actually rejects it, and ARM names cannot contain whitespace.

Tests

Full suite: 2142 passed, 0 failed, 12 skipped.

Fifth round (b0a71d7, 9f6fd17)

Two changes, both from reading the Microsoft.PowerPlatform.EnterprisePolicies module sources to check our split against the supported tool.

• Enterprise policies that are not NetworkInjection are now rejected here. The design moved this check to the CLI on the grounds that the CLI holds the whole policy object and can name what is wrong; it never actually landed. Every policy kind carries a systemId, so a CMK or Identity policy read back cleanly and failed later at BAP with an error naming nothing actionable. Six existing tests had ARM payloads with no kind field at all, which is why none of them caught it.

• unlink now resolves and sends policySystemId. The platform no longer retains it (MCP-Platform PR #3655, round 2 — the stored copy was a sliding cache entry, which put the recovery path behind a TTL), so a bodyless unlink is rejected. The CLI does the same two reads Disable-SubnetInjection does internally, just client-side: read the linked policy's ARM id from GET /agents/vnet/status, then read that policy from ARM on the admin's own Azure session — which also applies the kind check above.

  There is deliberately no bodyless fallback; there is nothing on the platform side left to fall back to. A failed ARM read is a client-side error that names the policy, because the usual cause is that it was deleted from Azure while still linked, and the admin cannot act on that without knowing which one. Nothing-linked short-circuits before any ARM call.

  The command surface is unchanged: a365 network vnet unlink still takes no policy argument.

Ordering: this needs MCP-Platform #3655 to ship first. Until it does, an unlink from this build sends a body the deployed platform ignores, which is harmless; after it ships, older CLI builds can no longer unlink. Both are accepted.

Sixth round (4c0f502)

origin/main merged in first, since several findings were scoped to the rebased state.

Security. The --policy-arm-id regex admitted % and \. Uri unescapes and normalizes before the request is sent, so resourceGroups/%2e%2e/... climbed the path after validation passed — pointing the admin's ARM bearer at a resource they never named. The subscription segment is now a strict GUID and the name segments an ARM allowlist ([-\w.()]+). Every vector is pinned as a reject row, including a 36-dash subscription id the old [0-9a-f-]{36} accepted.

No Uri.AbsolutePath guard was added: with the allowlist in place no accepted input normalizes differently, so the check could never fire. A branch that cannot execute rots. The property is held by the reject theory instead.

Correctness.

• Only an api-version error code advances to the next api-version. Any other 400 is about this request, and retrying buried the real reason behind "Azure rejected every supported api-version".
• authorityHost is passed on the Agent 365 token. This was the only Agent 365 Tools call authenticating against the commercial cloud on a sovereign one.
• The endpoint is built through ConfigConstants.BuildAgent365ToolsEndpointUrl; the local origin table is gone.
• --wait tolerates three consecutive failed status reads. A single transient 5xx reported a running link as failed, and printed no operation id to resume from.
• The two 403s are distinguished by required_scope. A role failure was being reported as a missing consent the admin cannot grant.
• Resolving the login hint honours the caller's cancellation token.

Command surface. Every link now confirms, not just --swap — subnet delegation can destabilise the environment for up to 30 minutes regardless of whether a policy is being replaced. Blank --policy-arm-id is rejected with a targeted message rather than an unexpected-error path. Unknown exits 1 and explains that operation ids are tenant-scoped. A running status with no operation id exits 1 rather than silently succeeding. Every resume hint carries --tenant-id.

Docs. Dropped the az login contradiction, narrowed the login-hint claim (it is not passed to the ARM read), replaced NotStarted with Unknown in the status table — the platform collapses every unsettled state to Running — and switched the walkthrough to New-SubnetInjectionEnterprisePolicy, noting -VirtualNetworkId2 for two-region geographies and the read-access requirement.

Tests. FakeAuth now matches all nine parameters. authorityHost was the third time an omitted matcher silently pinned a setup to a default, which makes success-path tests fail loudly but null-expecting tests pass while exercising nothing. Substitute.For<ArmApiService> takes constructor arguments so the real AuthenticationService constructor does not run. The zero wait budget that raced the first poll is now 5s. The poll interval is injectable, so retry tolerance is testable without 10s sleeps.

Full suite: 2420 passed, 0 failed, 12 skipped.

[github-actions]

⚠️ Deprecation Warning: The deny-licenses option is deprecated for possible removal in the next major release. For more information, see issue 997.

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[Copilot]

🟡 Changes recommended

Unresolved moderate findings remain in tenant validation, authentication, cancellation, polling, and test coverage.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds a365 network vnet link|unlink|status for managing Agent 365 VNet links through Power Platform enterprise policies.

Changes:

• Adds ARM enterprise-policy ID resolution with API-version fallback.
• Adds platform link, unlink, status, polling, swap handling, and exit codes.
• Adds CLI registration, models, tests, documentation, and changelog updates.

File summaries

File	Change	Final review findings
src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests/Services/VNetLinkServiceTests.cs	VNet service tests	Moderate (2 votes): Avoid real az account show calls and shared login-hint cache by using the override or injecting a resolver.
src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests/Services/ArmApiServiceTests.cs	ARM lookup tests	No findings.
src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests/Commands/NetworkCommandTests.cs	Command tests	Nit (3 votes): Invoke each handler to cover option wiring, service calls, and success/failure exit codes.
src/Microsoft.Agents.A365.DevTools.Cli/Services/VNetLinkService.cs	Platform API calls and polling	Moderate (3 votes): Treat NotStarted as in-flight. Moderate (1 vote): Bound status requests and delays to the remaining wait deadline.
src/Microsoft.Agents.A365.DevTools.Cli/Services/IVNetLinkService.cs	Service contract	No findings.
src/Microsoft.Agents.A365.DevTools.Cli/Services/ArmApiService.cs	Enterprise-policy lookup	Moderate (1 vote): The ARM request uses a separate MSAL token rather than the Azure CLI token; align the token flow or document separate authentication. Moderate (1 vote): Rethrow OperationCanceledException instead of converting cancellation to a null result.
src/Microsoft.Agents.A365.DevTools.Cli/Program.cs	Dependency and command registration	No findings.
src/Microsoft.Agents.A365.DevTools.Cli/Models/VNetModels.cs	Request and response models	No findings.
src/Microsoft.Agents.A365.DevTools.Cli/Constants/CommandNames.cs	Network command constant	No findings.
src/Microsoft.Agents.A365.DevTools.Cli/Commands/NetworkCommand.cs	CLI handlers and options	Moderate (3 votes): Reject explicitly blank --tenant-id values instead of silently resolving the current tenant. Nit (1 vote): Use CommandNames.Network instead of a hard-coded name. Moderate (1 vote): Treat a running operation without an OperationId as a request failure when waiting.
docs/commands/README.md	Command index entries	No findings.
docs/commands/network.md	VNet command documentation	No findings.
CHANGELOG.md	Unreleased feature entry	Nit (3 votes): Keep the changelog entry to one concise consumer-facing sentence and move implementation details to command documentation.

Review details

Suppressed comments (5)

src/Microsoft.Agents.A365.DevTools.Cli/Commands/NetworkCommand.cs:32

• CommandNames.Network is added for this command, but the constructor still hard-codes "network"; sibling registration uses CommandNames.Logs (LogsCommand.cs:19) and the constants documentation centralizes command names. Use the constant so command registration and log naming cannot drift if the name changes.

        var networkCommand = new Command("network", "Configure tenant networking for Agent 365");

src/Microsoft.Agents.A365.DevTools.Cli/Commands/NetworkCommand.cs:196

• When --wait is requested and the platform reports Running without an OperationId, this condition skips the wait; the method then returns 0 and prints an unusable --operation-id command. Since the CLI cannot verify completion in this case, treat the malformed response as a request failure (or obtain a status handle) instead of claiming success.

        if (wait && VNetLinkService.IsRunning(result.Status) && !string.IsNullOrWhiteSpace(result.OperationId))
        {
            logger.LogInformation("{Operation} is running. Waiting for it to settle...", operationLabel);
            result = await vnetLinkService.WaitForCompletionAsync(result.OperationId, DefaultWaitTimeout, cancellationToken);

src/Microsoft.Agents.A365.DevTools.Cli/Services/ArmApiService.cs:270

• This path does not actually use the existing az login access token: EnsureArmHeadersAsync obtains a separate MSAL token, while az account show only supplies the tenant ID. A user with a valid Azure CLI session may therefore be prompted again or use a different cached account. Either pass an ARM token from az account get-access-token, or update the documented prerequisite and flow to describe the separate MSAL authentication.

        if (!await EnsureArmHeadersAsync(tenantId, ct))
            return null;

src/Microsoft.Agents.A365.DevTools.Cli/Services/ArmApiService.cs:328

• This catch also absorbs OperationCanceledException from the HTTP call and converts cancellation into a normal null result. Ctrl+C during the ARM read is therefore reported as a policy-read failure rather than propagating cancellation, unlike the platform request path in VNetLinkService.SendAsync; rethrow cancellation before the general exception handler.

            catch (Exception ex)
            {
                if (NetworkHelper.IsConnectionResetByProxy(ex))
                    _logger.LogWarning(NetworkHelper.ConnectionResetWarning);
                else

src/Microsoft.Agents.A365.DevTools.Cli/Services/VNetLinkService.cs:129

• The budget is checked only after a status request, and a request can consume the remaining time before the method returns. If a poll starts near the deadline, the 10-minute --wait ceiling can be exceeded by the request timeout; compute the remaining budget before each poll and bound or cancel both the request and delay against that deadline.

            if (stopwatch.Elapsed + PollInterval >= timeout)
                return last;

            _logger.LogInformation("Still running... ({Elapsed:0}s elapsed)", stopwatch.Elapsed.TotalSeconds);
            await Task.Delay(PollInterval, cancellationToken);

• Files reviewed: 13/13 changed files
• Comments generated: 5
• Review effort level: Lite

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Rick Brighenti (rbrighenti)]

Requesting changes. The ARM URL construction lets the ARM bearer token be sent to an arbitrary host and needs fixing before merge. Details inline.

The open Copilot threads on this PR are also required, not optional: NotStarted not treated as running (so --wait can return early), blank --tenant-id silently falling back to az account show, the three SetHandler blocks never being invoked in tests, the static AzCliHelper call leaking into the service tests, and the multi-sentence CHANGELOG entry.

Stacking: #497 contains these same commits plus GSA but targets main, so it re-shows this whole diff. Please retarget #497 onto feature/network-vnet-link so it only shows the GSA changes; the VNet comments I left on #497 are really for this PR.

[Copilot]

Copilot review overview

🟡 Changes recommended

A critical VNet consent issue and several moderate CLI, ARM, polling, and resource-management issues remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1 · 3

Open (5)

• Add VNet permission to the canonical consent flow · New
• Bound in-flight status requests by the wait timeout · New
• Clarify release notes with concise user-facing command summary · New
• Document explicit tenant authentication behavior · New
• This [Unreleased] entry contains multiple sentences and implementation details (systemId, `az…

Resolved since last review (4)

• These tests fake authentication and HTTP, but VNetLinkService.SendAsync still calls the static…
• NotStarted is documented as an in-flight status, but this helper recognizes only Running. As a…
• An explicitly supplied blank or whitespace --tenant-id is treated as omitted and silently…
• These tests deliberately stop at ReportAsync, so none of the three new SetHandler blocks is…

[Lala Sushant Srivastava (lasrivas)]

Follow-up on the latest review round. Three of its four threads auto-resolved on the push, so recording the outcomes here.

Fixed in 2e6d896:

• The --wait ceiling didn't bound an in-flight poll. Correct, and the overshoot was up to the HttpClient's two-minute timeout on top of the stated budget. The ceiling is now armed on the token each request is made with. A timeout mid-request reports the last known state; a caller's Ctrl+C still propagates.
• docs/commands/network.md overstated the az login prerequisite. Also correct, and wrong in a second way the comment didn't mention: the ARM token isn't an Azure CLI token, it comes from the CLI's own AuthenticationService. Rewritten.

Fixing those surfaced a latent problem in the tests: FakeAuth in both service test classes configured GetAccessTokenAsync with matchers for 7 of its 8 parameters, omitting the CancellationToken. That pins the setup to ct == default, so any call carrying a real token missed it and returned null -- no cancellation path was reachable in a test at all. Fixed in the same commit.

Not fixed, because I believe it's incorrect: AgentTools.VNet.Manage.All is missing from AuthenticationConstants.RequiredClientAppPermissions.

That array is the CLI app's Microsoft Graph permissions. Every entry is a Graph permission, and ClientAppValidator.ResolvePermissionIdsAsync resolves each name against the Graph service principal's oauth2PermissionScopes. Adding an Agent 365 Tools scope would make a365 setup try to configure a Graph permission that doesn't exist, and fail validation.

The Agent 365 Tools token here is acquired as {atgAppId}/.default -- the same way all nine Agent365ToolingService calls do (AddMcpServerAsync, list servers, and the rest). None of them register anything in that array either, and none needed to. If the CLI app does need an explicit ATG delegated grant, that's a pre-existing gap across every Agent 365 Tools call in the CLI, not something this PR introduces, and the fix belongs in the consent flow rather than the Graph permission list.

Happy to be corrected if there's a consent path I've missed.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Three moderate findings remain unresolved.

Review effort: Lite
Findings: None

Resolved since last review (5)

• Add VNet permission to the canonical consent flow
• Bound in-flight status requests by the wait timeout
• Document explicit tenant authentication behavior
• Clarify release notes with concise user-facing command summary
• This [Unreleased] entry contains multiple sentences and implementation details (systemId, `az…

Previously missed (1)

In code that hasn't changed since last review

Validate empty policy ARM ID before linking

src/​Microsoft.Agents.A365.DevTools.Cli/​Commands/​NetworkCommand.cs:154

An explicit empty value (for example, --policy-arm-id "") satisfies IsRequired but reaches LinkAsync and throws ArgumentException. The command does not handle that exception, so the global handler reports the generic "Unexpected error"/bug message instead of a targeted invalid-option error; validate the option here and set exit code 1.

[Lala Sushant Srivastava (lasrivas)]

@microsoft-github-policy-service agree [company="Microsoft"]

[Lala Sushant Srivastava (lasrivas)]

@microsoft-github-policy-service agree company="Microsoft"

[Copilot]

Copilot review overview

🔵 Needs a closer look

Two moderate implementation issues and one status-contract issue remain unresolved.

Review effort: Lite
Findings: None

Previously missed (2)

In code that hasn't changed since last review

Avoid disposing the injected handler between requests

src/​Microsoft.Agents.A365.DevTools.Cli/​Services/​VNetLinkService.cs:200

The injected _handler is retained across calls, but CreateAuthenticatedClient constructs new HttpClient(handler) and this using disposes it after the first request. A second poll in WaitForCompletionAsync then reuses a disposed handler and returns a false failure, so the public test/custom-handler seam cannot support multi-request operations. Reuse one client for the service lifetime or create the client without transferring ownership of the injected handler.

Include NotStarted in the public status contract

src/​Microsoft.Agents.A365.DevTools.Cli/​Models/​VNetModels.cs:43

NotStarted is explicitly treated as an in-flight state by VNetLinkService.IsRunning and is listed in the command documentation, but it is omitted from this public status contract. Include it here so consumers of the model do not incorrectly treat the documented queued state as unknown.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Address empty --policy-arm-id validation and ensure login-hint resolution observes the wait cancellation ceiling.

Review effort: Lite
Findings: None

Previously missed (1)

In code that hasn't changed since last review

Honor --wait cancellation while resolving the login hint

src/​Microsoft.Agents.A365.DevTools.Cli/​Services/​VNetLinkService.cs:186

--wait's ceiling does not cover this await: ResolveLoginHintAsync ultimately runs az account show through a Func<Task<string?>> with no cancellation token, and it executes before the token reaches MSAL/HttpClient. If that subprocess hangs on the first status poll, WaitForCompletionAsync can block beyond its 10-minute ceiling despite the linked token. Make the resolver await observe cancellationToken (for example, await the returned task with WaitAsync(cancellationToken) or change the seam to accept a token).

[Rick Brighenti (rbrighenti)]

Thanks, the fixes look good and the token-leak issue is resolved. One last small change, inline, then this is good from my side.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Unresolved issues remain in changelog wording, tenant propagation, and cancellation of the initial Azure CLI resolver.

Review effort: Lite
Findings: None

Previously missed (1)

In code that hasn't changed since last review

Pass the cancellation token to the tenant resolver

src/​Microsoft.Agents.A365.DevTools.Cli/​Services/​VNetLinkService.cs:186

This resolver is awaited without the request token, so --wait's ceiling and Ctrl+C cannot interrupt az account show when the hint is not already cached. A stalled Azure CLI subprocess can therefore block the first poll indefinitely despite the documented timeout; await the resolver with the supplied cancellation token (or change the resolver seam to accept one).

[Krishnadheeraj (DheerajPannala)]

Thanks for the careful iterations on this. I went through the full diff, checked the request/response contract against the platform change it depends on (MCP-Platform PR 3655), and built and ran the suite both on this branch and merged onto current main. Details are inline; the summary:

Before merge

• Platform dependency: MCP-Platform PR 3655 has not merged yet, so these commands have nothing to call until it ships.
• Scopes (please confirm): the platform rejects any token without the exact scope (AgentTools.VNet.Manage.All for link/unlink, AgentTools.VNet.Read.All for status) with 403 insufficient_scope. This service requests {Agent 365 Tools app}/.default without a client id, so the token comes from the Azure PowerShell public client (1950a258-227b-4e31-a9cf-717495945fc2). Please confirm both scopes are exposed on the Agent 365 Tools app and pre-authorized for that client, in every cloud the CLI targets. If not, every command here returns 403 for every tenant, and the 403 hint points admins at a consent they cannot grant for a Microsoft client.
• Rebase onto main: #478 (cloud-aware endpoints) landed after this branched. Merged onto current main the branch builds, but one test fails deterministically (inline on VNetLinkServiceTests.cs, with a verified fix). #478 also added ConfigConstants.GetAgent365ToolsOrigin and an authorityHost parameter that every other Agent 365 Tools call now passes (inline on VNetLinkService.cs).
• Interaction with #497: both PRs create the network root command. With this repo's squash merges, whichever lands second conflicts in NetworkCommand.cs, Program.cs, NetworkCommandTests.cs, docs/commands/README.md and CHANGELOG.md (reproduced in both orders). The two groups also behave differently under one parent: vnet has --tenant-id and reads the az account twice (tenant, then login hint), while gsa has no --tenant-id and resolves the account once; gsa enable prompts while a first vnet link does not. Worth settling one set of semantics before the second PR merges.

Verified and looks right

• The ARM bearer token can no longer be sent to another host: every malicious id in the new theory is rejected before a request is made.
• HttpClient's own timeout is kept distinct from a real cancellation, and cancellation now propagates out of the ARM read.
• disposeHandler: false in HttpClientFactory is the right ownership model (the only other caller that passes a handler, DelegatedConsentService, benefits too).
• The tenant is threaded into both token requests.
• The wire shapes match PR 3655: policySystemId/policyArmId/swap in, status/policyArmId/operationId/reason out, error on failure.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Three moderate findings remain unresolved.

Review effort: Lite
Findings: None

[Copilot]

Copilot review overview

🟡 Changes recommended

Resolve the status failure mapping, confirmation behavior, and configured authority-host handling.

Review effort: Lite
Findings: 2 · 1

Open (3)

• Link command prompts unconditionally · New
• Unknown status incorrectly exits successfully · New
• Split oversized VNet test class into focused files · New

[Copilot]

Copilot review overview

🔵 Needs a closer look

status must treat Unknown or blank responses as failures; one negative-token test also needs complete parameter matching.

Review effort: Lite
Findings: None

Resolved since last review (3)

• Unknown status incorrectly exits successfully
• Link command prompts unconditionally
• Split oversized VNet test class into focused files

Previously missed (1)

In code that hasn't changed since last review

Treat unknown or blank platform status as command failures

src/​Microsoft.Agents.A365.DevTools.Cli/​Commands/​NetworkCommand.cs:300

status bypasses ReportAsync here and maps only Failed to exit 1. A platform response of Unknown (including an operation id from another tenant) or a blank status is rendered as Unknown but exits 0, contradicting the documented status contract and the corresponding ReportAsync handling. Treat Unknown/blank as failures here as well and add handler coverage for these responses.

[Lala Sushant Srivastava (lasrivas)]

All review threads on this PR are now resolved (0 unresolved) and CI is green on 0f40bfa.

Rick Brighenti (@rbrighenti) your CHANGES_REQUESTED is still recorded against the branch. Both of your threads are addressed -- the ARM host-injection fix landed in 5132585 (and was tightened further in 4c0f502: strict GUID plus an ARM-name allowlist, which also closes %2e%2e/%2F climbs), and RegexOptions.IgnoreCase is still on the pattern. Re-review when you have a moment.

Krishnadheeraj (@DheerajPannala) all 19 of your threads are fixed and resolved in 4c0f502, plus 0f40bfa for a null-status follow-up. Suite: 2423 passed, 0 failed, 12 skipped.