GitHub Repo
Hermes Agent Community Report Says Approval Shortcut Skips Permission Check, Allowing Group Users to Approve Pending Commands
A Hermes Agent community report on October 30 says text and emoji approval shortcuts may bypass admin-command restrictions. Public code shows the shortcut calls the approval handler directly, but the impact still needs independent reproduction and maintainer confirmation.

On October 30, Hermes Agent received a community report describing inconsistent approval permissions: after an admin list is configured, ordinary users may be unable to run /approve but may still approve the same pending command by replying with text. The reporter said this behavior occurs in v0.22.5 and in the main-branch commit they checked. At the time of review, the issue remained open and listed no related fix. Community report
The official documentation divides messaging-platform users into two tiers: admins in allow_admin_from can run all registered commands, while other permitted users can run only commands specified by user_allowed_commands. Groups have corresponding settings. A scope without a configured admin list remains in compatibility mode, where all permitted users can run commands. This report therefore concerns approval consistency when tiered access is enabled. Official command documentation
The issue is in the plaintext approval routing used while the agent is busy. The public gateway/run_busy.py shows that _route_plaintext_approval_while_busy, when gateway control is allowed and a blocking approval is pending, recognizes short replies, rewrites the message as an approval command, and directly calls the approve or reject handler. The function itself does not call _check_slash_access. A code comment explains that the shortcut is intended to clear the wait immediately and avoid a deadlock caused by queueing the reply. Public code
The engineering concern is that an input shortcut that shares the action handler but not the authorization check can produce different permission outcomes depending on the entry point. According to the report, the risk requires both a permitted non-admin user and a command awaiting approval; current evidence does not support inferring that unauthorized external users can access the system.
The project’s security policy also says that callers on the allowlist are treated as equally trusted, and that deployments needing capability isolation should use separate instances and allowlists. Watch how maintainers reconcile this trust model with the command-tier documentation, and whether they add regression tests for ordinary users, group scopes, and the plaintext shortcut. For now, this remains an unconfirmed report of a functional permission issue, not a published security advisory. Security policy