Skill Curation, Permissions, and Blank Slate Setup

The Cheapest Guardrail: Not Loading the Capability at All

Every later lesson in this module, sandboxing, approval gates, debugging, addresses what happens once a capability is available to the agent. This lesson is about a step earlier: deciding what’s available in the first place. A tool the agent never had access to cannot be the vector for a mistake, which makes toolset and skill curation the cheapest, highest-leverage guardrail in your whole deployment.

Applying Blank Slate After the Fact

Lesson 2 mentioned Blank Slate as one of three hermes setup modes. Most teams don’t choose it on day one, Quick Setup’s convenience is genuinely useful while you’re learning the system, which is exactly why this lesson matters: you can retrofit the same discipline onto an existing installation.

# ~/.hermes/config.yaml
agent:
  # Allow-list: ONLY these load. Nothing else, even if a skill or
  # MCP server tries to register more, gets exposed to the model.
  platform_toolsets:
    cli: ["filesystem", "web_search"]

  # Deny-list: belt-and-suspenders for anything that might otherwise
  # slip in through a bundled default or a future update.
  disabled_toolsets: ["code_execution", "shell", "image_generation"]

Verify the result matches your intent:

hermes tools    # confirm only the allow-listed toolsets actually appear
hermes doctor    # confirm no configuration conflicts

Curating Skills, Not Just Tools

Toolsets (Lesson 7.3, Lesson 8) control built-in and MCP capability. Skills (Lesson 11) are a separate surface worth the same scrutiny, especially once a skill can be triggered by cron (Lesson 17) or from a lower-trust messaging platform (Lesson 18).

Nous Research curates and stress-tests every bundled skill, tool, and plug-in that ships by default, a specific, deliberate quality bar. A skill your team wrote via /learn has not been through that process. Before promoting a custom skill from “useful in my private CLI session” to “reachable from the public Discord bot,” give it the same kind of review:

# Inspect exactly what a skill will do before trusting it broadly
cat ~/.hermes/skills/your-skill/SKILL.md

Questions worth asking for any custom skill headed for a lower-oversight surface:

• Does it touch destructive operations (deleting data, sending messages on your behalf, spending money)?
• Does it depend on tools that should be restricted on that surface anyway (per Lesson 18’s per-platform toolset design)?
• Would you be comfortable with anyone who can reach that surface triggering it, unsupervised?

If the answer to the last question is no, either narrow the skill’s own instructions, restrict the toolset it depends on, or keep it available only on higher-trust surfaces.

Least Privilege as a Default Posture

The practical shift this lesson asks for: stop treating “start permissive, lock down if something goes wrong” as the default. Start from Blank Slate, and add capability only as a deployment’s actual, demonstrated needs require.

This isn’t a claim that permissive defaults are never appropriate, your private, single-user CLI session (Lesson 18’s first rollout tier) can reasonably run broad. It’s a claim that the decision should be deliberate at every tier, not inherited by default from whatever Quick Setup gave you on day one.

Exercise: audit your current installation’s platform_toolsets and disabled_toolsets against Blank Slate. For each currently-enabled toolset, write one sentence justifying why that specific deployment needs it. Anything you can’t justify in one sentence is a candidate for removal.