Hermes Blank Slate: Tighter Agent Tool Scoping

Nous Research updated its open-source Hermes Agent with a Blank Slate setup mode that flips the default security posture of an AI agent from permissive to restrictive. Reported by MarkTechPost on June 20, 2026, the new mode boots an agent with only two toolsets active — file operations and a terminal — and leaves everything else off until you deliberately turn it on.

That sounds like a setup-wizard detail. It is actually a security design decision worth understanding. Most agent frameworks start wide-open and ask you to lock things down. Blank Slate starts closed and asks you to open things up. The difference is the gap between a denylist and an allowlist, and for autonomous agents that can read email, query databases, and trigger workflows, that gap is exactly where over-permissioning lives.

This guide covers what Blank Slate actually enables and disables, why the configuration being durable across upgrades matters more than it first appears, how the two config keys work, and how the mode maps cleanly onto the least-privilege controls the OWASP Top 10 for Agentic Applications 2026 calls for. Every feature detail below is vendor-stated via Hermes documentation and June 20 coverage rather than independently benchmarked — verify against the live docs before production use.

Hermes Agent now offers three distinct ways to set up an agent. Quick Setup uses Nous Portal OAuth and requires no API keys. Full Setup walks you through every provider and tool by hand. Blank Slate, the new option, boots with the minimum necessary configuration and asks you to add everything else explicitly.

The minimal baseline enables exactly three things: provider and model selection, the File Operations toolset, and the Terminal toolset. From there you pick one of two completion paths — finish immediately with file and terminal only, or walk through the optional configuration and opt into each tool, skill, plugin, MCP server, and messaging channel one at a time. Nothing is bundled by default that you did not request.

One detail is worth not conflating. The previous release, v0.16.0 (The Surface Release, June 5), introduced an install --no-skills flag and opt-in handling for the default skill profile. That was a skills-layer precursor — it governs which skills load, not the full toolset scope. Blank Slate is the broader idea: a complete setup mode that scopes every toolset category, not just skills.

The architectural story is a single inversion. A denylist starts from everything-enabled and subtracts known-bad behaviors; an allowlist starts from nothing-enabled and adds approved ones. Most agent frameworks default to the former — they ship with broad capability and expect you to restrict it later, which means anything you forget to lock down stays open.

Blank Slate defaults to the latter. An agent boots with file and terminal access only, and any further capability is an explicit, recorded decision. The practical consequence is that the failure mode flips from accidentally too permissive to deliberately too restrictive — and a too-restrictive agent fails safely, by refusing to do something, rather than dangerously, by doing something it should not have been able to do.

This is the angle worth sitting with. Hermes Agent ships 60+ built-in tools across categories — web search, image generation, text-to- speech, browser control, vision, and more. In a denylist default, all of that capability surface is live the moment the agent starts, and your security work is reactive. In Blank Slate, that surface is dark until you light each part of it on purpose. For a framework with a capability set this large, the inversion is not cosmetic; it meaningfully changes how much you have to reason about before you trust the agent with real tasks.

The table below maps Hermes Agent's toolset categories to their default state under Blank Slate and to the OWASP agentic risk category each one touches if enabled without scoping. Default states are drawn from the Hermes docs and the June 20 coverage; the risk mapping is our reading of the OWASP Top 10 for Agentic Applications 2026 — it shows why a tighter default matters per category, not a vendor claim about any specific tool.

The disabled list is long on purpose. The reported set of items off by default includes web search, browser control, code execution, vision, memory, delegation, cron, skills, plugins, MCP servers, compression, checkpoints, smart routing, and memory capture — well over a dozen categories. Read against the OWASP risk column, the pattern is clear: the most injectable inputs (web, vision) and the highest-impact actions (code execution, MCP) are precisely the ones Blank Slate leaves dark until you decide otherwise.

Plenty of tools let you disable a capability. The harder problem is keeping it disabled. Runtime toggles are fragile across upgrades — a new version ships, a default changes, and a capability you turned off quietly comes back. For a security control, silent re-enablement is close to no control at all.

Blank Slate writes its choices to disk and pins them. A toolset you skipped during setup stays off after hermes update; an upgrade cannot silently re-enable something you excluded. Because the mechanism is a config file rather than a runtime flag, the pinning is architectural — it persists by design, not by a default the next release might overwrite.

This durability extends beyond the top-level agent. The v0.17.0 changelog notes that assigned-profile toolsets are now pinned for worker agents, and that background review inherits the parent toolset configuration. In plain terms: the scoping you set does not leak when an agent delegates to sub-agents — the allowlist follows the work down the tree. It is fair to call Hermes Agent one of the first open-source agent frameworks to make toolset pinning upgrade-durable by design; whether it is strictly the only one is not something the available record establishes.

The configuration lives in ~/.hermes/config.yaml and is written to two explicit keys. The first, platform_toolsets.cli, is the enabled toolsets list — the allowlist. The second, agent.disabled_toolsets, is the comprehensive disabled list — the denylist. Secrets such as API keys live separately in ~/.hermes/.env, keeping credentials out of the capability manifest.

Encoding both lists, rather than just one, is the design choice worth copying. An allowlist alone tells you what is on; a paired, comprehensive denylist makes the off state explicit and auditable — you can read the config and see at a glance exactly what was excluded, not infer it from absence. That pairing is what makes the file a usable security artifact, and it is the part any team can adopt regardless of which framework they run.

The OWASP Top 10 for Agentic Applications 2026 identifies Tool Misuse and Exploitation (ASI02) and Identity and Privilege Abuse (ASI03) among the top agentic security risks. The documented mitigation for both explicitly requires strict least-privilege controls for each tool — scope, rate limits, and allowed data. Blank Slate is a direct, setup-time implementation of that mitigation.

The fit reaches the first risk too. OWASP's ASI01 (Agent Goal Hijack) recommends enforcing least privilege so agents only get the goals, tools, and data they actually need — which makes tool scoping a mitigation for prompt-injection attacks that try to redirect an agent's goals. An agent that cannot browse the web or execute arbitrary code has far fewer levers an injected instruction can pull.

Read together, the standards and the feature describe the same posture from two directions. OWASP says least privilege is the control; Blank Slate makes least privilege the default state of a fresh agent. The interesting part is that this used to require after-the-fact configuration work and now arrives as the starting point — a small but real shift in where the security burden sits. For teams formalizing this into policy, our agent governance policy and agent access controls guides cover how tool scoping fits a broader compliance framework.

Security vendor Zscaler frames the practical risk of an over-permissioned agent as its blast radius — a metric with three variables: the number of accessible systems, the types of data domains reachable, and whether permissions include write capability. By starting with file and terminal only, Blank Slate reduces all three at once: fewer systems are reachable, fewer data domains are in play, and the broad write-capable integrations stay off until you enable them.

That matters because, without zero-trust controls, AI agents typically receive broader access than most employees — able to read email, query databases, update CRM systems, and trigger workflows, often through full-scope tokens, inherited permissions, and standing service accounts. The chart below shows how the blast-radius surface collapses between a wide-open default and a Blank Slate baseline.

Blank Slate is not the right default for every situation — it trades convenience for control. The decision matrix below sorts the common cases. Note one practical prerequisite throughout: Hermes Agent requires a model with at least a 64,000-token context window and rejects smaller ones at startup, so any local-model plan has to account for that floor.

A note on the messaging side: Hermes Agent supports 20+ messaging platform integrations — Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Email, SMS, and more — through a single gateway, and Blank Slate keeps all of them off until you opt in. For agents that will eventually live in a team chat, that means you connect the one channel you actually need rather than inheriting a wide messaging surface by default. Tighter toolsets also make behavior easier to reason about; our agent observability guide covers why a smaller capability surface produces cleaner traces. For the broader landscape, see our overview of open-source agentic AI foundations and the existing Hermes Agent desktop app walkthrough. The permission model also rhymes with autonomous permission decisions in other agent tooling.

Standing this up well is the kind of work our AI digital transformation engagements start with: scoping each agent to least privilege, mapping toolsets to your risk model, and committing the config as a reviewable artifact before anything touches production data.