Skip to content

dmPolicy allowFrom / groupAllowFrom not filtering incoming messages — foreign users reach agents #91006

@producedbysavant

Description

@producedbysavant

Summary

channels.telegram.allowFrom and groupAllowFrom do not prevent messages from non-allowlisted users from reaching bound agents. The agent receives, processes, and attempts to reply to foreign users, wasting tokens and creating delivery failures.

Configuration

"channels": {
  "telegram": {
    "dmPolicy": "allowlist",
    "allowFrom": ["1144466778"],
    "groupPolicy": "allowlist",
    "groupAllowFrom": ["1144466778"],
    "groups": {
      "-1003956954389": {
        "requireMention": true,
        "groupPolicy": "allowlist"
      }
    }
  }
}

Observed Behavior

  1. User 1725321322 ("dj chuk+") sent a message — the orchestrator agent received it, processed it (spent ~$0.006 in DeepSeek tokens), and generated a full reply about Tarantino movies. Delivery failed with "chat not found" because the bot hasn't started a DM with this user.

  2. User 999598842 — same issue earlier, multiple delivery attempts (183+ failed entries in the queue), all failing with "chat not found".

Expected Behavior

Messages from users NOT in allowFrom / groupAllowFrom should be silently dropped before reaching any agent. No tokens should be spent, no responses generated, no delivery attempts made.

Log Evidence

session dfccdd63: deliveryContext.to = "1725321322"
agent processed foreign message, generated NO_REPLY response
multiple 400 Bad Request: chat not found for 1725321322
183+ failed delivery entries for 999598842

Impact

  • Token waste: every foreign message costs DeepSeek API tokens
  • Delivery queue pollution: failed deliveries accumulate and block reconnect drains
  • Session corruption: concurrent access to session files from foreign messages triggers EmbeddedAttemptSessionTakeoverError
  • Agent instructions to "never reply to non-owner" are model-dependent and unreliable

Related

Also observed: sub-agents (analyst) spawned via sessions_spawn lack read/write tools when using an explicit tools.allow list. The orchestrator's sub-agents inherit a restricted tool set that breaks file-based workflows. Workaround: manually add read, write, exec to the agent's tools.allow list.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions