§1 · Premise
PowerShell automates the machine by doing, not describing
A script you cannot read is a command you did not give.
PowerShell automates the machine by doing, not by describing — which makes generated PowerShell more dangerous than generated prose and, in one specific way, more dangerous than generated Terraform: Terraform shows you a plan and waits; a pasted PowerShell line executes the instant you press Enter. AI writes PowerShell that is faster to run than to read. It hallucinates cmdlets that do not exist, sets destructive verbs against object sets larger than you predicted, assumes a system state that is not true, and inlines credentials it should never touch.
And because PowerShell is the most common administration tool and the most common post-exploitation tool on Windows, your AI-generated automation is structurally hard to distinguish from an attacker's tradecraft. The triad keeps you in control: the Apprentice:Mentor lens keeps your model of what the script touches intact, the Defense lens treats every generated line as your own command before it runs, and the Offense lens hunts the unattended automation and drift before it fails loudly. You install them in a fixed order, because the order is load-bearing.
§2 · Falsification bet
The bet we are willing to lose
The trust layer of this workshop is not a testimonial — it is a falsifiable claim with a horizon and a check. If it fails, bring the transcript log that proves it.
Position The triad keeps you in control of what your scripts actually do Horizon Two quarters from install Checkable Prediction accuracy, destructive/inlined-secret rate in generated automation, and captured reasons for scheduled remediation, measured
If a team installs all three lenses over its PowerShell practice — a withholding config on its assistant, `-WhatIf`-first discipline, a defense stack that catches destructive and hallucinated code before it runs, and a ritual that governs unattended automation through decision records — and after two quarters its admins are no better at predicting what a script touches, its generated automation still ships destructive one-liners and inlined secrets, and not one scheduled remediation carries a captured reason, then the triad added ceremony and I was wrong. Bring the transcript log that proves it.
OPEN · CHECKABLE Prediction accuracy, destructive/inlined-secret rate in generated automation, and captured reasons for scheduled remediation, measured
§3 · The three lenses
Three lenses, installed in a fixed order
In PowerShell each lens has a flag, a pipeline, and a thing that breaks: `-WhatIf` is predict-and-trace built into the verb, the object pipeline is the comprehension test, the machine is the blast radius, and PSGallery is a documented supply-chain target. You install them in sequence because the order is load-bearing.
- 01
Apprentice
Predict the object set and the modified state before you run; `-WhatIf` first, always.
Operates on Your model of what the script touches; the deskilling effect of pasting and running generated scripts unread. - 02
Defense
Your generated script is your command. “The AI wrote it” is not an incident finding.
Operates on Destructive verbs, hallucinated cmdlets, inlined secrets, slopsquatted modules — every line before it executes. - 03
Offense
The dangerous script is the one you are not watching; drift you cannot explain is debt you cannot price.
Operates on Scheduled tasks, runbooks, self-remediating jobs; surfacing drift; governing automation that runs without you.
Load-bearing rule Apprentice:Mentor → Defense → Offense, never reversed. Install Defense and Offense before you can read what a script touches and you sign and log and schedule automation you do not understand — controls wrapped around commands nobody can predict. Install the how of reading a script before the what you defend and the where you hunt. If time is short, modules are shortened, not resequenced.
§4 · Who gets what
Where the value lands by archetype
One core program, but its center of gravity shifts with where you operate. Pick your stance to see the emphasis and the recommended tier.
Supporter L1–L2
Builder L3
Orchestrator EM / Director
Architect Principal
Strategist CISO / CTO / VP
§5 · Curriculum
Three modules, then the capstone
Each module is one lens: an objective, the core move, a build exercise you do paper-first in a disposable sandbox, and a checkpoint that names the failure mode. Predict-and-trace is `-WhatIf` — predict the actions by hand, run the dry run, trace the divergence.
Objective
Install the read-before-run reflex and the `-WhatIf`-first habit, with a withholding config that defaults your assistant to coaching, so you never run a script whose object set and modified state you cannot predict.
Core move
Configure the assistant to refuse a finished script for anything that changes state and instead ask the senior questions — which objects, could the filter match more than expected, is the verb reversible, what state does it assume, what runs elevated, what does it touch that you did not name. Predict the object set and modified state by hand, then run with `-WhatIf` and trace. Three reading habits: `Get-Command`/`Get-Module`, `Get-Help -Full`, `Get-Member`.
Exercise
Predict a supplied script's object set and destructive line cold (a disk-cleanup pipeline plus a bulk account-property change from CSV), then dry-run with `-WhatIf` and trace. Write your withholding config: senior questions by default, forbid destructive verbs and bulk identity operations as finished code, require `-WhatIf`/`ShouldProcess` in any state-changing function, re-state safety constraints each session.
Checkpoint
If you could not name the destructive line in the cold read, the diagnostic is working. If your config does not require `ShouldProcess` in generated functions, it has no teeth where it matters most.
Objective
Install the gate that proves generated PowerShell safe before it runs, scored against a fixed taxonomy — and dismantle the most common false sense of security in the language.
Core move
When a generated script removes the wrong directory tree, resets the wrong accounts, or sends a credential to a transcript, the action is yours. The myth that has to die: execution policy is not a security boundary — it is a convenience control against accidental runs, bypassed trivially. The real controls hold: code signing with `AllSigned`, Constrained Language Mode, WDAC/AppLocker, AMSI + script-block logging + transcription, least privilege, JEA. And the living-off-the-land answer is attribution: make legitimate automation signed, logged, and run from known accounts so what is yours is provable.
Exercise
Harden one generated script (a scheduled cleanup that removes files, restarts a service, and reports by email with a stored credential) through the gate: which failure modes are present, the destructive action and its `-WhatIf` output, where the credential lives and its SecretManagement fix, any unverified `Install-Module` name, the execution-policy myth check, and the objects-modified-plus-largest-blast-radius paragraph.
Checkpoint
If your script's safety story is “we set RemoteSigned,” you have no defense — name the real control. If a destructive verb has no `-WhatIf` evidence, it does not pass.
Objective
Arm your automation rituals so each surfaces drift — between what a script should do and what it does, and between generated code and team understanding — and design the gate that governs unattended and self-remediating automation.
Core move
The dangerous PowerShell is the script you are not watching: the scheduled task, the runbook, the service-restart monitor. The autonomous-remediation trap: a self-healing script reverts an on-call engineer's deliberate emergency change because it cannot tell intentional deviation from drift. The fix is the decision record — the remediation checks open ODRs before it acts, and emits an AgODR per action (provenance, human checkpoint sized to blast radius, rollback, REVIEW); destructive or fleet-wide remediation runs `-WhatIf` first and blocks on approval.
Exercise
Arm one automation ritual with a single offensive move and test it (surfaces drift specifically? gameable? adds a meeting or modifies one?). Then design the self-remediation gate: what it reads before acting, the AgODR fields it emits, and the blast-radius tiers for autonomous vs. dry-run-and-block.
Checkpoint
If your remediation gate has no “check open ODRs first” step, you built the automation that reverts the emergency change. If it blocks a human on every action, your on-call will rubber-stamp — tier it by blast radius.
Brief
Design the 60-day install of all three lenses over a real (or supplied) PowerShell estate, then defend it before a panel in the CTRL ALT PRESS voice.
Scenario
A mid-sized Windows shop runs daily helpdesk one-liners, a dozen scheduled tasks, and a few Azure Automation runbooks. Admins increasingly paste AI-generated scripts; review is a glance. A generated cleanup recently removed more than intended in a sandbox, and a self-remediating service-restart job reverted a deliberate maintenance change. The team believes `RemoteSigned` keeps them safe. 60 days, no new headcount, you may not stop the team using AI.
Must contain
- The withholding config (Apprentice) and the predict-`-WhatIf`-trace drill, with the verb classes it forbids generating.
- The defense stack (Defense): PSScriptAnalyzer + Pester, signing/CLM/WDAC, script-block logging + transcription, SecretManagement, PSGallery allow-listing — and the explicit retirement of execution policy as a believed control.
- The offensive rituals (Offense) and the self-remediation gate that reads ODRs and emits AgODRs.
- Your answer to the living-off-the-land question: how legitimate automation is made attributable.
- The 60-day behavioral markers, with “the AI wrote it” and “execution policy protects us” both banned.
Pass line
Pass ≥ 18/30; distinction ≥ 24 with no dimension below 3.
You will leave able to
- Predict the object set and modified state of a script before running it, use `-WhatIf` as a standing predict-and-trace habit, and configure an assistant to withhold the script and coach instead.
- Detect the high-frequency failure modes of generated PowerShell — hallucinated cmdlets/parameters/modules, false state assumptions, destructive verbs, inlined secrets — and run a blast-radius review gate.
- Build a defense stack (PSScriptAnalyzer, Pester, signing, Constrained Language Mode, script-block logging, SecretManagement) and explain why execution policy is not part of it.
- Govern unattended automation with one offensive ritual and an AgODR gate that reads ODRs before it remediates.
- Defend the install against an adversarial panel, including how you tell your own AI automation apart from an attack.
§6 · Failure taxonomy
The failure modes of generated PowerShell
A working taxonomy to score against. In PowerShell a flaw is not a latent bug — it is an action that already executed.
| Failure mode | Counter |
|---|---|
| Hallucinated cmdlets / parameters / modules — code referencing commands or parameters that do not exist in the session. | `Get-Command` / `Get-Help` verification before first run. |
| False state assumptions — paths, keys, accounts, or services the script assumes exist. | `Test-Path` and existence checks; predict the state. |
| Destructive verbs without brakes — `Remove-*`, `Set-*`, `Disable-*`, bulk identity changes with no `ShouldProcess` or `-WhatIf`. | The dry-run discipline and the blast-radius gate. |
| Secret exposure — credentials inlined, `-AsPlainText -Force`, or written to transcripts/logs. | SecretManagement / SecretStore; never inline; treat transcripts as sensitive. |
| Supply-chain / slopsquatting — `Install-Module` against a hallucinated or typosquatted name. | Verify the Owner, pin `-RequiredVersion`, allow-list sources. |
§7 · Evidence floor
The research this stands on
No testimonials, no countdown timers. Claims carry provenance; vendor and unverified figures are labeled.
- 01
Execution policy is not a security boundary — it is a convenience control against accidental runs, bypassed trivially.
- 02
`-WhatIf`/`-Confirm`/`ShouldProcess`, the object pipeline, PSScriptAnalyzer, Pester, signing, CLM, JEA, SecretManagement, and logging are established, stable controls.
- 03
PSGallery is a documented typosquatting/spoofing target: the unverified Author field shows by default while the trustworthy Owner is hidden; rogue modules can run code at install.
- 04
AI generates offensive PowerShell as readily as automation; living-off-the-land technique makes legitimate automation hard to distinguish from an attack.
- 05
Over 40% of AI-generated code carries security flaws; package hallucination runs ~5–20%.
- 06
No partition between an LLM's output and the organization that deploys it; the chatbot is not a separate legal entity.
- 07
PowerShell 7.6.2 LTS (.NET 10) is current; Windows PowerShell 5.1 remains an OS component; PSResourceGet is the modern install path.
§8 · Enroll
Choose your delivery tier
Three modalities, same curriculum, all run in a disposable sandbox VM. Efficacy rises with the live BUILD/BREAK drills on destructive runs — the in-person intensive runs against instructor-seeded breakage and a remediation bot.
| Modality | Format | Efficacy | Positioning |
|---|---|---|---|
| Self-paced | 8 modules, sandbox lab, `-WhatIf` drills, template pack | Lowest — no live BUILD/BREAK on destructive runs | Entry tier; justified by the sandbox lab and lifetime updates |
| Virtual cohort | 8 weekly live sessions, paper-first prediction drills, shared sandbox, async capstone | High — accountability + witnessed cold reads | Premium; the cap preserves drill integrity |
| In-person intensive | 2 days, live runs against instructor-seeded breakage and a remediation bot | Maximum — the practice is embodied | Top tier; pairs with the ODR workshop's automation-governance audit |
A domain installment of The Triad of Prompt Lenses; pairs with the automation-governance audit from ODR & AgODR.