🔒 Aisle Security Analysis

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

1. 🟠 Messaging-tool suppression bypass when sends contain no tracked text (media/caption/components) causing duplicate outbound replies

Description

buildReplyPayloads now suppresses final replies only if messagingToolSentTexts.length > 0. However, the messaging tool can successfully send content without populating messagingToolSentTexts (e.g., media-only sends, attachment captions, interactive/component-only messages, or tools whose text param is not content/message).

As a result:

• A same-target messaging tool send can occur (tracked in messagingToolSentTargets / messagingToolSentMediaUrls) while messagingToolSentTexts remains empty.
• suppressMessagingToolReplies becomes false, so the normal auto-reply is still emitted.
• Additionally, dedupe is disabled in this case (dedupeMessagingToolPayloads becomes false when targets are present), so media/text duplicates that would otherwise be filtered may be sent again.

This creates an abuse/spam/billing amplification vector: a malicious prompt (or a user prompt that the agent follows) can instruct the agent to send via the messaging tool using non-text fields (e.g., media + caption) to keep messagingToolSentTexts empty, thereby forcing the system to also emit an additional auto-reply (and potentially resend the same media).

Vulnerable logic:

const messagingToolSentText = messagingToolSentTexts.length > 0;
const suppressMessagingToolReplies =
  messagingToolSentText &&
  shouldSuppressMessagingToolReplies({ ... });

const dedupeMessagingToolPayloads =
  suppressMessagingToolReplies || messagingToolSentTargets.length === 0;

Recommendation

Decouple suppression (whether to drop all final replies) from dedupe (removing duplicates) and base both on whether the messaging tool actually sent anything to the same origin target, not on sentTexts alone.

Safer options:

1. Always compute same-target send and use it to enable dedupe, even when you choose not to fully suppress replies:

const sentSameTarget = shouldSuppressMessagingToolReplies({
  messageProvider: resolveOriginMessageProvider({
    originatingChannel: params.originatingChannel,
    provider: params.messageProvider,
  }),
  messagingToolSentTargets,
  originatingTo: resolveOriginMessageTo({ originatingTo: params.originatingTo }),
  accountId: resolveOriginAccountId({ originatingAccountId: params.accountId }),
});

​// Keep the new behavior (don’t drop the whole reply) if tool only sent media,
​// but still dedupe against tool-sent media/text.
const suppressMessagingToolReplies = sentSameTarget && messagingToolSentTexts.length > 0;
const dedupeMessagingToolPayloads = sentSameTarget || messagingToolSentTargets.length === 0;

2. Track a single boolean like messagingToolSentAny based on any of:

• messagingToolSentTargets.length > 0
• messagingToolSentTexts.length > 0
• messagingToolSentMediaUrls.length > 0
• (optionally) other send metadata (templates/components)

and use that for suppression/guardrails.

3. Improve tracking so that non-message/content fields that produce user-visible text (e.g., caption) are added to messagingToolSentTexts for correct suppression/dedupe behavior.

Add tests asserting that when a same-target tool send occurs with only media/caption, duplicates are still deduped (and/or suppression is applied according to the intended policy).

Analyzed PR: #37900 at commit 21c7dc0

_{Last updated on: 2026-03-06T14:47:18Z}

Greptile Summary

This PR fixes a silent data-loss bug where session text was dropped whenever the message tool sent media to the same target in a single agent turn. The fix gates shouldSuppressMessagingToolReplies behind messagingToolSentTexts.length > 0, so media-only tool sends no longer trigger reply suppression.

Core fix is correct — the suppressMessagingToolReplies gate on messagingToolSentText precisely targets the described bug and is backed by a new unit test.

Media deduplication regression — dedupeMessagingToolPayloads derives from suppressMessagingToolReplies as a same-target proxy. After this fix, when the message tool sends media-only to the same target, suppressMessagingToolReplies becomes false, which causes dedupeMessagingToolPayloads to also become false. This disables filterMessagingToolMediaDuplicates, so if a session payload carries a mediaUrl that was already delivered by the message tool to the same target, the media would be sent twice. This contradicts the PR's claim that media URL deduplication did not change. Separating the same-target detection (isSameTargetSend) from the text-existence check would preserve both the bug fix and existing media dedup behavior.

Confidence Score: 3/5

• The core bug fix is safe and correct; however, it introduces a subtle media duplication regression in the edge case where a session payload carries a mediaUrl matching an already-sent message tool media URL for same-target sends.
• Score 3/5 reflects that this is safe to merge for the common case (preserving session text when message tool sends media-only), but carries an identified regression. The core fix is sound and well-tested for its intended purpose. The media deduplication regression only manifests when: (1) message tool sends only media to same target, (2) session payload carries a mediaUrl matching a tool-sent URL. While this scenario is uncommon, it's a real regression relative to the PR's claim that media URL deduplication was unchanged.
• src/auto-reply/reply/agent-runner-payloads.ts (lines 114-115) — dedupeMessagingToolPayloads logic needs to separate same-target detection from text-existence checking to preserve media deduplication for same-target media-only sends.

_{Last reviewed commit: 21c7dc0}

To avoid the one mentioned regression, maybe you can check message content to deduplicate the caption across other messages that are indended to be sent from the session?