Greptile Summary

This PR fixes a bug where Slack inbound system events (reactions, member joins/leaves, pins, interactions, modals) were not routed through binding-aware agent session resolution, causing events to land in agent:main instead of the correct bound agent session in multi-account Slack setups.

The fix threads senderId through the call chain so that resolveSlackSystemEventSessionKey can delegate to resolveAgentRoute — the same routing path used for normal inbound messages — before falling back to the existing legacy resolveSessionKey when routing context is incomplete (e.g. unknown sender for a DM).

Key changes:

• resolveSlackSystemEventSessionKey in context.ts now attempts resolveAgentRoute first, with a robust fallback to legacy key derivation; for DMs, the peer is the sender's user ID; for channels/groups, the peer is the channel ID
• senderId is forwarded at all call sites: system-event-context.ts (reactions, pins, members), interactions.ts (button clicks), and interactions.modal.ts (view submissions/closures)
• New tests in monitor.test.ts cover account-binding routing for channel events and direct-peer binding routing for DM events; reactions.test.ts and interactions.test.ts are updated to assert the new senderId field is passed through

Confidence Score: 5/5

• Safe to merge — the change is backward compatible with a well-tested fallback path for edge cases.
• The logic is straightforward: try the new binding-aware route, fall back to the legacy path on failure or missing context. The implementation is consistent across all event types, the new code path is guarded by a non-empty peerId check and a catch block, and the author has added targeted unit tests covering binding-match and fallback scenarios. No authorization semantics were changed, no new network calls or permissions introduced, and all existing tests remain valid.
• No files require special attention.

_{Last reviewed commit: d8a7d9c}

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Slack DM system events can be misrouted by using message author/bot_id as senderId for session routing

Description

resolveSlackSystemEventSessionKey now routes DM ("im") system events via resolveAgentRoute() using senderId as the DM peer identifier.

For several system-event sources, senderId is not guaranteed to be the DM peer user:

• Message subtype system events (e.g., message_changed, message_deleted) derive senderId from the message author (message.user/previous_message.user) and fall back to bot_id.
• In a DM, when the bot updates its own message, Slack commonly emits message_changed where message.user is absent and message.bot_id is present.

As a result, DM system events can be routed to a session bound to the bot ID (or to an account/default binding) instead of the intended per-user DM session. In deployments using per-peer bindings to isolate agents (e.g., VIP/customer-specific agents), this can cause cross-session information disclosure (DM activity metadata appearing in the wrong agent/session) and session confusion.

Vulnerable routing logic:

const peerId = isDirectMessage ? senderId : channelId;
...
return route.sessionKey;

Example of non-peer senderId source (bot message edit/delete):

return changed.message?.bot_id ?? changed.previous_message?.bot_id;

Recommendation

For DMs, resolve the actual DM peer user ID from the channelId (via conversations.info) and use that as the routing peer, instead of senderId.

Suggested approach:

1. Extend resolveChannelName() (or add a new resolver) to also return the DM peer user ID when channel.is_im:

​// when conversations.info() returns an IM
const dmUser = (channel as any).user as string | undefined;

2. In resolveSlackSystemEventSessionKey, prefer that DM peer id:

const channelType = normalizeSlackChannelType(p.channelType, channelId);
if (channelType === "im") {
  const info = await resolveChannelInfo(channelId); // includes dmUser
  const dmPeerId = info.userId;
  const peerId = dmPeerId ?? undefined; // fallback handled below
  if (peerId) {
    return resolveAgentRoute({
      cfg: params.cfg,
      channel: "slack",
      accountId: params.accountId,
      teamId: params.teamId,
      peer: { kind: "direct", id: peerId },
    }).sessionKey;
  }
}

3. As a defense-in-depth fallback, if you keep senderId routing for DMs, only use it when it looks like a Slack user ID (e.g., /^[UW]/) and otherwise fall back to the legacy per-channel key to avoid collapsing multiple users into a bot-id-derived route.

Analyzed PR: #34045 at commit ee664d3

_{Last updated on: 2026-03-04T14:09:48Z}