# Skill vetting Hermes v0.10.0 bundled 118 skills. Later releases add more. Reviewing them once is a weekend; reviewing every update is a standing job nobody has been given. This is the triage that makes the standing job small enough to actually do. --- ## The mistake to avoid first Do not start by reading 118 skills. Most of them cannot hurt you, and the effort spent confirming that is effort not spent on the handful that can. Sort by capability before reading a single line: a skill that formats text and a skill that executes shell commands are not the same review, and treating them alike guarantees the second one gets the same five minutes as the first. --- ## Four tiers Sort every skill into exactly one. When in doubt, sort up, not down. **Tier 3 — reaches outside the machine.** Network calls, credential use, sending messages, posting, paying, writing to remote systems. These get read in full, every version, by a person. There will not be many. If there are many, that is the finding. **Tier 2 — changes local state.** Writes files, runs commands, mutates memory, installs anything. Read the diff on every update. Read in full on first adoption. **Tier 1 — reads local state.** Reads files, queries local data, inspects the repo. Read once on adoption, then diff-only. A read-only skill still shapes what the agent believes, which is why it is not tier 0. **Tier 0 — pure transforms.** Formatting, parsing, arithmetic on data already in context. Spot-check on adoption. No standing review. --- ## The vetting contract One file per adopted skill, in `01-authority/skills/`. The CLI validates them. ```yaml skill: version: tier: 0 | 1 | 2 | 3 reviewed_by: reviewed: capability: network: false # true for any egress, including "just an API" credentials: false # true if it reads, uses or forwards any secret shell: false # true for command execution of any kind writes: [] # paths or systems it can modify sends: [] # channels it can emit to: email, chat, social, git review: read_in_full: false # required true for tier 2 on adoption, tier 3 always notes: "" # what you actually checked, not "looks fine" decision: adopt | reject | sandbox ``` `sandbox` means adopted but confined — the agent may call it only where the authority contract's boundaries make its worst case survivable. --- ## What to look for, by tier The questions that repay the reading time: **Tier 3.** Where does the destination come from? A skill whose target host is fixed is a different risk from one that takes a host from the model's output. The second means a prompt-injected instruction can choose the recipient of your data — the skill was never compromised, it did exactly what it was told. **Tier 2.** What bounds the path it writes to? "Writes a file" is fine. "Writes a file at a path assembled from model output" is the same class of problem one layer down. **Tier 1.** What does it pull into context that you would not paste yourself? A skill that reads broadly is a skill that can be steered into reading something sensitive and then repeating it. **Tier 0.** Only that it is genuinely tier 0. Most mis-sorting happens here, because a skill's description describes its purpose, not its capability. --- ## Re-vetting on update The trigger is a version change, not a calendar. - Tier 3: full re-read. Every time. No exceptions for patch releases — a patch is where a destination quietly becomes configurable. - Tier 2: read the diff. If the diff touches capability rather than behaviour, promote it to a full read. - Tier 1: read the diff. - Tier 0: confirm it is still tier 0. Record the reviewed version in the contract. An un-updated `version:` field next to an updated skill is the signal that the review did not happen, and it is the only signal you will get. --- ## When the count is the finding If sorting produces twenty tier-3 skills, the problem is not the review burden. It is that the deployment has twenty ways to reach outside the machine, and almost no deployment needs that. Cut before you read. The same applies to `shell: true`. One shell skill is a decision. Four is an accident.