Multi-Agent Communication

• Outcome: Review
• Latest audit: Sep 16, 2026 · 7:50 AM UTC
• Version: 1.0.0

Overview

This skill is coherent multi-agent orchestration documentation, but it promotes invisible child-agent work and an all-agents communication setting that should be reviewed before use.

Review this skill carefully before installing. Use explicit agent allowlists instead of wildcard cross-agent access, avoid invisible background agents for sensitive work unless the user has approved it, and ensure spawned agents have tight workspace, attachment, timeout, and audit controls.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/config.md:22

Finding

Wildcard Policy Permits Unrestricted Cross-Agent Communication

Content

View full analysis

Vulnerability Details

File Location: references/config.md, lines 22-27
Vulnerability Type: Unrestricted cross-Agent access control
Risk Level: Medium

Vulnerable Code:

json5

agentToAgent: {
  enabled: true,
  allow: ["*"],              // Allow all cross-Agent communication
  maxPingPongTurns: 5        // A2A negotiation capped at 5 rounds
}

Technical Analysis

The documented basic configuration enables Agent-to-Agent communication and uses the wildcard value ["*"] for the authorization policy. This violates least-privilege principles because every available Agent is permitted to communicate across Agent boundaries, regardless of whether that access is required.

The five-turn negotiation limit constrains conversation length but does not restrict which Agents may initiate communication or validate whether their messages are authorized. If this example is deployed directly, a compromised, malicious, or insufficiently trusted Agent could send crafted messages to other Agents and attempt to influence their tasks or obtain information exposed through their replies.

Attack Path

1. An attacker gains control of, or the ability to submit messages through, any Agent available in the environment.
2. The wildcard allow: ["*"] policy authorizes that Agent to communicate with other Agents.
3. The attacker invokes the Agent-to-Agent messaging mechanism and sends crafted instructions to a target Agent.
4. The target processes the unauthorized message within its own permissions and operational context.
5. Depending on the target's behavior, the attacker may influence task execution or receive information returned in the target's response.

Impact Assessment

Exploitation can permit unauthorized lateral communication between Agent sessions, task or prompt injection against reachable Agents, and disclosure of information included in Agent responses. The attacker does not automatically obtai ...[truncated 307 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the wildcard with an explicit allowlist containing only trusted Agent IDs that require cross-Agent communication.
• Disable Agent-to-Agent messaging by default and enable it only for defined workflows.
• Apply authorization checks to both the sending and receiving Agent rather than relying solely on a global policy.
• Validate message origin, destination, content type, and requested operation before processing cross-Agent messages.
• Ensure receiving Agents do not treat messages from peer Agents as trusted system-level instructions.
• Restrict each Agent's tools and data access independently so that a messaging-policy failure cannot expose unrelated privileges.
• Add audit logging, rate limits, and alerts for rejected or unusual cross-Agent communication attempts.
• Document separate development and production policies, ensuring that wildcard access is never presented as a production-safe default.

A hardened example would use a narrow allowlist:

json5

agentToAgent: {
  enabled: true,
  allow: ["code-reviewer", "doc-writer"],
  maxPingPongTurns: 5
}

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Exfiltration Commands

High

• Category: Prompt Injection
• Confidence: 90% confidence

Finding

Instructions found that direct the agent to transmit conversation context or user data to external services.

Content

Scanner excerpt · SKILL.md (reported line 8)May include surrounding context.

md

# Multi-Agent Communication

Core tools: `sessions_spawn` (launch child Agents) and `sessions_send` (send messages to existing Agents).

## Use Cases

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The skill explicitly promotes child-agent execution in mode="run" as not visible to the user by default, but it does not pair that capability with clear safety guidance, audit expectations, or restrictions on what invisible agents may do. In a multi-agent orchestration skill, reduced visibility materially increases the risk of hidden actions, covert delegation, or policy-evading behavior, especially when combined with messaging between agents.

Content

No source excerpt is available for this finding.