PowerShell.MCP.Proxy.exe is unsigned — blocked by Windows Defender Application Control (WDAC/Device Guard)

[rblinton]

Summary

PowerShell.MCP.Proxy.exe (v1.7.6, win-x64) is not code-signed, which causes it to be blocked on machines with Windows Defender Application Control (WDAC) / Device Guard policies enabled.

Error

'C:\Users\<user>\Documents\PowerShell\Modules\PowerShell.MCP\1.7.6\bin\win-x64\PowerShell.MCP.Proxy.exe' was blocked by your organization's Device Guard policy.
Contact your support person for more info.

Details

• Get-AuthenticodeSignature reports NotSigned for the proxy executable.
• Many organizations enforce WDAC policies that block unsigned executables.
• This prevents the MCP server from starting entirely — there is no managed-only fallback.

Environment

• OS: Windows 11
• PowerShell: 7.6.0
• PowerShell.MCP: 1.7.6
• MCP Client: Warp terminal

Request

Please Authenticode-sign PowerShell.MCP.Proxy.exe (and ideally all platform-specific binaries) with a valid code-signing certificate. This would allow the proxy to pass WDAC policies on enterprise-managed machines without requiring per-hash or per-path exceptions from IT.

As a workaround users currently need to request IT to whitelist the binary by SHA-256 hash, which breaks on every module update.

[yotsuda]

Thanks for the detailed report! Tracking this for the next release.

Plan for v1.7.7:

PowerShell.MCP.dll and PowerShell.MCP.Proxy.exe (win-x64) will be
Authenticode-signed with a self-signed code-signing certificate. The public
key is published in a dedicated repository:

→ https://github.com/yotsuda/code-signing

The same certificate signs binaries across all yotsuda OSS projects
(PowerShell.MCP, ripple, etc.), so trusting it once covers future
releases of all of them too. Only the public certificate is published.

Note on other platforms: Authenticode signing is Windows-specific.
macOS uses a different model (Apple-issued Developer ID + Gatekeeper,
with annual subscription costs not planned for this OSS project), and
Linux has no system-level signature enforcement comparable to WDAC. The
signing change is therefore scoped to Windows binaries only.

Why self-signed instead of a CA-issued cert: a CA-issued cert costs
several hundred USD/year for an OSS project. WDAC environments that accept
publisher rules will work the same way with a self-signed cert as with a
CA-issued one — your IT just needs to trust the cert once, after which
every future release passes WDAC without per-version hash exceptions.

Quick check first (1 minute, no IT involvement):

Some environments report "WDAC" but actually run it in Audit mode, in
which case adding the cert to your own machine's Trusted Publisher store
is enough. Worth trying before going through IT:

# Run as Administrator
Import-Certificate `
    -FilePath yotsuda.cer `
    -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

If WDAC is in Enforce mode (which sounds like your case based on the
hash-whitelist requirement), this won't help — WDAC ignores per-machine
trust stores and only honors signers listed in the policy XML itself.
That's by design: WDAC is meant to be tamper-resistant from the user side.
In that case you'll need IT to update the policy as below.

For your IT team (replacing the current per-hash whitelist):

# Add a User-mode signer rule to your existing WDAC policy XML, derived
# directly from the .cer
Add-SignerRule `
    -FilePath YourExistingPolicy.xml `
    -CertificatePath yotsuda.cer `
    -User

# Convert the updated policy XML to the binary form WDAC enforces
ConvertFrom-CIPolicy `
    -XmlFilePath YourExistingPolicy.xml `
    -BinaryFilePath SiPolicy.p7b
# Then deploy SiPolicy.p7b via your usual mechanism (GPO / Intune / etc.)

After this one-time setup, future PowerShell.MCP updates will not require
re-whitelisting.

One caveat (FYI): if your WDAC policy is configured to reject all
third-party publishers (only Microsoft signatures + explicit hashes
allowed), this won't help — and a paid CA cert wouldn't help either in
that case unless the CA's root is explicitly in your policy's trust list.
If you hit this, please reopen with details.

I'll post the cert thumbprint in the v1.7.7 release notes so you can verify
authenticity.

[yotsuda]

v1.7.7 is out on PSGallery. If WDAC still blocks after trusting the cert, feel free to reopen with your policy mode (Audit/Enforce).