hermes - 💡(How to fix) Fix [Feature]: Add pre/post tool-call hooks to the plugin context API [1 participants]

Problem or Use Case

Disclosing affiliation upfront: I work on AgentGuard at GoPlus Security (https://github.com/GoPlusSecurity/agentguard, MIT). Filing this so a Hermes adapter is possible, but the hooks are useful for any plugin that needs to inspect tool calls (security, audit, dry-run, custom policy, logging). A skill can't solve this. Skills are loaded on demand to teach the agent how to do something. They run after the model decides to call a tool, and they can't block or modify the call. Security and policy enforcement need to sit between the model's tool decision and the actual execution. That requires runtime hooks, not a skill, and not a separate tool. Concrete failure modes in Hermes today that no skill can catch:

• web / browser output piped into terminal / code_execution: prompt injection in a fetched page pivots to RCE before any skill sees it.
• file / memory writes to MEMORY.md / USER.md: poisoning persists across sessions and skill reloads. A skill can't audit writes it didn't initiate.
• messaging / discord / tts: exfiltration channel for any token the agent has handled. A skill can't enforce a deny-list on outbound payloads.
• cronjob + poisoned memory: agent self-reschedules into a failure mode that compounds in the unattended path, where no skill is loaded.

These are about action shape, not message content, so text-only prompt-injection filters miss them too.

Proposed Solution

Two new hook events on the existing plugin context API:

# ~/.hermes/plugins/security_plugin.py (or pip entry point)
def setup(context):
    context.register_hook("pre_tool_use", scan)
    context.register_hook("post_tool_use", scan)

def scan(tool_name, args, session):
    # {"action": "allow"}
    # | {"action": "block", "reason": str}
    # | {"action": "require_user_confirm", "reason": str}
    ...

Behavior:

• pre_tool_use fires after the model selects a tool, before the tool runs. Handlers can allow, block, or require confirmation.
• post_tool_use fires after the tool returns, before the result goes back to the model. Same return shape. Useful for redaction and post-hoc audit.
• If multiple plugins register, strictest decision wins (block > require_user_confirm > allow). No core dependency on any specific plugin. Useful for security, audit, logging, dry-runs, custom policy.

Same shape already runs in production against two other agent platforms on a shared decision engine: Claude Code (PreToolUse / PostToolUse) and OpenClaw (before_tool_call / after_tool_call). A Hermes adapter would be the third instance of this pattern, not a new design. The AgentGuard plugin itself would live in a separate repo (GoPlusSecurity/hermes-agentguard), installable via pip entry point or ~/.hermes/plugins/. No AgentGuard code in this repo. For reference on the latency budget: AgentGuard's scan runs at ~0.13 ms per call on an open 84-sample benchmark, which makes the hooks viable in the critical path.

Alternatives Considered

A skill that reads tool history and warns: runs after the fact, can't intercept the call. Doesn't prevent damage. A wrapper tool that the model is supposed to call instead of the real tool: the model won't reliably choose it, and it forces forking every existing tool plugin. External MCP proxy: works for MCP tool calls but not native Hermes tools. Adds a process boundary and latency. Doesn't cover memory writes or skill-initiated actions. Patch core for each consumer separately: doesn't scale. Generic hooks let multiple plugins (security, audit, logging) share one API.

Feature Type

Other

Scope

Medium (few files, < 300 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)