Back to skill

Security audit

Advanced Collab Protocol

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent multi-agent handoff protocol, but it asks agents to access private session history and system configuration too broadly.

Review this skill carefully before installing in any environment where agents can access private histories, broad configuration files, or real messaging channels. It would be safer if context were passed through task-scoped summaries, identity lookup used a narrow API or sanitized mapping, and outbound routing fields were validated against trusted task metadata.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:64
Finding
Unrestricted Retrieval of Private Agent Session History<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 64-65 **Vulnerability Type**: Excessive access to private agent history **Risk Level**: High ### Vulnerable Code Snippet ```markdown ### 8. 🔍 Context Retrieval * If context is insufficient, proactively use the `sessions_history` tool to retrieve the upstream Agent's thought process or private chat history. ``` ### Technical Analysis The instruction directs an agent to retrieve an upstream agent's thought process or private chat history whenever it determines that context is insufficient. It does not require authorization from the affected user or upstream agent, limit retrieval to the current task, define which messages may be accessed, or require redaction of sensitive information. This violates least-privilege and data-minimization principles. Private session history can contain unrelated user conversations, system instructions, credentials, personal information, internal operational details, or other confidential material. The broad and subjective condition—“context is insufficient”—does not provide a meaningful access-control boundary. ### Attack Path 1. A downstream agent receives a task with incomplete or intentionally ambiguous context. 2. The downstream agent invokes the documented context-retrieval rule. 3. It calls `sessions_history` against an upstream agent's session. 4. The retrieved history includes private or unrelated information beyond what is necessary for the assigned task. 5. That information becomes available to the downstream agent and may subsequently be included in files, messages, summaries, or additional agent handoffs. ### Impact Assessment A downstream agent may obtain access to private upstream conversations and internal context outside the legitimate scope of the current task. The exposure scope depends on the access controls implemented by `sessions_history`, but it could include confidential prompts, user-provided information, operational metadata, ...[truncated 201 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the instruction to retrieve an agent's thought process or unrestricted private history. 2. Require the downstream agent to request a task-scoped summary from the upstream agent before using any history-retrieval capability. 3. Require explicit authorization from the affected user or upstream agent before accessing private session data. 4. Restrict retrieval to messages associated with the current task and session identifier. 5. Apply field-level filtering and redact credentials, personal data, system prompts, and unrelated conversation content. 6. Enforce authorization in the `sessions_history` tool itself rather than relying only on written instructions. 7. Record access in an audit log containing the requesting agent, authorized task, target session, fields accessed, and reason. 8. Return a minimal sanitized summary instead of raw private history whenever possible. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:54
Finding
System-Wide Configuration Read for Identity Resolution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 54-57 **Vulnerability Type**: Overbroad system configuration access **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ### 6. 🌐 Downstream Identity Discovery (Native Config Mapping) If an initiator *needs* to publicly `@` a downstream Agent in a group chat during a handover, but only knows its internal `agentId`: * **Read System Config**: The initiator MUST use the `read` tool to parse the `/root/.openclaw/openclaw.json` configuration file. * **Resolve Mapping**: Look inside the `routes` array. Find the object where `"agentId"` matches your target. Extract the corresponding `match.accountId` (this is the bot's unique platform username, e.g., `suPMAgent_bot`). Prefix it with `@` to use in group chats. * **Silent Handoff Fallback**: If the target agent is not found in the routes, do NOT attempt to guess the username or use generic mentions. Instead, omit the `@` mention in the public chat and rely entirely on `sessions_send` to wake the target up. ``` ### Technical Analysis The protocol requires an agent to read and parse the complete `/root/.openclaw/openclaw.json` system configuration merely to resolve one agent identifier. Reading an entire system-level configuration file for a narrow identity lookup violates least-privilege and data-minimization principles. Although the instruction only tells the agent to inspect the `routes` array and extract `match.accountId`, access is granted at file granularity. Consequently, the agent can observe all other information present in the configuration file, including unrelated routes and potentially sensitive operational settings. The protocol does not require a sanitized view, field-level access control, redaction, or authorization specific to the requested identity. ### Attack Path 1. An initiator claims that it needs the public username associated with a downstream `agentId`. 2. Following the Skill instructions, it reads `/root/.o ...[truncated 793 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace direct file access with a dedicated identity-resolution API that accepts an authorized `agentId` and returns only the corresponding public `accountId`. 2. If an API is unavailable, generate a sanitized mapping file containing only agent IDs and approved public usernames. 3. Restrict each agent to mappings required for its assigned task or collaboration group. 4. Enforce access control outside the prompt so agents cannot use the same read permission to inspect the full system configuration. 5. Redact secrets and unrelated settings from any configuration view exposed to agents. 6. Validate that the requesting agent is permitted to discover and contact the target account. 7. Audit identity-resolution requests, including the requester, target agent, task, and result. 8. Retain the silent-handoff fallback when an authorized mapping cannot be resolved. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:44
Finding
Unvalidated Routing Envelope Controls Outbound Cross-Channel Messages<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 44-52 **Vulnerability Type**: Untrusted routing data used as an outbound message destination **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ### 5. 🤫 Cross-Channel Wakeup & Payload Routing (Fixing Upstream Username Discovery) Because physically isolated agents (e.g., on Telegram) do not automatically know each other's platform usernames, you must explicitly pass this routing data downstream. * **Initiator Must Route**: When handing over a task to the next Agent using the `sessions_send` tool, your private message MUST begin with a Routing Envelope containing: ``` [ROUTING ENVELOPE] GroupId: <Current_Group_ID_or_Name> ReplyToUsername: <Your_Unique_Username> (or the Human's unique username if they need the direct reply) ``` * **Receiver Must Extract**: When receiving a task privately, extract the `GroupId` and `ReplyToUsername`. Proactively invoke the `message` tool (`action="send"`, `target="<Extracted_GroupId>"`) to broadcast your status to the group, explicitly mentioning the exact username provided (e.g., `[ACK] @<ReplyToUsername> Instructions received.`). ``` ### Technical Analysis The receiver is required to extract `GroupId` and `ReplyToUsername` directly from an inter-agent message and use those values to construct an outbound `message` tool call. The protocol provides no validation that the supplied group belongs to the current task, that the receiver is authorized to contact it, or that the username is associated with the purported sender. This creates a confused-deputy condition: an untrusted or compromised upstream agent can supply attacker-selected routing values, while the receiving agent contributes its own `message` permissions. The issue is an insecure routing design because authorization decisions are based on payload fields rather than trusted session or platform metadata. ### Attack Path 1. A malicious or compromised upstream agent sends a ...[truncated 1281 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not treat routing fields contained in agent-generated message text as authoritative. 2. Derive the source identity and destination group from trusted session or platform metadata. 3. Bind every handoff to a task identifier, sender identity, approved destination, and expiration time. 4. Validate `GroupId` against an allowlist of groups authorized for both the sender and receiver. 5. Verify that `ReplyToUsername` corresponds to the authenticated sender or an explicitly authorized human participant. 6. Reject malformed, unauthorized, expired, or mismatched routing envelopes. 7. Consider cryptographically signing routing envelopes if they must cross untrusted boundaries. 8. Require confirmation before sending to a destination different from the source task's established group. 9. Apply rate limits and maintain audit logs for cross-channel acknowledgments. 10. Ensure acknowledgment content contains no task-sensitive data unless disclosure to the validated destination is explicitly authorized. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (3)

Context-Inappropriate Capability

High
Confidence
96% confidence
Finding
The protocol explicitly authorizes retrieval of upstream agents' thought process or private chat history when context is insufficient, which exceeds normal handoff needs and can expose sensitive internal reasoning, secrets, or private user data. In a multi-agent environment, this creates an unnecessary lateral data access path that could leak information across tasks, users, or trust boundaries.

Ssd 3

High
Confidence
98% confidence
Finding
Directing agents to retrieve upstream private history via natural-language instructions creates a practical data-leakage channel, because agents may disclose or act on sensitive content that was never intended for the downstream recipient. The surrounding skill context makes this more dangerous because it is a collaboration protocol for multi-agent handoffs, so the instruction is likely to be repeatedly exercised across many interactions and channels.

Intent-Code Divergence

Medium
Confidence
91% confidence
Finding
The skill presents a least-privilege tool list but later instructs agents to use `sessions_history`, creating a mismatch between documented permissions and actual behavior. This can lead operators to grant additional access ad hoc or deploy the skill with unclear security expectations, increasing the chance of over-privileged access to prior conversations.

Static analysis

No suspicious patterns detected.