Never run an AI-written PowerShell script without a dry run first

Ask an AI for a script to disable stale accounts, strip licences or move mailboxes and you'll get a tidy one. The danger isn't a syntax error. It's the script doing exactly what you told it, on a lot more accounts than you had in mind.

So put the safety in the request.

Write a PowerShell script that [TASK, e.g. lists users who haven't
signed in for 90 days].
Requirements:
- Read-only by default. Any change sits behind an -Apply switch and
  supports -WhatIf so I can preview it.
- Write a CSV of every object it would touch: the reason, and the current
  value of anything it would change, so I can put it back.
- Log what it did and what it skipped, with timestamps.
- Exclude [BREAK-GLASS ACCOUNTS, SERVICE ACCOUNTS, A NAMED GROUP].
- Stop if it would affect more than [N] objects, and tell me why.
- Use only documented cmdlets, and tell me which modules and versions
  it needs.
Then explain each block in plain English and list what could go wrong.

Then I'd work through it in order:

1. Read it. If you can't explain a line, ask the AI to, or take the line out.
2. Once you've read it and it only reads, run the read-only pass on live and look through the CSV by eye.
3. Run the change on a test group of five.
4. Keep the CSV. It's your record of what happened, and the start of a way back.

Only the start, because a CSV tells you what to restore and doesn't restore anything. A licence you removed can usually be assigned again. A deleted account or mailbox might not come back, so know what's reversible before you run the real thing.

The usual traps: a cmdlet that doesn't exist (the model made it up), a module that's been retired, and a filter that catches more than you meant. The "stop above N" line is there for the last one.

Don't paste real credentials, tenant IDs or user lists into the prompt. Placeholders.