How to Scan AI-Generated PowerShell Scripts with PSScriptAnalyzer Before Running Them

PSScriptAnalyzer helps with the first pass. It checks PowerShell code against a collection of rules and reports potential problems without running the script being analyzed. It can flag risky patterns and common mistakes, but it cannot certify that a script is safe or that it does what you intended.

Here’s how to install it, scan a script and make sense of the results before you consider running code from an AI assistant—or any other source.

Before you begin​

You’ll need:

• Windows PowerShell 5.1, or a supported PowerShell 7 installation. Microsoft currently lists PowerShell 7.2.11 or later for PSScriptAnalyzer.
• Access to a trusted module repository, such as the PowerShell Gallery, or an approved internal repository.
• A .ps1 file containing the script you want to review.

Microsoft describes PSScriptAnalyzer as a static code checker that applies PowerShell best-practice rules and returns diagnostic results. This guide uses its built-in rules, not third-party analyzer rules.

Open a non-administrator PowerShell window for the review. You do not need to give the script administrator privileges merely to inspect it.

1. Install PSScriptAnalyzer​

First, check your PowerShell version and whether the module is already available:

$PSVersionTable.PSVersion
Get-Module -ListAvailable -Name PSScriptAnalyzer

If you need to install it and your organization permits installation from the PowerShell Gallery, run:

Install-Module -Name PSScriptAnalyzer -Repository PSGallery -Scope CurrentUser

The CurrentUser scope avoids a machine-wide installation and normally does not require elevation. You may be prompted to install the NuGet provider or confirm that you trust the repository. Read those prompts and follow your organization’s policy rather than accepting them blindly.

Next, load the module and confirm the analyzer command is available:

Import-Module PSScriptAnalyzer
Get-Command Invoke-ScriptAnalyzer

A successful Get-Command result identifies the command and its source module. If your organization uses an internal repository, ask your administrator for the approved installation method instead of changing repository settings yourself.

2. Save the script without running it​

Paste the code you want to review into a text editor and save it as a PowerShell script—for example:

C:\Scripts\Review-Me.ps1

Use your actual file location in the commands below. Saving the text as a .ps1 file does not require executing it. Don’t paste the generated commands directly into the PowerShell prompt: that’s less like reviewing the instructions and more like pressing the launch button.

Before scanning, read the script in the editor. Pay particular attention to file paths, network addresses, downloaded content, credential handling and commands that change system settings.

3. Run the analysis​

Point the analyzer at the saved file:

Invoke-ScriptAnalyzer -Path 'C:\Scripts\Review-Me.ps1'

PSScriptAnalyzer returns diagnostic records for rule violations. To make longer messages easier to read, use:

Invoke-ScriptAnalyzer -Path 'C:\Scripts\Review-Me.ps1' |
 Format-List RuleName, Severity, ScriptName, Line, Message

Look for the rule name, severity, line number and message. Open the file at the reported line and examine the surrounding code as well; one line rarely tells the whole story.

If the command completes without diagnostics or errors, the analyzer did not report a violation under the rules used. That is not a safety guarantee. If you see an error about the path or the analyzer itself, resolve it and run the scan again—an unsuccessful scan is not a clean scan.

4. Interpret what the findings mean​

Not every diagnostic represents the same kind of problem:

• ParseError indicates a problem parsing the PowerShell code. Correct it before expecting the script to run as written.
• Error indicates a rule classified as an error. Read the message carefully; some security-related rules use this severity.
• Warning identifies a potential problem or practice worth reviewing.
• Information can flag a recommendation rather than an immediate failure.

Severity helps you prioritize, but it is not a complete risk score. A script can have no warnings and still delete the wrong folder perfectly.

For example, Microsoft’s PSAvoidUsingInvokeExpression rule warns about Invoke-Expression, which executes a string as PowerShell code. If untrusted input becomes part of that string, it can create a code-injection risk. Often the better answer is to call the intended command directly rather than build a command string.

To learn more about a finding, inspect the corresponding rule:

Get-ScriptAnalyzerRule -Name PSAvoidUsingInvokeExpression |
 Format-List *

Replace the example rule name with the one in your diagnostic. Then review the code and decide whether to change it. Don’t suppress a warning simply to make the output quiet.

A useful extra check: scripts can contain rule suppressions. To see reported suppressions, run:

Invoke-ScriptAnalyzer -Path 'C:\Scripts\Review-Me.ps1' -SuppressedOnly

Investigate any suppression and its justification, particularly in code from an unfamiliar source. Microsoft documents -SuppressedOnly as a way to report suppressed rule violations.

5. Review the behavior the analyzer cannot prove​

Static analysis is a guardrail, not a crystal ball. PSScriptAnalyzer cannot establish that a script matches your request, that a remote server is trustworthy, or that a command will be harmless in your particular environment.

Before any test, review:

1. The target. Are the paths, accounts, computers and other inputs exactly the ones you intend?
2. The effects. Does the script delete, overwrite, download, upload, disable or modify anything? Are those actions necessary?
3. The dependencies. Does it call another script, import a module or retrieve code over the network? Review those components separately.
4. The credentials and permissions. Does it request secrets or administrative access? Avoid supplying either unless you understand why they are needed.
5. The recovery plan. If the script changes data or settings, do you have an appropriate backup and a way to undo the change?

After editing the script, save it and scan it again. If the code changes after review, the old result no longer describes the exact file you may run.

Where practical, test only after review, using a disposable environment and non-sensitive data. A command’s -WhatIf option can help preview supported operations, but don’t assume every command in a script supports it or that it makes the entire script safe.

If something goes wrong​

• “The term Install-Module is not recognized.” Check that you’re using a supported PowerShell installation and that PowerShellGet is available. On a managed PC, use your organization’s approved software source.
• Repository or download errors. Check connectivity and whether the repository is registered and approved. Corporate network controls may require administrator assistance.
• “The term Invoke-ScriptAnalyzer is not recognized.” Run Get-Module -ListAvailable -Name PSScriptAnalyzer, then try Import-Module PSScriptAnalyzer in the same PowerShell edition where it was installed.
• Path not found. Confirm the file exists and replace the example path with its actual location. Keep the path in quotes if it contains spaces.
• Execution policy blocks module loading. Check Get-ExecutionPolicy -List and consult your administrator. Don’t bypass an organizational policy just to complete the scan.

Finally, avoid adding -Fix to an unfamiliar file as your first move. Microsoft notes that it can modify files and recommends having a backup. Review first, make deliberate changes, and scan again.

The goal is not to win a contest for the quietest analyzer output. It is to understand what the script will do before Windows finds out the hard way.