BXUP Track progress & test yourself — free
IT Support / Service Desk / Sysadmin · Playbook · Core · ~4 min read
IT SUPPORT / SERVICE DESK / SYSADMIN · PLAYBOOK · CORE

Generate Scripts with the Mandatory Safety Review

AI writes working PowerShell in seconds — including working PowerShell that runs as admin, swallows errors, and deletes the wrong thing at scale. The skill this playbook teaches is not prompting for scripts; it is the fixed five-point safety review that every generated script passes before it touches a real machine.

Tier: Core · Workflow area: Scripting & automation · ~35 minutes

This playbook establishes the generation-plus-review protocol for admin scripting with Claude, Copilot or Gemini: a prompt pattern that requests safety features up front, then the mandatory review — -WhatIf support, least privilege, error paths, secrets handling, PSScriptAnalyzer — applied every time, with no seniority exemption.

When to use

  • Any generated script that changes statecreates, modifies, deletes, or reconfigures anything on endpoints, servers, AD/Entra, M365 or network gear.
  • Read-only scripts headed for scheduled executiona broken report script that silently returns nothing misleads for months; it gets the review too.
  • Scripts a colleague or the internet "already tested." Provenance is not review; inherited scripts get the same five points (and pb-22's deeper treatment if they are large and unexplained).

When NOT to use

  • Interactive one-liners you fully understandGet-ADUser jsmith -Properties LockedOut needs no protocol. The line is state change and scale, not script length.
  • As a substitute for change managementa reviewed script that modifies production still goes through the change process (pb-36); the review is a quality gate, not an authorization.
  • When you cannot read the language at allthe review requires comprehension. If you cannot follow the script's logic even with AI explanation, you cannot own its execution; learn first or hand it to someone who can.

The recipe

  1. Prompt for safety features, not just function. The generation prompt bakes in the requirements so the review starts from a defensible draft:

    Write a PowerShell script: disable AD user accounts inactive for 90+
    days, from OU "OU=Staff,DC=corp,DC=local", excluding accounts in the
    group "ServiceAccounts".
    
    Requirements — non-negotiable:
    - [CmdletBinding(SupportsShouldProcess)] and honor -WhatIf/-Confirm
      on every state change
    - Parameters with validation, no hardcoded values
    - Try/catch on every AD call; on error: log and continue, never
      silently skip; summary of failures at the end
    - No plaintext credentials anywhere; assume the runtime identity
    - Before changing anything, export the affected accounts (name,
      DN, lastLogonTimestamp) to a timestamped CSV — the rollback record
    - Log every action taken to a transcript file
    Then list: what could go wrong running this, and what permissions
    it minimally needs.
    

    That final question is a review head start — the model is decent at criticizing its own script when asked explicitly.

  2. Review point 1 — dry run honestly supported. Confirm SupportsShouldProcess is declared and every state-changing call actually respects it (if ($PSCmdlet.ShouldProcess(...)) or the cmdlet's native -WhatIf passthrough). A script that declares it but bypasses it in an inner function is the classic generated bug.

  3. Review point 2 — least privilege. Ask: what is the minimum identity this needs? Generated scripts assume Domain Admin by default silence. Run it as a delegated service account scoped to the OU or Graph scope in question; if the script fails under least privilege, fix the scoping, not the privilege.

  4. Review point 3 — error paths. Read every catch block. The generated failure modes to hunt: empty catch (error vanishes), catch { continue } without logging, and a pipeline where one failed item kills the whole run. Force a failure to test it — point the script at one nonexistent object and watch what it does.

  5. Review point 4 — secrets. Grep for password/key/token literals, connection strings, and ConvertTo-SecureString ... -AsPlainText. Anything found moves to the platform's secret store (SecretManagement module, Azure Key Vault, RMM credential store) or dies.

  6. Review point 5 — run PSScriptAnalyzer. Mechanical and non-negotiable:

    Install-Module PSScriptAnalyzer -Scope CurrentUser
    Invoke-ScriptAnalyzer -Path .\Disable-StaleAccounts.ps1 -Severity Warning,Error
    

    Typical catch on generated code:

    RuleName                            Severity  Line  Message
    PSAvoidUsingPlainTextForPassword    Warning   34    Parameter '$Password' should use SecureString
    PSUseShouldProcessForStateChanging  Warning   61    Function calls Set-ADUser without ShouldProcess
    

    Errors block; warnings are resolved or explicitly waived in a comment with a reason.

  7. Execute in stages, keep the artifacts. -WhatIf first and read the full output — the WhatIf list is your blast-radius preview. Then limited live run (-First 5 or a pilot OU), verify in the console, then full run. File the WhatIf output, the pre-change CSV and the transcript with the change record.

Make it yours

  • Copilot-in-VS-Code shopgeneration and iteration happen in the editor; keep the review checklist as a repo PULL_REQUEST_TEMPLATE so scripts merged to the team library carry evidence of all five points.
  • Bash/Linux estatesame protocol, different tools: a --dry-run flag you implement, ShellCheck instead of PSScriptAnalyzer, set -euo pipefail as the error-path baseline, and secrets via your vault, never in the script.
  • RMM script libraryscripts destined for the RMM (pb-26) get reviewed before upload, and the RMM's own variable/credential store replaces every embedded value.

Quality check

  • The five points are a written checklist, signed per script. Not a vibe — a row in the script header or the team's script register: WhatIf ✓, least-priv ✓, errors ✓, secrets ✓, PSSA ✓, reviewer initials.
  • WhatIf output actually read. The step everyone skips; the count and names in the WhatIf run must match your expectation before live execution.
  • Rollback record exists before change. The pre-change export is written and opened — an empty CSV means the filter is wrong, and that discovery must happen before the change.
  • Second pair of eyes for high-blast-radius. Anything touching more than ~50 objects, or any identity/security system, gets a colleague's review — the same gate pb-15 uses for knowledge, applied to code.
Warning

Never paste real credentials, tenant IDs or production hostnames into a public assistant while iterating on a script — use placeholders, and populate real values only in your editor from the secret store.

Key Takeaway:

Generation is the easy 10%; the fixed five-point review — dry run, least privilege, error paths, secrets, analyzer — is what makes AI scripting an asset, and it applies to every script, every time, regardless of who or what wrote it.

This is the free reading view. Open BXUP to track your progress, run the hands-on labs, and prove it with original, exam-pattern assessments.
© Anvi Innovate · BXUP — Be Exponentially Upskilled · BXUP is an independent learning platform, not affiliated with or endorsed by AWS, Microsoft, Google, NVIDIA, IBM, Salesforce, Databricks, Oracle or Anthropic. All trademarks belong to their respective owners. · bxup.in