On a Windows server, running a .ps1 file fails with "running scripts is disabled on this system". What is PowerShell's execution policy doing, and why is it not treated as a security boundary?

## What the error actually means The message — "File C:\...\deploy.ps1 cannot be loaded because running scripts is disabled on this system" — comes from PowerShell itself, before any of your code runs. It is not an NTFS permission problem, not User Account Control, and not antivirus. PowerShell checked its **execution policy** and declined to load the script *file*. Note the word *file*. Execution policy applies to loading `.ps1` files, module files and configuration files. It says nothing about commands typed or pasted into an interactive session: those run regardless of policy. That asymmetry is the first hint about what it is really for. ## The policy values - **Restricted** — no script files load. The default on Windows client editions. - **AllSigned** — every script file must carry a valid Authenticode signature from a publisher you trust, including scripts you wrote yourself. - **RemoteSigned** — locally created files run unsigned; files that arrived from elsewhere must be signed. The default on Windows Server editions. - **Unrestricted** — everything runs; files from another machine produce a warning prompt. - **Bypass** — everything runs, nothing is blocked and nothing warns. - **Undefined** — no policy set in this scope, so the next scope decides. "From elsewhere" is not magic: when a browser or mail client saves a file, it tags it with a zone marker (the mark of the web). `RemoteSigned` reads that tag. Clearing it with `Unblock-File` makes the same bytes count as local — which tells you how much weight the distinction can carry. ## Scopes and precedence The effective policy is resolved across five scopes, highest precedence first: **MachinePolicy**, **UserPolicy** (both set by Group Policy), **Process**, **CurrentUser**, **LocalMachine**. ```powershell Get-ExecutionPolicy -List Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass ``` The Process scope lives only in the current PowerShell process and its environment, so it evaporates when the window closes. That makes it the right scope for a one-off — and, not coincidentally, the reason the setting cannot restrain anybody. Group Policy is the only scope an administrator can actually pin: a policy-set value outranks whatever a user chooses for themselves, and `Set-ExecutionPolicy` will report that it could not take effect. ## Why it is not a security boundary Microsoft documents it as a safety feature, and the reasoning is straightforward: **everything it blocks is available by another route to the same user, at the same privilege level.** All of these are ordinary, non-elevated actions: ```powershell powershell.exe -ExecutionPolicy Bypass -File .\deploy.ps1 Get-Content .\deploy.ps1 | powershell.exe -Command - Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass ``` And beyond the shell, a program can host the PowerShell engine through its .NET API and never consult the policy at all. A control that the attacker can turn off, from the same account, without asking anyone, is not a control — it is a speed bump against the honest mistake of double-clicking something from an email. That framing is the point of the interview question. Candidates who answer "we set AllSigned, so untrusted scripts can't run here" have made a security claim their configuration does not support, and that is the misconception being probed. ## What does enforce script policy If the requirement is genuinely "unapproved code must not execute on this server," the answer is application control, not execution policy: - **AppLocker** or **Windows Defender Application Control (WDAC)** define which executables and scripts may run, enforced by the system rather than by the shell's own preference. - Under those policies PowerShell drops untrusted code into **constrained language mode**, which removes the ability to call arbitrary .NET types and Win32 APIs — the very techniques a bypass relies on. You can read the current mode from `$ExecutionContext.SessionState.LanguageMode`. - **Script block logging** (Group Policy) records what was executed to the `Microsoft-Windows-PowerShell/Operational` event log, so even permitted code is attributable. - Signing scripts with an internal code-signing certificate still has value under those regimes — it is what lets application control identify code as approved, rather than being the enforcement itself. ## Answering the original symptom Operationally, the fix depends on the fleet's policy. On your own workstation, `Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned` is the usual setting. In an automation context — a scheduled task, a build agent — invoke the interpreter with `-ExecutionPolicy Bypass` explicitly rather than loosening the machine's setting, so the exception is visible in the job definition instead of silently applying to everything on the box. If Group Policy pinned the value, none of that helps and the correct move is to get the script signed or approved by the process the organisation already runs.