Problem

PR #30745 (May 24 2026, commit e4a1220f8) restricted the default hermes-webhook toolset to a safe subset:

_HERMES_WEBHOOK_SAFE_TOOLS = ["web_search", "web_extract", "vision_analyze", "clarify"]

The rationale in the code comment is sound: webhook payloads can originate from untrusted third parties (e.g. GitHub PR titles/comments, Stripe metadata), so prompt-injection into a webhook handler should not be able to reach terminal, write_file, send_message, or HA service tools. Good default for the public-internet-facing case.

The problem is that webhook subscriptions are also the documented integration path for trusted, locally-authenticated event sources — Home Assistant via rest_command + X-Gitlab-Token, Hubitat virtual switches, internal CI runners, etc. The bundled skills ha-hermes-webhook-bridge and ha-cross-sensor-snapshot-gate both build flows whose prompts depend on terminal/write_file/send_message (fetch snapshot → save to disk → vision_analyze → send_message to Telegram with MEDIA:). After #30745, every such route silently breaks: HA fires correctly, the gateway dispatches the agent, but the agent has no tools to complete the task and either bails with a clear failure or hallucinates a no-op "ok" final response.

Today the only workaround is widening platform_toolsets.webhook globally in config.yaml — which restores capability for every webhook route, including the third-party-payload ones the original PR was designed to protect. That's a regression in granularity.

Proposal

Per-subscription toolset override on hermes webhook subscribe:

hermes webhook subscribe ha-front-door \
    --toolset hermes-cli \
    --deliver log \
    --prompt "..."

• New --toolset flag, repeatable (action="append"), accepts any registered toolset name from TOOLSETS.
• Persisted as toolsets: ["hermes-cli"] in the route dict in ~/.hermes/webhook_subscriptions.json.
• hermes webhook list displays the configured toolset (or "(default: hermes-webhook)" when unset).
• gateway/platforms/webhook.py reads the route's toolsets field; when present, passes that list as enabled_toolsets to the AIAgent instead of the platform default resolved via _get_platform_tools(config, "webhook").
• Default behavior unchanged: routes created without --toolset continue to get the safe hermes-webhook toolset.

This keeps the security default from #30745 intact for the GitHub/Stripe-style untrusted-payload case (which was the motivating case for the lockdown), while letting operators with authenticated LAN-only routes opt into the wider toolset on a per-route basis.

Alternatives considered

1. Revert security: restrict default webhook toolset capabilities #30745 — no, the safe default is correct for new users wiring up internet-facing webhooks.
2. Tell users to set platform_toolsets.webhook: [hermes-cli] in config.yaml — works, but is all-or-nothing across every webhook route on the gateway. Bad for any setup that mixes trusted LAN routes with untrusted public routes.
3. Add a "trusted/untrusted" boolean per route — less expressive than naming a toolset, and forces a hardcoded mapping of trusted → which-tools.

Impact

• Backwards-compatible: routes without toolsets in their JSON keep current safe-default behavior.
• Migration: users whose webhook flows broke at security: restrict default webhook toolset capabilities #30745 can re-add capability per-route with hermes webhook subscribe <name> --toolset hermes-cli (subscribe is idempotent on existing names).
• Docs: webhook-subscriptions skill and ha-hermes-webhook-bridge skill both need a note pointing operators at --toolset when their prompt needs terminal/send_message/write_file.

Repro

hermes webhook subscribe demo --prompt 'List /tmp via terminal and report back'
# Fire the route; agent responds with "I don't have terminal access" regardless of prompt.

Willing to implement

Yes — PR to follow if the design is acceptable.