Overview

Add a first-class website blocklist system that web_extract and browser tools consult before fetching or interacting with external sites. The goal is to give users an explicit, configurable safety layer against prompt injection, malicious content, and generally untrusted domains.

This should support both personal blocklists and shared/importable blocklists so users can maintain their own policies while also benefiting from community-curated safety lists.

The user who requested this feature said they will be working on implementation.

Problem

Today, Hermes can browse or extract content from arbitrary websites if the agent decides to do so. For security-conscious users, this creates two problems:

1. There is no native way to declare "never visit these domains"
2. There is no reusable mechanism for sharing known-bad or high-risk site lists across users

This matters especially for:

• prompt injection defense
• malicious or deceptive pages
• domains known to host unsafe content
• users who want tighter browsing controls without disabling web capabilities entirely

Proposed Design

Core behavior

• Add a user-managed blocklist of domains / host patterns / optionally URL patterns
• Enforce it in web_extract and browser tools before navigation/extraction occurs
• Return a clear blocked-by-policy message when a request is denied

Sharing model

• Support local personal blocklists
• Support importable/shared lists (community, team, or official curated lists)
• Allow users to combine multiple lists into an effective policy

UX / policy requirements

• Clear config surface for adding/removing/listing blocked sites
• Easy visibility into which rule blocked a request
• Safe defaults that do not silently bypass user policy
• A trust model for shared lists (official vs community vs user-defined)

Why This Is Valuable

A blocklist makes the web toolchain more configurable for users who care about security but still want browsing enabled. Instead of an all-or-nothing model, Hermes can support a middle ground:

• browse normally, but never touch explicitly disallowed domains
• opt into community-maintained safety lists
• reduce exposure to prompt injection and known-risk sites

This also aligns well with existing safety/trust patterns in the project (for example, differing trust levels for skills and install sources).

Initial Scope

A practical MVP could include:

• exact-domain and subdomain matching
• enforcement in web_extract
• enforcement in browser navigation tools
• user-visible error messaging
• config-backed local blocklist

Possible follow-up work:

• shared list import/export
• allowlists / precedence rules
• wildcard patterns
• per-tool policy differences
• official maintained safety feeds

Open Questions

• Should shared lists live in config, skills, or a dedicated policy file format?
• Should the system support both blocklists and allowlists from day one?
• How should precedence work if a shared list blocks a domain but a local user wants to override it?
• Should blocked attempts be logged for audit/debugging?
• Should this extend beyond web_extract and browser tools to other URL-capable tooling later?

Note

I will be working on this issue