Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix Security/UX proposal: gateway-level /trust-above for safe public-thread context import [1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17856•Fetched 2026-05-01 05:55:29
View on GitHub
Comments
1
Participants
1
Timeline
7
Reactions
0
Author
asdigitosasdigitos
Participants
asdigitosasdigitos
Timeline (top)
labeled ×5commented ×1cross-referenced ×1

Proposal for a gateway-level /trust-above mechanism for public Slack threads so an allowed user can explicitly unmask prior thread messages above the command, without relying on the model to interpret trust instructions.

This comes from a practical Slack-thread security/cost review in a downstream fork, but the design target is generic gateway behavior.

Related downstream discussion / draft:

  • asdigitos/hermes-agent#1

Root Cause

Proposal for a gateway-level /trust-above mechanism for public Slack threads so an allowed user can explicitly unmask prior thread messages above the command, without relying on the model to interpret trust instructions.

This comes from a practical Slack-thread security/cost review in a downstream fork, but the design target is generic gateway behavior.

Related downstream discussion / draft:

  • asdigitos/hermes-agent#1
RAW_BUFFERClick to expand / collapse

Summary

Proposal for a gateway-level /trust-above mechanism for public Slack threads so an allowed user can explicitly unmask prior thread messages above the command, without relying on the model to interpret trust instructions.

This comes from a practical Slack-thread security/cost review in a downstream fork, but the design target is generic gateway behavior.

Related downstream discussion / draft:

  • asdigitos/hermes-agent#1

Problem

Current behavior has two important properties:

  1. Ingress authorization is mainly user-based

    • Gateway authorization is centered on user_id / *_ALLOWED_USERS.
    • Slack does not appear to have a generic allowed_channels gate similar to Discord.

  2. Slack thread bootstrap can import prior thread context

    • On first thread/session bootstrap, the Slack adapter may fetch prior thread messages and prepend them as context.
    • In a public thread, this means messages from non-allowed users can become indirect prompt-injection input when an allowed user later invokes Hermes.

There is also a cost side:

  • Once imported into transcript/session history, that context is replayed on later turns, so noisy public-thread context can also create repeated token waste.

Proposed Design

Implement /trust-above as gateway/adapter hard logic, not as model-interpreted natural language.

Desired behavior

  • Default in public/shared threads: prior messages from untrusted / non-allowed users are masked when imported.
  • An allowed user may explicitly issue /trust-above.
  • That command elevates prior content above the command into trusted context for future turns.
  • Trust changes should update persisted transcript state so subsequent turns load the new effective history.

Recommended architecture

  1. Sidecar raw thread-context store
    • Preserve raw imported thread messages outside transcript.
  2. Rendered/effective transcript view
    • Transcript should contain only the model-visible version.
    • By default, untrusted content is masked.
  3. Gateway command path for /trust-above
    • Validate sender via normal authorization logic.
    • Update trust state (trusted_cutoff_ts, trusted message IDs, etc.).
    • Re-render thread context block from raw store.
    • Rewrite transcript so future turns see the trusted/unmasked version.

Why transcript rewrite matters

Gateway currently reloads transcript history on each new turn and passes it back into run_conversation(...), so changing trust state only in memory is not sufficient for future turns.

Code locations touched (relative paths + line numbers)

Authorization / ingress

  • gateway/run.py:3340
    • _is_user_authorized(self, source: SessionSource) -> bool
  • gateway/run.py:3613-3616
    • unauthorized shared/group messages are silently ignored; DM may enter pairing flow

Slack thread bootstrap

  • gateway/platforms/slack.py:1623-1635
    • first entry into a thread (_has_active_session_for_thread(...) is false) triggers _fetch_thread_context(...)
  • gateway/platforms/slack.py:2029-2045
    • _fetch_thread_context(...) definition and comments; only called when there is NO active session for the thread
  • gateway/platforms/slack.py:2061-2063
    • client.conversations_replies(...) fetch of prior thread messages
  • gateway/platforms/slack.py:1949-1952
    • SLACK_ALLOWED_USERS check in button/approval-click path

Transcript reload / replay

  • gateway/run.py:4723-4724
    • history = self.session_store.load_transcript(session_entry.session_id)
  • gateway/run.py:5120-5129
    • _run_agent(... history=history, ...)
  • gateway/run.py:10709-10717
    • transcript history -> agent_history
  • gateway/run.py:10967
    • agent.run_conversation(_run_message, conversation_history=agent_history, task_id=session_id)

Transcript mutation hooks

  • gateway/session.py:1221
    • append_to_transcript(...)
  • gateway/session.py:1254-1264
    • rewrite_transcript(...)

Related precedent: channel-level gating on Discord

  • gateway/config.py:669-674
    • Discord allowed_channels
  • gateway/platforms/discord.py:3206-3209
    • actual DISCORD_ALLOWED_CHANNELS enforcement

Security properties targeted

  1. Non-allowed users still cannot directly invoke Hermes.
  2. Non-allowed users in public threads should not automatically inject raw text into bootstrap context.
  3. Only an allowed user can elevate prior thread content into trusted model-visible history.
  4. Trust decisions are enforced by gateway code, not delegated to model reasoning.

Open questions

  • Best storage location for raw thread-context sidecar?
  • Minimal trust granularity: all-above cutoff vs per-message trust marks?
  • Slack-only first, or generalize to Discord/Telegram shared contexts too?
  • What should masked placeholders preserve (author/timestamp/message ID) for debuggability?

Links

  • Downstream draft / implementation thread: asdigitos/hermes-agent#1

extent analysis

TL;DR

Implement a /trust-above mechanism as gateway/adapter hard logic to explicitly unmask prior thread messages above the command in public Slack threads.

Guidance

  • Introduce a sidecar raw thread-context store to preserve imported thread messages outside the transcript.
  • Create a rendered/effective transcript view that contains only the model-visible version, masking untrusted content by default.
  • Develop a gateway command path for /trust-above that validates the sender, updates trust state, and re-renders the thread context block.
  • Update the transcript to reflect the new trust state, ensuring future turns see the trusted/unmasked version.

Example

# Simplified example of trust state update and transcript rewrite
def update_trust_state(session_id, trusted_cutoff_ts, trusted_message_ids):
    # Update trust state in database or storage
    session_store.update_trust_state(session_id, trusted_cutoff_ts, trusted_message_ids)

def rewrite_transcript(session_id, trusted_message_ids):
    # Load raw thread context from sidecar store
    raw_context = load_raw_thread_context(session_id)
    
    # Filter out untrusted messages
    trusted_context = [message for message in raw_context if message['id'] in trusted_message_ids]
    
    # Update transcript with trusted context
    session_store.rewrite_transcript(session_id, trusted_context)

Notes

The implementation details, such as storage location for raw thread-context sidecar and minimal trust granularity, are still open questions. This solution focuses on the high-level design and architecture.

Recommendation

Apply the proposed design and architecture to implement the /trust-above mechanism, as it addresses the security properties targeted and provides a clear solution to the problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING