Review AI-Generated PowerShell with PSRafScan

Direct answer

1. Preserve the original

Keep the complete response unchanged with the original prompt, provider or model, date, and allowed context. Create a separate candidate file containing only executable PowerShell. Markdown fences and surrounding prose are not script lines.

2. Define a review contract

• State the task independently of the generated code.
• List allowed inputs and expected outputs.
• Name allowed side effects and explicitly forbidden effects.
• Identify required privileges, modules, credentials, paths, and network endpoints.
• Write observable success and failure conditions.

3. Choose context and scan

Read parser findings first and the full report second. Do not ask a model to declare its own output safe based on one process result.

$scan = @{
    Path = './candidate.ps1'
    IntendedUse = 'Ps1File'
    FailOn = 'Warning'
    OutputFormat = 'Json'
    OutputPath = './candidate.psrafscan.json'
    NonInteractive = $true
}
Invoke-PSRafScan @scan

4. Request a bounded revision

Share the least information needed: rule name, severity, direct issue and fix guidance, required behavior, constraints, and the smallest redacted excerpt. Do not automatically send the complete script, report, local path, credentials, host names, customer data, or unrelated code to an external service.

5. Review the diff

• Confirm every changed line serves the stated task.
• Reject new commands, dependencies, privileges, network access, broader paths, or side effects unless separately approved.
• Preserve the original and save the accepted candidate as a new file or version.
• Start a separate review for any scope expansion.

6. Rescan and stop when uncertainty remains

Repeat the same intended use and threshold. Confirm no parser error was introduced, the targeted finding changed as expected, all other findings were reviewed, and the final diff still matches the contract.

• Stop for unexplained Error or Warning findings.
• Stop when purpose, inputs, outputs, privileges, or effects change.
• Stop when a dependency or command cannot be identified from authoritative documentation.
• Stop when a sufficiently isolated runtime test cannot be defined.

7. Keep runtime testing separate

Static acceptance can support a decision to test. It cannot establish real-data correctness, permission behavior, environmental compatibility, safe side effects, or complete rule coverage. A controlled test needs known inputs, a disposable environment where possible, minimal privilege, expected output, cleanup, and an explicit human decision.