Essay 5 of 10

Nothing runs until a person types their name

Himanshu Saxena · Sep 13, 2026

A checklist you cannot see is not a public baseline. A command you did not read is not an inspection. This tool’s safety model is simple: a person approves each check, by name, before it runs. The website never does that for you.

The Defense Information Systems Agency (DISA) writes STIG check text as prose for a human inspector. Someone still has to turn that prose into a command a computer can run. That translation can be wrong in a quiet way. A command might measure a related setting and still return a clean number. If the tool then prints “pass,” the error is invisible. The design here assumes authoring is untrusted — whether a person drafted the command or a language model did. Trust starts at review, not at generation.

Every check this project ships is therefore unreviewed. That is not an unfinished feature. An approval is worthless if it was not made by the person accountable for the machine. When you download a scanner from stig.hsaxena.com, the zip already knows which rules you ticked. It does not mark those checks approved. The local page will show them as unread. You read the command. You type your name. Only then may that check run.

1. 1 Tick rules on the hosted page. Nothing is approved yet.
2. 2 Download a zip. Scanning stays on that computer.
3. 3 Read each command. Confirm it only looks.
4. 4 Type your name. That freezes a fingerprint of the exact bytes.
5. 5 Only then may the check run — or the safety gate refuses it.

The name is not decoration. Approval records a fingerprint — a SHA-256 digest — over the fields that decide what executes: the identifier, the mode, the command, the comparison, the expected value, and whether privilege is required. If any of those bytes change later, the digest no longer matches. The check is treated as drifted and refused. The signature always refers to specific text a human actually saw. That is what makes an AI-assisted authoring loop auditable. “A model helped write this” is a provenance note. “Jordan Hale approved these exact bytes on Tuesday” is evidence.

Jordan Hale, in the example run, is a fictional reviewer. On a real machine you type a real name. The program will not invent one. It will not approve a batch because you clicked a banner. It will not run a check that has no command — some DISA rules are a GUI inspection or an interview, and those stay manual. It will not run a check the safety gate rejects. Two rules have to hold at once: every executable named in the command is on a read-only allowlist, and no forbidden construct appears. Writes, network clients, privilege escalation, and destructive verbs are refused. Approval is permission to look, not permission to change.

Why be this strict for a school MacBook? Because the alternative is a tool that is convenient and unaccountable. A coordinator under time pressure will click “run all.” A language model will happily produce a command that looks right. If those two facts meet without a gate, the machine is no longer being inspected. It is being driven by text nobody can defend. Public-interest software that touches education and care systems should fail closed. Unreviewed means it does not run. Drifted means it does not run. Unsafe means it does not run. The report must then say that those rules were not evaluated. Silence is not a pass. That honesty is the subject of the next essay; the gate is what makes the honesty possible.

There is a second reason for a typed name: organisations without a security team still have people. The office manager, the volunteer technician, the one teacher who “knows computers” — they are the accountability layer. Asking them to read a short command and put a name on it treats them as adults. Hiding the command behind a green button treats them as a risk to be automated away. The second approach is how tools earn distrust. The first approach is slower. It is also how you can later answer “who decided this was safe to run?” without guessing.

The website cannot take that responsibility even if it wanted to. It is static files on GitHub Pages. It never sees the MacBook. It never receives a name. The banner on the start page is literal: this website does not scan your machine and never will. Checks stay unreviewed until a person types their name on the computer they downloaded. That split is easy to skip in a demo video. It is the whole product. Hosted pages explain and package. Local code inspects. Humans approve.

AI has a defined place in this picture and a defined exclusion. A model may help write a plain-English summary or draft a candidate check offline. It does not approve. It does not execute. The skill files in this repository tell assistants the same rule, and the scanner enforces it. That is not hostility to automation. It is a boundary that belongs in any tool offered as public infrastructure. If a later “harden” module ever writes a fix script, the same boundary should apply: a person reads the change, types a name, and accepts a frozen fingerprint. Until that work exists, this release only looks.

If you take one practice from this essay, take this: do not run a check you have not read, and do not let a page in a browser pretend it read one for you. DISA’s public checklists are worth using. They are not worth using blindly. A typed name is a small ritual. It is also the difference between a scan you can stand behind and a black box you cannot explain to a director, a parent, or yourself.

Next: Silence is not compliance.

The free STIG Checker tool — pick a computer, read the rules, download a local scanner — lives at stig.hsaxena.com.

All STIG essaysPrevious: Settings gaps are not Hollywood hackingNext: Silence is not compliance