fix(relay): authorize relay-delivered events by delivery, not source.platform

[benbarclay]

Infographic

Summary

A relay-connected hosted instance was silently dropping every message from a successfully-linked user. The /link succeeded, the connector delivered the inbound, but the instance's authz layer default-denied it:

WARNING gateway.run: Unauthorized user: 267171776755269633 (rewbs) on discord

This is a second-order bug in the #52190 upstream-authz fix. That fix added BasePlatformAdapter.authorization_is_upstream and an _is_user_authorized branch keyed off source.platform via _adapter_authorization_is_upstream(source.platform). The problem: a relay message inbound carries the underlying platform — source.platform == Platform.DISCORD (telegram/signal/…), not Platform.RELAY — because ws_transport._event_from_wire maps the connector's wire payload (platform="discord") straight onto SessionSource, which is what session-keying and egress need. But the relay adapter is registered only under Platform.RELAY, so adapters.get(Platform.DISCORD) misses, the trusted-upstream branch is skipped, and the user falls through to the env-allowlist default-deny.

The note in the log (on discord, not on relay) is the tell — the existing regression test passed only because it built the source with platform=Platform.RELAY, which the live wire path never produces for a message.

Fix

The authentic trust signal is how the event was delivered — over the per-instance-authenticated relay WebSocket — not which platform it underlies, and not whether some relay adapter happens to be registered (that would wrongly authorize a direct Discord event on a multiplexing gateway running both a direct Discord adapter and a relay adapter).

So:

1. gateway/session.py — add a wire-invisible SessionSource.delivered_via_upstream_relay: bool = False. Deliberately excluded from to_dict/from_dict so a peer can neither forge it across the wire nor have it restored from persistence.
2. gateway/relay/ws_transport.py — _event_from_wire stamps delivered_via_upstream_relay=True. This is the authentic injection point: it only runs for frames that arrived over the authenticated relay socket.
3. gateway/authz_mixin.py — _is_user_authorized authorizes on source.delivered_via_upstream_relay OR _adapter_authorization_is_upstream(source.platform). The marker is the primary signal for message inbounds; the adapter-flag check is retained for events whose source.platform is Platform.RELAY (the interaction-passthrough path).

This is delegation to a trusted upstream, not a fail-open: the marker is only set by the relay transport on the authenticated socket. A direct, network-exposed adapter leaves it False and its events unmarked, so the env-allowlist default-deny is unchanged.

Tests

tests/gateway/test_relay_upstream_authz.py — added cases that reproduce the live shape (each fails without the fix, except the fail-open guard which must stay green):

• test_relay_message_with_underlying_discord_platform_authorized — source.platform=DISCORD + relay-delivery marker → authorized (the staging bug, exactly).
• test_direct_discord_event_not_authorized_by_relay_presence — a direct Discord event (no marker) on a gateway with a relay adapter still default-denies (no fail-open leak).
• test_relay_delivery_marker_is_wire_invisible — marker absent from to_dict() and does not survive a from_dict round-trip (unforgeable).
• test_event_from_wire_sets_relay_delivery_marker — the transport stamps the marker on every event it rebuilds.

$ python -m pytest tests/gateway/test_relay_upstream_authz.py -q
10 passed

$ python -m pytest tests/gateway/ -q -k "relay or session or authz"
846 passed

Review note

Touches shared gateway/authz_mixin.py + gateway/session.py — this is a general-runtime authz path, not the relay-adapter solo lane, so it needs core review (@teknium1).

Reported via staging alpha test (instance hermes-agent-stg-telemetric-void-5140).

[github-actions]

🔎 Lint report: fix/relay-authz-underlying-platform vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 11266 on HEAD, 11263 on base (🆕 +3)

🆕 New issues (2):

Rule	Count
unresolved-attribute	2

First entries

run_agent.py:2989: [unresolved-attribute] unresolved-attribute: Object of type `Self@get_credits_spent_micros` has no attribute `_credits_session_start_micros`
tests/run_agent/test_credits_notices_toggle.py:76: [unresolved-attribute] unresolved-attribute: Unresolved attribute `_credits_session_start_micros` on type `AIAgent`

✅ Fixed issues (1):

Rule	Count
invalid-assignment	1

First entries

tests/run_agent/test_credits_notices_toggle.py:76: [invalid-assignment] invalid-assignment: Object of type `None` is not assignable to attribute `_credits_session_start_micros` of type `int`

Unchanged: 5941 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.