Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: sessions_send bypasses agentToAgent.allowAgents — no cross-agent validation [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63351•Fetched 2026-04-09 07:54:56
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
macbenouzemacbenouze
Participants
macbenouzemacbenouze

Error Message

When agent A calls sessions_send targeting a session owned by agent B, the gateway should verify that B is listed in A's allowAgents array. If not, the call should fail with an error (e.g., "agent B is not in allowAgents for agent A"). 3. The message is delivered to wattson's session — no error, no warning.

Root Cause

In practice, we observed agent vox (Gemini 3 Pro) spontaneously sending sessions_send to wattson because the bug reports concerned Wattson (the product) — the model "inferred" Wattson (the agent) was the right target, despite its prompt listing only Sensei/Maestro/Vigil as valid targets.

Fix Action

Workaround

Added an explicit blocklist in the agent's prompt (AGENTS.md). This is best-effort only — relies on model compliance.

Code Example

sessions_send({
     "sessionKey": "agent:wattson:telegram:direct:<chat_id>",
     "message": "test message",
     "timeoutSeconds": 0
   })
RAW_BUFFERClick to expand / collapse

Bug description

sessions_send does not enforce the agentToAgent.allowAgents restriction configured per-agent in openclaw.json. Any agent can send messages to any other agent's session if it knows (or guesses) the target sessionKey, regardless of allowAgents.

Expected behavior

When agent A calls sessions_send targeting a session owned by agent B, the gateway should verify that B is listed in A's allowAgents array. If not, the call should fail with an error (e.g., "agent B is not in allowAgents for agent A").

Actual behavior

The message is delivered without any validation. The allowAgents configuration is effectively ignored for sessions_send.

Steps to reproduce

  1. Configure two agents in openclaw.json:
    • Agent vox with allowAgents: ["sensei", "maestro", "vigil"] (no wattson)
    • Agent wattson with allowAgents: ["darwin", "gutenberg", "sensei", "spielberg"] (no vox)
  2. From a vox session, call: 
    sessions_send({
  "sessionKey": "agent:wattson:telegram:direct:<chat_id>",
  "message": "test message",
  "timeoutSeconds": 0
})
  3. The message is delivered to wattson's session — no error, no warning.

Impact

This undermines the agent silo architecture. In our setup, agents are organized in two teams (coaching / SaaS) with only orchestrator-to-orchestrator cross-team bridges. Without gateway enforcement, any agent can bypass the intended communication topology by guessing a sessionKey.

In practice, we observed agent vox (Gemini 3 Pro) spontaneously sending sessions_send to wattson because the bug reports concerned Wattson (the product) — the model "inferred" Wattson (the agent) was the right target, despite its prompt listing only Sensei/Maestro/Vigil as valid targets.

Workaround

Added an explicit blocklist in the agent's prompt (AGENTS.md). This is best-effort only — relies on model compliance.

Environment

  • OpenClaw version: 2026.4.5
  • OS: macOS
  • 13 agents configured with per-agent allowAgents
  • Global agentToAgent.enabled: true

extent analysis

TL;DR

The sessions_send method should be updated to enforce the agentToAgent.allowAgents restriction by verifying the target agent is in the sender's allowAgents array before delivering the message.

Guidance

  • Review the sessions_send implementation to ensure it checks the allowAgents configuration for the sending agent before sending the message to the target session.
  • Modify the sessions_send method to throw an error if the target agent is not in the sender's allowAgents array, as described in the expected behavior.
  • Consider adding logging or monitoring to detect and alert on potential bypass attempts, where an agent tries to send a message to another agent not in its allowAgents list.
  • Evaluate the effectiveness of the current workaround using an explicit blocklist in the agent's prompt and consider replacing it with a more robust solution once the sessions_send method is updated.

Example

// Pseudo-code example of the updated sessions_send method
function sessions_send(sessionKey, message, timeoutSeconds) {
  const senderAgent = getSenderAgent();
  const targetAgent = getSessionOwner(sessionKey);
  if (!senderAgent.allowAgents.includes(targetAgent)) {
    throw new Error(`Agent ${targetAgent} is not in allowAgents for agent ${senderAgent}`);
  }
  // Deliver the message to the target session
}

Notes

The provided workaround using an explicit blocklist in the agent's prompt relies on model compliance and may not be foolproof. A more robust solution would be to update the sessions_send method to enforce the agentToAgent.allowAgents restriction.

Recommendation

Apply a workaround by modifying the sessions_send method to enforce the agentToAgent.allowAgents restriction, as this will provide a more robust solution than relying on the current blocklist workaround.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When agent A calls sessions_send targeting a session owned by agent B, the gateway should verify that B is listed in A's allowAgents array. If not, the call should fail with an error (e.g., "agent B is not in allowAgents for agent A").

#permission error#memory optimization#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING