fix(gateway): make Discord/Telegram allow/deny gates per-profile under multiplex

[teknium1]

Summary

Under gateway.multiplex_profiles, Discord/Telegram authorization gates read process-global env populated first-writer-wins — profile A's allow/deny lists and allow-all flags governed profile B. All gate reads are now per-adapter-instance.

Changes

• gateway/authz_mixin.py: new _platform_gate_env — under multiplex with a profile scope installed, a scope miss returns the default instead of falling through to another profile's env value; single-profile behavior identical.
• Discord adapter: connect() snapshots all 11 gate env vars per-adapter in the owning profile's scope; accessors (snapshot → config.extra → scoped env) replace every raw os.getenv gate read (message, slash, component, fail-closed, backfill, allow-bots); YAML loads seed PlatformConfig.extra and skip env writes under multiplex; removed the unguarded runtime DISCORD_ALLOWED_USERS env clobber (multiplex only).
• Telegram adapter: same class fixed — intake prefilter, callback-auth fallbacks, chat/topic/thread getters now scope-aware; YAML→env bridge skipped for profile-scoped loads.

Deferred (non-security, listed for follow-up)

Non-auth Discord env bridges (auto_thread, reactions, history_backfill, require_mention, reply_to_mode); Slack/Signal/WhatsApp sibling bridges; gateway _auth_env tightening (already scope-preferring via #65629/#65700).

Validation

21 new order-independent regression tests (two-adapter own-list enforcement, negative allow-all isolation, slash-gate isolation, env-clobber, bridge skip/seed matrix, Telegram scoped-reader matrix); sabotage-verified both platforms; ~1,100 related gateway tests pass (4 pre-existing flakes reproduce on clean main); ruff clean.

Credits: direction from #72427 (@JonthanaHanh), @yournetworkplug-ctrl's live-verified Telegram approach, thread analysis by @jackjin1997 / @cal88.

Fixes #72348

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on f35cca3}

ℹ️ Info

Desktop E2E visual evidence · View test artifacts · View job

2 visual diffs.

_{inline evidence upload failed.}

Failed to upload diff-1508682a2ae8-boot-ready-diff.png with gh image (exit code 1): Error uploading /home/runner/work/_temp/e2e-evidence/diff-1508682a2ae8-boot-ready-diff.png: step 0 (get upload token): uploadToken not found on repo page — do you have write access to NousResearch/hermes-agent? (or, if NousResearch enforces SAML SSO, authorize at https://github.com/orgs/NousResearch/sso)

[egilewski]

suggesting changes

The adapter-local Discord/Telegram gates are substantially improved, but the gateway's authoritative authorization decision still reads the process-global first-profile allowlist. A focused two-profile probe reproduces the same cross-profile authorization failure on both current main and the PR head: profile B authorizes profile A's user and rejects its own configured user. Because this remaining path is the final inbound gateway gate before agent execution, the PR does not yet close the reported security boundary.

• [P1] Gateway authorization still consumes another profile's allowlist (gateway/authz_mixin.py:601)
  Under multiplex, profile B's secret scope can legitimately omit DISCORD_ALLOWED_USERS because its allow_from is in config.yaml, while process-global os.environ still contains profile A's first-writer-bridged value. _is_user_authorized calls _auth_env here; _auth_env falls through to os.getenv on a scoped miss, so the nonempty profile-A value prevents the later adapter.config.extra fallback. In the validated case, B's configured user 222 was denied while A's user 111 was authorized against B's bot. That crosses the profile authorization boundary and can dispatch an attacker-controlled prompt into the wrong profile's agent/tool context.
  Remediation: Make authorization gate reads authoritative on a multiplex secret-scope miss (including platform/group/global allowlists and allow-all/bot/chat early gates), then fall through to the selected live adapter's config.extra for YAML policy. Add an end-to-end GatewayAuthorizationMixin regression with two profile adapters asserting both A-on-B denial and B-on-B authorization.

Security evidence:

• trust boundary: Untrusted Discord/Telegram sender and chat identifiers enter a platform adapter, pass adapter-local gates, and then reach GatewayAuthorizationMixin._is_user_authorized before an event may invoke the profile's agent and tools. Under multiplex, each adapter, config.yaml, .env secret scope, pairing store, and resulting agent context must remain bound to one profile; process-global os.environ is outside that per-profile boundary.
• source/sink/invariant: Sources are sender ID, chat ID/type, role/bot metadata, profile-stamped SessionSource, profile config.extra, scoped .env values, and legacy process env bridges. The security sink is returning True from _is_user_authorized, which permits agent dispatch. The claimed invariant is that only the selected profile's allow/deny policy may authorize that sink. _platform_gate_env and per-adapter snapshots validate scoped misses correctly, but the central sink still uses _auth_env/raw os.getenv and violates the invariant.
• current-main reproduction: A focused probe dynamically loaded gateway/authz_mixin.py from bound current main 40e0e7a. With multiplex active, an empty profile-B secret scope, process env DISCORD_ALLOWED_USERS=111 (profile A), and B's live adapter config.extra.allow_from=[222], _is_user_authorized returned True for user 111 and False for user 222. This reproduces the reported first-writer cross-profile failure on current main.
• PR-head or patch-replay validation: The same probe against checked-out PR head f35cca3 returned the identical pair: True for profile A's user on profile B and False for B's own configured user. A three-way git merge-tree of base d109138, current main, and PR head reported merged entries without conflict for the changed files, so the head behavior is coherently applicable to current main.
• positive/negative cases: Negative case: profile B must reject user 111, who exists only in profile A's process-env allowlist; observed result was True. Positive case: profile B must accept user 222 from B's config.extra.allow_from; observed result was False because the leaked nonempty env allowlist bypassed the adapter-extra fallback. PR tests cover adapter snapshots, allow-all isolation, YAML seeding, and Telegram scoped reads, but do not exercise this final GatewayAuthorizationMixin decision.
• residual bypass search: Searched both modified adapters and gateway code for raw DISCORD_, TELEGRAM_, and GATEWAY_* os.getenv reads and traced _auth_env callers. Residual central reads occur in _is_user_authorized for platform allowlists, group allowlists, global allowlists, allow-all, early group-chat authorization, and bot authorization; _get_unauthorized_dm_behavior also retains raw gate reads. The source-backed blocker is the directly reproduced platform-allowlist path at line 601; the adjacent reads should be converted and regression-tested as the same bug class.
• reviewer validation: Inspected the complete production diff, profile runtime-scope construction, config shared-key bridging, adapter selection, authorization callback construction, and new tests. Ran the two-SHA behavioral probe successfully and compiled all changed Python/test files successfully. The focused pytest invocation could not run because the leased checkout's available Python has no pytest module; no network or dependency installation was attempted.

Uncertainty: The leased environment lacks pytest, so the repository's focused unit tests were not executed.; No live Discord or Telegram network session was exercised; validation used the real local authorization code with deterministic profile and sender inputs.

Signed: GPT-5.6-sol-xhigh in Codex