What can an authorised message cause Hermes Agent to do?

A private messaging channel can be a convenient way to ask an AI agent for help. For a professional-services owner, the first job might be simple: summarise a brief without opening another application.

But “only approved people can message the agent” does not mean “the agent can only summarise briefs”.

In Hermes Agent, admitting a sender and limiting what the agent can do are different controls. Before connecting client material, ask your implementer to demonstrate both: who can get in, and what the configured agent can reach once they do.

This article concerns the Hermes Agent application, not the Nous Hermes model family or Digital Sanctum’s Hermes persona. It draws on documentation pinned to commit b07a3b46ed7579b7119c2b525e500d0994d42c24, checked on 28 September 2026 and compared with repository HEAD on 29 September 2026. No Hermes installation, channel or runtime test was performed for this article.

Start here

Contents

• Check the entry rule
• Check four separate controls
• Run a bounded pilot—not a live experiment
• Record what was actually observed
• Make the next decision

Check the entry rule

Example—not a deployed service: a small professional-services firm wants its owner to request summaries of a synthetic internal brief through one private messaging conversation.

The implementer first needs to establish what Hermes actually receives:

• Which messaging platform and adapter are involved?
• Is this a direct message, group conversation or another channel type?
• Which platform identities are permitted in that scope?
• Which allowlist or pairing rule admits them?
• Who can approve and revoke access?

The pinned messaging gateway guide says users outside an allowlist or direct-message pairing are denied by default. It documents platform-specific allowlists, GATEWAY_ALLOWED_USERS, and pairing approval, listing and revocation. It warns against GATEWAY_ALLOW_ALL_USERS=true for a bot with terminal access.

These are documented controls to inspect—not evidence that a particular installation is correctly configured. A successful direct-message test does not establish a group’s admission rules.

Most importantly, pairing admits a caller to the configured agent; it does not provide per-sender tool capability separation. The security policy treats callers within one authorised adapter set as equally trusted. Where callers need different capabilities, it recommends separate agent instances and allowlists.

If the owner and an assistant need different access, do not assume their job titles—or their messaging roles—create that separation.

Check four separate controls

The word “permission” can hide four different questions.

A regular-user tier is not a restricted-tool account

The gateway guide’s current admin/regular-user split gates slash commands. Plain chat is unaffected by that split. The guide presents tool-access gating as a possible future extension, not an existing per-user restriction.

If allow_admin_from is unset for a scope, the split is disabled and allowed users retain full command access. /whoami reports scope and tier, making it useful inspection evidence. It does not demonstrate that a regular user’s natural-language request cannot reach a terminal, file or network-capable tool. Source: messaging gateway guide

Available tools and host access need their own inspection

Common platform toolsets listed in the guide include terminal access. The implementer must inspect the effective configuration rather than assume a messaging connection is a summary-only interface.

The security policy says the default terminal backend executes commands on the host. A non-default terminal backend confines shell/file tools, not all code running in the agent process. It describes whole-process wrapping as the supported posture for untrusted external input and production or shared deployments. Approval gates, scanners, redaction and in-process tool allowlists are not containment boundaries. Source: security policy

For the owner, the practical question is:

If an admitted message asks for something outside the summary task, what prevents the effect—apart from an instruction asking the model not to do it?

The answer should identify enforced boundaries, such as inaccessible files or blocked network access, and evidence from the exact proposed setup.

A tool being available does not prove it was used. Equally, “I cannot access that folder” proves only what the agent said unless traces show what it attempted and what happened.

Run a bounded pilot—not a live experiment

The following is a proposed test plan. Every test is unrun. It is not a successful-test report or an instruction to experiment against production.

Ask the implementer to prepare:

• One disposable, isolated instance at a recorded Hermes revision.
• One named adapter and exact conversation scope.
• A permitted and an unpermitted test identity.
• A synthetic brief containing no client information.
• A separate harmless test file for a deliberate access-denial check.
• No real client files, production credentials or business-service integrations.
• Sufficient gateway, tool and environment evidence to distinguish rejection, refusal, attempted action and actual effect.

A real messaging-platform test may require dedicated test accounts and a test bot credential. Do not describe those as fake platform identities or “no credentials”. Keep any necessary test credential narrowly scoped, outside the manuscript and out of retained evidence.

A fixture or simulated event can test part of the gateway logic, but it does not prove the live platform’s identity mapping works. Record which kind of test was used.

1. Establish that the permitted path works

From the permitted test identity, request a summary of the synthetic brief.

Check that the message reaches the intended instance and scope, that the expected work occurs, and that the response reaches only the intended test recipient. This is the positive control: without it, a later denial might merely reflect a disconnected adapter or broken instance.

2. Test entry from an unpermitted identity

Send a test message from the unpermitted identity in the same intended scope.

Inspect the gateway decision and dispatch evidence. Confirm whether any agent work or tool call occurred. Where output delivery and approval handling have separate paths, test those paths with controlled fixtures or dedicated test recipients; do not infer their behaviour from a rejected incoming message.

The desired observation is rejection at the relevant authorisation boundary—not merely a final reply saying “access denied”. The policy describes authorisation checks for work, output and approvals; the pilot must distinguish which were actually exercised. Source: security policy

3. Test an admitted request outside the task

From the permitted identity, request access to the harmless test file that the pilot boundary is intended to deny.

The file must exist in the controlled test environment but be inaccessible to the agent process under the intended configuration. Otherwise, “file not found” could be mistaken for successful access control.

Inspect:

• Whether the agent attempted a tool call.
• Which tool and execution path were involved.
• Whether the environment denied access.
• Whether any file content reached a tool result, model context or reply.
• Whether another tool path bypassed the intended restriction.

A model refusal is useful evidence of that interaction, but it leaves enforcement untested if no access attempt occurred. The implementer may need a separate controlled boundary check using the same execution identity and environment. Label that as a boundary test, not as an observed Hermes action.

If outbound access is also in scope, use a controlled synthetic destination and observable network controls. An absent integration, invalid address or unreachable server alone does not prove that the configured boundary blocks outbound access. Do not send to real customers or third-party recipients.

Know what a small pilot cannot prove

These checks can expose configuration mistakes. They cannot establish that every future prompt, plugin or tool path is safe.

Do not generalise a direct-message result to a group, or one instance’s result to another. Do not treat a /whoami tier label as capability separation. Different privilege classes need separate constrained instances and allowlists, or another independently demonstrated boundary.

Record what was actually observed

Complete one evidence sheet per pinned instance and conversation scope. Keep identifiers and trace references in the restricted operational record, not a public article.

H2 synthetic messaging pilot — PRIVATE

Date/time, implementer and reviewer:
Hermes revision and effective configuration reference:
Instance, adapter and exact conversation scope:
Live-platform test or fixture; coverage limitations:
Permitted/unpermitted test identity references:
Allowlist/pairing rule; approval and revocation controls:
allow_admin_from setting; observed /whoami scope and tier:
Session origin/routing reference — not an authority credential:
Effective model, toolset, plugins and loaded skills:
Terminal backend and whole-process isolation:
Effective mounts, network access and credential scope:

Permitted summary — dispatch, tools, effects and recipient:
Unpermitted sender — admission and dispatch evidence:
Output/approval authorisation paths — tested or not tested:
Out-of-scope file request — attempts, denial and content exposure:
Separate boundary check, if needed — method and result:
Outbound test, if in scope — controlled destination and evidence:

Trace references, access restrictions and redaction check:
Unexpected effects or configuration differences:
Untested paths and remaining uncertainty:
Decision, accountable owner and next review date:

Use “not tested” when no relevant path was exercised and “inconclusive” when evidence is insufficient. Neither means “pass”.

Make the next decision

Stop the pilot and investigate if:

• The exact scope or effective configuration is unclear.
• An unpermitted sender reaches work, protected output or approval handling.
• The agent reads the prohibited test file or produces another effect the boundary was meant to prevent.
• Traces cannot distinguish a model refusal from an enforced denial.
• Real client information or production credentials are discovered in the test environment.

Do not connect real data to resolve those uncertainties.

Proceed only to a further controlled review when the permitted path works, relevant negative tests have complete and consistent evidence, and the effective capabilities and boundaries match the proposed job. Untested output, approval or network paths must remain explicit limitations.

For the business owner, the next action is modest: ask for the completed evidence sheet before approving access to client material. A private channel is useful, but it is not a substitute for a constrained agent.

Read next

• Hermes Agent workflow-selection guide: decide whether the supervised workflow is worth adopting.
• What may an AI agent read or change?: distinguish identity from authority, including for agents other than Hermes.
• Command approval and actual effects: examine the selected approval mode and what happens after approval; approval alone does not establish safety.

If the workflow will retain information or reusable procedures, consult Hermes memory versus skills separately. Channel pairing does not settle what information should be retained or which reusable procedures should be allowed.