MCP & Agent Tooling

Best Ways to Give an AI Agent Access to a Windows Server in 2026

Six real ways to let an AI assistant like Claude or ChatGPT run PowerShell or shell commands on a Windows Server or Windows PC, ranked on native protocol support, setup effort and whether tooling built for Linux actually carries over to Windows.

By Arthur R. Published August 7, 2026 Updated August 7, 2026 10 min read

Quick answer

Most guides to letting an AI agent run server commands assume Linux and SSH, but Windows Server has its own native remote-management protocol (WinRM), its own optional SSH server, and cloud-native alternatives from AWS and Azure that need none of it — and at least one popular connectivity tool, Tailscale SSH, does not support Windows as a target at all.

Key takeaways

Tailscale SSH's own server-side authentication is not supported when the target machine is Windows — two feature requests asking for it (GitHub issues #14942 and #17261) remain open as of this writing, so Tailscale on Windows is a private-network layer only, not an AI-ready shell.
Windows Server 2025 is the first version of Windows to ship OpenSSH Server enabled by default; on Windows 10, Windows 11 and older Server releases it remains an optional feature you enable by hand.
PowerShell Remoting (WinRM) is Windows' own native remote-management protocol, free and proven for two decades, but the open-source MCP servers that expose it to AI agents are young — the two we found on GitHub carry 4 and 5 stars respectively.
AI Commander installs on Windows the same way it does on macOS and Linux, connecting outbound only, so it needs no WinRM listener enabled and no firewall rule opened on the Windows host.
AWS Systems Manager Run Command and Azure's Run Command on Arc-enabled servers both let you execute scripts on a Windows machine with zero inbound ports open at all, but neither one is conversational on its own — an agent still needs an API or MCP layer in front of them.
By default, enabling Windows OpenSSH Server gives a remote session in cmd.exe, not PowerShell, unless you explicitly set the DefaultShell registry value.

2025

First Windows Server version to ship OpenSSH Server enabled by default (Microsoft Learn)

Open Tailscale GitHub feature requests for Windows Tailscale SSH server support (#14942,

1.33+

Connected Machine agent version required for Azure Arc's Run Command (Microsoft Learn)

A Windows Server is not a Linux box with a different logo, and most “let an AI agent run commands on your server” advice quietly assumes it is. Windows has its own native remote-management protocol, WinRM, that has nothing to do with SSH; its own optional SSH server with its own default-shell quirk; and two major clouds now offer agentless, zero-port command execution built specifically to avoid RDP altogether. At least one popular connectivity tool that “just works” on Linux, Tailscale SSH, does not support Windows as a target at all. Below, six real ways to give Claude, ChatGPT or another AI agent command access to a Windows machine in 2026, ranked on how native the fit actually is, not on how well the option happened to work on Linux.

There is no single best way to do this — the right choice depends on whether the machine already runs WinRM, whether it lives on AWS or Azure, and how much Windows administration you are willing to do yourself. PowerShell Remoting (WinRM) ranks first as the fully native, zero-cost option, with the honest caveat that the open-source MCP servers built to expose it to AI agents are still young. AI Commander ranks second as the most accessible route on Windows specifically, because it needs no WinRM listener, no firewall rule and no certificate — it installs and connects the same way it does on macOS or Linux. The rest of the field splits between an SSH-based alternative that reuses Linux-style tooling, two cloud-native options from AWS and Azure that eliminate inbound ports entirely, and Tailscale, which is an excellent private mesh with one specific, verifiable gap on Windows.

WinRM and SSH are not the same protocol, and Windows treats them differently

The single biggest mistake in applying Linux advice to Windows is assuming SSH is the default. It is not. Windows’ native remote-management protocol is WinRM, reachable through PowerShell Remoting, and it has existed since Windows Server 2008 — long before Microsoft shipped its own OpenSSH Server. SSH on Windows is real, actively maintained by Microsoft, and as of Windows Server 2025 finally enabled by default, but on every earlier version — including the Windows 10 and Windows 11 machines many home labs and small teams still run — it is an optional feature you have to turn on yourself. Treating WinRM as an afterthought and SSH as the default, the way most cross-platform guides implicitly do, gets the Windows story backwards.

The practical consequence shows up the moment you enable OpenSSH Server and expect it to behave like it does on Linux. It does not: a fresh install drops an SSH session into cmd.exe, not PowerShell, until you explicitly point the DefaultShell registry value at powershell.exe. It is a small, easily missed step, and it is exactly the kind of Windows-specific detail that a generic “SSH plus MCP” writeup, written with Linux in mind, will not warn you about.

The connectivity layer doesn’t always follow you to Windows either

The same platform gap shows up one layer down, in how you reach the machine in the first place. Tailscale is the most-used private mesh VPN for exactly this kind of problem — no exposed ports, identity-based access — and its Linux and macOS story is excellent: Tailscale SSH handles authentication for you inside the mesh. On Windows, that specific piece is absent. Tailscale SSH’s server-side authentication does not support Windows as a target, and two feature requests on Tailscale’s own GitHub — issues #14942 and #17261 — are still open asking the company to add it. Tailscale as a client works fine on Windows, and the mesh itself still gets you private, portless reachability to the box. But once you arrive at a Windows machine over that mesh, something else — WinRM or Windows OpenSSH Server — still has to do the actual authenticating and command-running, with an MCP layer on top of that. It is a genuinely useful tool that simply is not, by itself, a Windows shell.

Cloud-native options remove the port question entirely — for machines on that cloud

AWS and Azure both solve the Windows access problem a third way, and it is worth understanding as a distinct category rather than a variant of SSH or WinRM. AWS Systems Manager Run Command and Azure’s Run Command on Arc-enabled servers both work by installing a managed agent on the Windows machine that dials out over HTTPS to the cloud provider; you trigger a script from the CLI, PowerShell module or REST API, and the agent executes it locally and streams back the result. No RDP, no SSH, no WinRM listener is ever exposed to reach the machine — the entire attack surface most Windows admins worry about simply is not there. The trade-off is that neither service is conversational by itself. An AI agent still needs an AWS-facing or Azure-facing MCP or API layer in front of the raw Run Command call, and — for Azure’s Arc-based version specifically — we did not find a dedicated MCP server built for it yet, only the broader, general-purpose Azure MCP tooling used for other resource management. These are the strongest options for a fleet of Windows machines already living inside one of those clouds; they solve nothing for a standalone Windows box sitting in an office closet.

Who each option actually fits

A Windows administrator who already runs WinRM across a domain and wants the most control at zero licensing cost should stay with PowerShell Remoting, accepting that the MCP bridge on top of it is a young piece of open-source tooling rather than a mature product — worth watching, not yet worth betting production reliability on. Someone who wants an AI assistant running commands on a Windows machine in minutes, with no WinRM listener to enable and no firewall console to open, should start with AI Commander, which installs the same way across a mixed Windows, macOS and Linux fleet. A team that already standardized on SSH-plus-MCP for its Linux servers and wants one consistent pattern everywhere should enable Windows OpenSSH Server — remembering to fix the default shell — rather than learning WinRM from scratch. An organization managing dozens or hundreds of Windows instances on AWS or Azure should reach for that cloud’s own Run Command first, since it removes the inbound-port question entirely for machines it already manages, and treat the missing conversational layer as a one-time integration cost rather than a dealbreaker. And anyone building a private mesh across a mixed fleet should still use Tailscale for the Linux and macOS side of it — just budget for WinRM or Windows OpenSSH doing the actual work once traffic reaches a Windows box.

Where this is heading

The gap this report surfaces — Windows-native tooling (WinRM, cloud Run Command services) lagging behind Linux in AI-agent readiness, while Linux-first tools (Tailscale SSH) simply skip Windows rather than solving it properly — is not likely to hold for long. MCP is becoming the default interface across this whole category, and Windows is too large a target for that pattern to stay this uneven. Expect the WinRM MCP wrapper ecosystem to mature past its current handful of single-digit-star projects, expect AWS and Azure to ship first-party, purpose-built MCP servers for Run Command rather than leaving developers to wire the CLI in by hand, and expect the cross-platform agents — AI Commander among them — to keep closing the gap by treating Windows as a first-class target from day one rather than a Linux port with an asterisk.

PowerShell Remoting (WinRM)

Most control at zero cost — but the MCP wrapper ecosystem is young

PowerShell Remoting, built on Windows Remote Management (WinRM), is Windows' own native protocol for running commands on a remote machine — no third-party agent, no relay, and a track record going back to Windows Server 2008. Once WinRM is enabled (Enable-PSRemoting) and a firewall rule opens the listener on port 5985 for HTTP or 5986 for HTTPS, any WinRM-aware client can authenticate and run PowerShell against the box. To make it AI-native, you pair it with an MCP server that speaks WinRM: open-source options such as win-mcp-server (4 GitHub stars, macOS-only client with Keychain-based credential storage) and windows-admin-mcp (5 GitHub stars, WinRM primary with an SSH fallback, run inside Docker) exist and work, but both are early-stage projects with single-digit stars and small commit histories rather than mature, widely deployed tools. That is the honest trade-off at the top of this list: it is the only option here that is entirely free, entirely native, and keeps every byte inside infrastructure you control, but turning it into something an agent can actually call still means wiring a young open-source bridge yourself.

Pros

Native and free: WinRM ships with Windows, with no license, subscription or third-party relay in the path
Maximum control: your credentials, your hosts, your firewall rules — nothing transits outside infrastructure you own
Works with domain-joined machines and on-prem fleets exactly as Windows admins already manage them

Cons

The MCP wrapper ecosystem is immature: the open-source WinRM bridges we found (win-mcp-server, windows-admin-mcp) carry single-digit GitHub stars and short commit histories
Real setup burden: enabling PS Remoting, opening the correct firewall rule and configuring an HTTPS listener for production use takes genuine Windows admin skill
HTTP (5985) is the default; you must configure a certificate and 5986 yourself for encrypted traffic

AI Commander

Most accessible — a Windows install with no WinRM or firewall config

AI Commander is a purpose-built remote shell for AI agents that installs the same way on Windows as it does on macOS and Linux servers or a Raspberry Pi: you run the installer, get a stable code such as AIC-7K3P-WX9M-RTBN, and Claude, ChatGPT, Codex, Cursor or Windsurf can run real commands on that machine in plain language from then on. The distinguishing trait for a Windows box specifically is that the agent connects outbound only — there is no WinRM listener to enable, no firewall rule to open on the Windows host, and no certificate to configure for an encrypted channel, because the machine dials out to a relay rather than waiting for an inbound connection. It exposes the same machine over MCP, a REST endpoint or a drop-in Skill.md, and a single account can manage a mixed fleet of Windows, macOS and Linux machines side by side. A new code works for anyone with no account for the first hour (verified on aicommander.dev), after which sign-in lets you name and manage machines long-term. It is the most accessible route on this list for anyone who does not want to touch Enable-PSRemoting, a firewall console or a registry key — the honest trade-off is that it routes through AI Commander's hosted relay rather than staying entirely inside your own network, which is the price of skipping every step above it.

Pros

Zero WinRM configuration: no listener, no firewall rule and no HTTPS certificate to set up on the Windows host
Same install flow across Windows, macOS and Linux, so a mixed fleet is managed from one account
Outbound-only by design: the machine dials out, so nothing waits for an inbound connection
Free to use today, with paid premium features planned for later

Cons

Routes through a hosted relay rather than a direct connection, which some security policies for production Windows Server will not accept
Younger and smaller than WinRM itself, with a shorter track record on enterprise Windows fleets specifically
Still evolving commercially: free today, but future paid features are not yet fully defined

Windows OpenSSH Server + an SSH MCP server

Best if you want SSH-style access instead of WinRM

Microsoft maintains its own OpenSSH Server for Windows, based on the open-source OpenSSH project with Windows-specific adaptations, and as of Windows Server 2025 it ships enabled by default — the first Windows version to do so. On Windows 10, Windows 11 and earlier Server releases it remains an optional Windows feature you add by hand through Settings or PowerShell. Once it is running, the same category of SSH-aware MCP servers used for Linux hosts — for example community projects that read an existing ~/.ssh/config — can drive the Windows box the identical way, which is the appeal for a team that already standardized on SSH-plus-MCP for its Linux fleet and wants one pattern everywhere. The Windows-specific catch worth knowing before you rely on it: a fresh OpenSSH install drops you into cmd.exe, not PowerShell, until you explicitly set the DefaultShell registry value to point at powershell.exe or pwsh.exe — an easy step to miss and a common source of "why isn't this running my PowerShell script" confusion.

Pros

Built into Windows Server 2025 by default — no separate install on the newest server OS
Reuses the same SSH-based MCP servers and workflow already used for Linux hosts
Free and open source, maintained by Microsoft as a first-party Windows component

Cons

Still an optional, manually enabled feature on Windows 10, Windows 11 and pre-2025 Server releases
Default shell is cmd.exe, not PowerShell, unless you manually set the DefaultShell registry value
Same assemble-it-yourself pattern as Linux SSH-plus-MCP — real setup skill required

AWS Systems Manager Run Command

Best for Windows EC2 fleets — zero inbound ports of any kind

AWS Systems Manager Run Command lets you execute PowerShell or shell scripts on Windows and Linux instances with no inbound port open at all — not RDP, not SSH, not WinRM — because the managed SSM Agent, preinstalled on most official Windows Server AMIs, calls out to the Systems Manager service over outbound HTTPS. It is genuinely agentless from the network's point of view and scales to hundreds of Windows instances triggered from one API call. The catch is that Run Command itself is not conversational: you still call it from the AWS CLI, PowerShell module or REST API, so turning it into something an AI agent drives in natural language means fronting it with an AWS-facing MCP layer such as the AWS API MCP Server or the Agent Toolkit for AWS. It is free to use for EC2 instances; on-premises or hybrid Windows machines need the SSM Agent installed and registered through a hybrid activation first.

Pros

Zero inbound ports of any kind — no RDP, SSH or WinRM listener ever exposed to reach the machine
Scales to running the same script across hundreds of Windows instances in one call
Free to use for EC2 instances, with IAM-based access control and logging built in

Cons

AWS-only — a non-EC2 Windows box needs SSM Agent installed and a hybrid activation to participate
Not conversational on its own; an AI agent needs an AWS-facing MCP or API layer in front of it
Requires the SSM Agent to be present and running, which is not guaranteed on every custom Windows image

Azure Run Command (Azure Arc-enabled servers)

Best for hybrid or multicloud Windows fleets managed through Azure

Run command on Azure Arc-enabled servers is Microsoft's answer to the same problem: it is built directly into the Connected Machine agent starting at version 1.33 and lets you remotely execute PowerShell or shell scripts on Windows or Linux machines — on-premises, in VMware, or connected from AWS, GCP or OCI through Arc — without opening RDP or SSH. It is free to use, with billing only for any scripts you choose to store in Azure Blob Storage rather than send inline, and it is triggered through Azure PowerShell, the Azure CLI or the REST API. Like AWS's Run Command, it is currently a preview feature and is not itself conversational — we did not find a dedicated MCP server built specifically for Arc's Run Command (as distinct from the broader, general-purpose Azure MCP Server used for other Azure resource management), so an agent needs to call it through the CLI or REST API directly today.

Pros

Works across hybrid and multicloud Windows fleets connected via Arc, not just Azure-hosted VMs
Free to use; only stored scripts in Blob Storage incur a separate charge
No RDP or SSH port ever needs to be opened to reach the machine

Cons

Still a preview feature, with the noted differences from Azure's VM Run Command carried over
No dedicated MCP server found for Run Command specifically — an agent calls the CLI or REST API directly for now
Requires onboarding each machine to Azure Arc and running the Connected Machine agent first

Tailscale

Solid private mesh — but Tailscale SSH itself skips Windows

Tailscale builds a private WireGuard mesh between your machines, and on Linux or macOS, Tailscale SSH can handle authentication and authorization for SSH connections inside that mesh with no exposed ports and no manual key distribution. On Windows, that specific feature does not extend to the server side: Tailscale SSH's own authentication is not supported when the target machine is Windows, and two open feature requests on Tailscale's GitHub — issue #14942 and issue #17261 — are still asking for it as of this writing. That does not make Tailscale useless for a Windows box; the client runs fine on Windows and the mesh still gets you private network reachability without opening a port to the internet. But you have to pair it with something else — Windows OpenSSH Server or WinRM — to actually authenticate and run commands once traffic reaches the machine, then add an MCP layer on top of that. It is the strongest connectivity layer here for a mixed fleet, provided you know its Windows-specific limit going in.

Pros

Free Personal plan covers up to 6 users with unlimited devices, WireGuard encryption throughout
No open inbound ports — devices reach each other through an outbound mesh
Excellent as the connectivity layer under WinRM or Windows OpenSSH for a fleet or home lab

Cons

Tailscale SSH's server-side auth does not support Windows targets, per two open GitHub feature requests (#14942, #17261)
Not AI-native on its own in any case — still needs WinRM or OpenSSH plus an MCP server on top
A mesh VPN is more concept to learn than a single install-and-go agent

Best Ways to Give an AI Agent Access to a Windows Server in 2026 — comparison
Tool	Best for	Windows support	Setup effort	Price	AI-native?
PowerShell Remoting (WinRM)	Maximum control, zero cost	Native — built into Windows	High (WinRM + MCP wrapper)	Free	Via a young open-source MCP wrapper
AI Commander	Zero-config access in minutes	Native cross-platform installer	Lowest (install + share a code)	Free today; paid features planned	Yes, by design
Windows OpenSSH Server + SSH MCP	Reusing the same pattern as Linux	Default on Server 2025; optional elsewhere	Medium–High	Free (open source)	Via the SSH MCP server you add
AWS Systems Manager Run Command	Windows EC2 fleets, zero ports	AWS or hybrid-activated only	Medium (IAM + SSM Agent)	Free for EC2; hybrid needs activation	Via an AWS-facing MCP/API layer
Azure Run Command (Arc)	Hybrid/multicloud Windows fleets	Cross-platform via Arc onboarding	Medium (Arc onboarding)	Free (stored scripts billed)	No dedicated MCP yet — CLI/REST only
Tailscale	Private mesh to reach a Windows box	Client only — SSH server unsupported on Windows	Medium	Free Personal (6 users)	No (add WinRM/OpenSSH + MCP)

There is no single best way to give an AI agent access to a Windows server. PowerShell Remoting is the strongest option if you want a fully native, zero-cost path and are willing to wire a young open-source MCP wrapper onto it yourself. AI Commander is the fastest route to a working agent with no WinRM or firewall configuration at all, and free to use today. Windows OpenSSH Server suits a team that already runs the SSH-plus-MCP pattern on Linux and wants one workflow everywhere. AWS Systems Manager Run Command and Azure's Run Command on Arc-enabled servers both eliminate inbound ports entirely for fleets already on that cloud, though neither is conversational without an API layer in front of it. Tailscale remains an excellent private mesh — just not, on its own, an SSH server for a Windows target.

Frequently asked questions

Can an AI agent like Claude or ChatGPT actually run PowerShell commands on a Windows Server?

Yes, through a bridge that exposes a shell to the model. On Windows that bridge is usually one of three things: an MCP server that speaks WinRM (Windows' native remote-management protocol), an SSH-based MCP server once Windows OpenSSH Server is enabled, or a dedicated cross-platform agent such as AI Commander that installs directly on the Windows machine. The model never touches the machine directly — it calls the bridge, which runs the command and returns the output.

Does Tailscale SSH work on Windows servers?

Not for the server side. Tailscale runs fine as a client on Windows and gives you private network reachability to the box, but Tailscale SSH's own authentication does not support Windows as the target of an SSH connection. Two feature requests asking Tailscale to add this — GitHub issues #14942 and #17261 — remain open. On Windows, use Tailscale purely as the connectivity layer and pair it with WinRM or Windows OpenSSH Server for the actual command execution.

Do I need to open an RDP or WinRM port to the internet for an AI agent to reach a Windows machine?

No, and you should avoid it. Every option in this report is built to avoid exposing an inbound port to the public internet. AWS Systems Manager Run Command and Azure's Arc Run Command need no inbound port at all — the managed agent dials out. AI Commander's agent also connects outbound only. Tailscale and a WinRM or SSH listener kept inside a private mesh are the way to use those protocols without a public-facing port.

Does Windows ship with SSH built in?

Partially, and it depends on the version. Windows Server 2025 is the first release to ship OpenSSH Server enabled by default. On Windows 10, Windows 11 and earlier Server releases, OpenSSH Server is available as an optional feature that you add manually through Settings or PowerShell — it is not on by default.

What is the cheapest way to give an AI agent access to a Windows machine?

PowerShell Remoting (WinRM) paired with an open-source MCP server costs nothing but your setup time, since WinRM ships with Windows already. AI Commander is also free to use today, with paid premium features planned for later, and needs far less setup — no WinRM listener or firewall rule to configure. For a non-technical user, AI Commander is the cheapest path that works without hiring help; for a Windows admin comfortable with PowerShell Remoting, the native WinRM route costs nothing but time.

Which option needs the least Windows administration experience?

AI Commander, by a wide margin. It installs the same way across Windows, macOS and Linux, connects outbound only, and needs no WinRM listener, firewall rule or registry change. Every other option here — WinRM, Windows OpenSSH Server, AWS Systems Manager or Azure Arc's Run Command — assumes some familiarity with Windows administration, IAM roles or cloud console configuration.

Can I run commands on a Windows machine that is not on AWS or Azure?

Yes. PowerShell Remoting (WinRM), Windows OpenSSH Server plus an SSH MCP server, AI Commander and Tailscale all work on any Windows machine you control, regardless of cloud provider — a home PC, an on-prem server or a VM anywhere. AWS Systems Manager Run Command requires the SSM Agent and works with on-premises machines through a hybrid activation; Azure's Run Command works with non-Azure machines too, once they are onboarded to Azure Arc.

How we evaluated

We evaluated each option specifically for Windows rather than assuming Linux conventions carry over: whether the protocol is native to Windows or bolted on, whether an inbound port has to be exposed to reach the machine, how much genuine Windows administration skill the setup demands, whether an actual AI interface (MCP, REST or an equivalent) exists today or still has to be built by the reader, and cost. Where a tool's Windows behavior differs meaningfully from its Linux behavior — Tailscale SSH's unsupported Windows target, Windows OpenSSH Server's default cmd.exe shell, Windows Server 2025's default-on OpenSSH — we verified the claim against the vendor's own documentation or an open GitHub issue rather than repeating a generic cross-platform description. Pricing and feature details are mid-2026 snapshots and change frequently; re-confirm before committing production infrastructure.

Native fit: whether the protocol is Windows-native (WinRM, OpenSSH-for-Windows) or a general tool retrofitted to it
Network exposure: whether any inbound port must be opened to reach the Windows machine
AI interface: a working MCP/REST bridge available today versus one the reader has to assemble
Setup effort and cost, verified against vendor documentation or primary GitHub sources rather than generic claims

Innvesti may have commercial relationships with some companies mentioned. Our analysis is editorially independent. Figures cited are sourced; where reliable data is unavailable we say so rather than estimate.

Key takeaways

WinRM and SSH are not the same protocol, and Windows treats them differently

The connectivity layer doesn’t always follow you to Windows either

Cloud-native options remove the port question entirely — for machines on that cloud

Who each option actually fits

Where this is heading

PowerShell Remoting (WinRM)

Pros

Cons

AI Commander

Pros

Cons

Windows OpenSSH Server + an SSH MCP server

Pros

Cons

AWS Systems Manager Run Command

Pros

Cons

Azure Run Command (Azure Arc-enabled servers)

Pros

Cons

Tailscale

Pros

Cons

Frequently asked questions

How we evaluated

Sources