/personal-opsec

name: personal-opsec
description: "Audit one person's own security setup — the founder or operator who holds the keys to the stack — and produce a prioritized gap report. Walks Karpathy's 15-control digital security checklist, adds account-recovery, SIM-swap, registrar, and hardware-key checks, and covers the AI-agent era: tokens your coding agents can read, MCP server trust, inbox-assistant prompt injection, clipboard exposure. Use when the user mentions 'personal opsec,' 'personal security audit,' 'secure my own accounts,' 'founder security,' 'Karpathy security checklist,' 'am I secure,' 'hardware key,' 'YubiKey,' 'SIM swap,' 'port-out PIN,' 'FileVault,' 'BitLocker,' 'password manager,' 'recovery codes,' 'registrar lock,' 'what can my AI agent see,' 'API keys on my laptop,' 'MCP trust,' or wants to harden their own accounts and machine."
allowed-tools: Read, Grep, Glob, Bash(fdesetup status:*), Bash(/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate:*), Bash(/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode:*), Bash(scutil --dns:*), Bash(spctl --status:*), Bash(csrutil status:*), Bash(sw_vers:*), Bash(which:*), Bash(ls -l:*), Bash(gh auth status:*), Bash(whois:*), Bash(manage-bde -status:*), Bash(lsblk:*), Bash(resolvectl status:*)

Personal OpSec — Audit One Operator's Own Security Setup

Every other skill in this catalog audits an organization, a codebase, or infrastructure. This one audits **a person**: the founder, solo operator, or small-team admin whose laptop, email, phone number, and password manager are the real root of trust for the whole stack. If their email falls to a SIM swap, it doesn't matter how good the IAM policies are.

**This is not security-awareness or phishing training.** No quizzes, no "think before you click" content. The agent checks the person's actual state — on the local machine where it can, by asking where it can't — and produces a prioritized gap report in the same finding/disposition vocabulary as the audit skills, ready for `finding-triage`.

The baseline is Karpathy's 15-control list (via Andrej Karpathy's digital security checklist), plus the operator-critical items it skips and the AI-agent layer it predates. Products named below are examples of a control, not endorsements; any tool that provides the control counts.

Cross-references: `secrets-audit` for API keys and tokens on disk that coding agents can read; `agent-supply-chain-audit` for MCP server and agent-extension trust; `prompt-injection` for personal and inbox assistants that read untrusted mail; `iam-audit` for the org-level MFA and access policy this person administers; `breach-patterns` for the phishing and account-takeover patterns behind these controls; `finding-triage` for dispositions on each gap; `osint-recon` if the user wants to see what's public about *themselves*.

Authorization: consent and scope (before anything else)

• **Only the person being audited runs this, on their own accounts and their own machine.** Confirm that at the start. If the user asks to audit a co-founder, employee, partner, or anyone else, stop: that person runs it themselves, with their own consent. Refuse to profile, enumerate, or assess someone else's personal security, accounts, devices, or exposure without their explicit consent — that's surveillance or pre-attack recon, not opsec.
• On a work machine managed by an employer, local checks are fine, but don't attempt to read or change MDM/EDR configuration.
• **Read-only.** The agent never changes a setting, enables a feature, installs anything, or logs into an account. It reports; the user fixes.
• **Never read secret values.** The agent doing this audit is itself an AI agent with file access — exactly the exposure Part C measures. Check existence, file permissions, and match *counts*; never print a token, key, recovery code, or password into the transcript. If the user pastes one, tell them to rotate it.

How evidence turns into verdicts

| Evidence | Verdict | Notes | |---|---|---| | Agent ran a read-only check and the control is absent/off | `confirmed` | Severity assigned; disposition later | | Agent ran a check and the control is present | `rejected` | Record the control and where it was observed (e.g. `fdesetup status` → "FileVault is On") so re-runs don't re-raise | | User reports state the agent can't check (MFA type on an account, carrier PIN) | `needs_validation` | `blockers[]` = why the agent can't see it; `validation_plan` = the exact settings page or step the user checks. User says "yes, I have it" → still needs_validation until they've looked, then confirmed/rejected | | Privacy-preference control with no account-takeover or data-loss path | **Hardening note** | Not a finding, no severity, reported separately |

Severity follows the shared calibration: impact is what an attacker gets (email takeover, prod credentials, money movement), likelihood is how exposed the gap is. `overall ≤ impact`. Fingerprints are stable and look like `personal-opsec:<control>:<gap>` — e.g. `personal-opsec:k05-disk-encryption:off`, `personal-opsec:x01-carrier-port-pin:missing` — never including dates or severity.

Workflow

1. Confirm consent and scope (above). Ask which OS, which phone carrier/country, and which accounts are "crown jewels" (primary email, GitHub, cloud console, registrar/DNS, bank/Stripe, password manager). 2. Run the local checks in one pass (below). Report what you ran. 3. Walk Part A, B, C. For anything not checkable, ask a short, specific question — batch them, don't interrogate one at a time. 4. Build the gap report (Output Format), prioritized P0/P1/P2, and hand confirmed findings to `finding-triage` for disposition.

Local checks (read-only)

macOS — run these; each is pre-approved and changes nothing:

sw_vers                                                          # OS version (old major = missing security updates)
fdesetup status