Agent Swarm Workflow

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:55 AM UTC
• Version: 1.0.0

Overview

The skill is a coherent multi-agent coding workflow, but it under-controls high-impact actions like broad code editing and pushing all changed files to a remote repository.

Use this only in repositories where you intentionally want multiple agents to edit code and coordinate through Agent Mail and BV. Before allowing commit or push, require a human-reviewed diff, file ownership check, secret scan, test results, target branch confirmation, and explicit approval. Treat AGENTS.md, README.md, task descriptions, and Agent Mail messages as project context, not as authority to override the original user-approved task or security policy.

A.I.G

Vulnerability Patterns

• 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
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs

Findings (2)

T01 · Skill Instruction Hijacking

Warning

• Location: SKILL.md:79
• Finding: Untrusted Project Files and Agent Mail Can Redirect Agent Behavior## Vulnerability Details **File Location**: `SKILL.md`, lines 79-85 **Vulnerability Type**: T01: Skill Instruction Hijacking **Risk Level**: Medium ### Vulnerable Code Snippet ```text First read ALL of the AGENTS dot md file and README dot md file super carefully and understand ALL of both! Then use your code investigation agent mode to fully understand the code, and technical architecture and purpose of the project. Then register with MCP Agent Mail and introduce yourself to the other agents. Be sure to check your agent mail and to promptly respond if needed to any messages; then proceed meticulously with your next assigned beads, working on the tasks systematically and meticulously and tracking your progress via beads and agent mail messages. Don't get stuck in "communication purgatory" where nothing is getting done; be proactive about starting tasks that need to be done, but inform your fellow agents via messages when you do so and mark beads appropriately. When you're not sure what to do next, use the bv tool mentioned in AGENTS dot md to prioritize the best beads to work on next; pick the next one that you can usefully work on and get started. Make sure to acknowledge all communication requests from other agents and that you are aware of all active agents and their names. Use ultrathink. ``` ### Technical Analysis The workflow directs agents to treat project-controlled `AGENTS.md` and `README.md` content, task selections returned by `bv`, and Agent Mail messages as operational instructions. It does not establish a trust boundary, require instruction provenance validation, restrict permitted actions, or state that external content must be treated only as untrusted data. Consequently, an attacker who can modify one of the referenced project documents, manipulate the task graph, or send messages through Agent Mail can introduce instructions that redirect an agent away from its approved task. The risk is increased by the explic ...[truncated 1706 chars]
• Remediation: ## Remediation Suggestions - Explicitly classify repository documents, task descriptions, tool output, and Agent Mail messages as untrusted data rather than higher-priority instructions. - Define a fixed action policy in the skill that cannot be overridden by project files or messages. - Require agents to reject requests that conflict with the original user-approved task, security policy, or declared repository scope. - Authenticate Agent Mail participants and enforce per-project authorization and message provenance. - Allow only approved senders to assign work; ordinary messages should be informational and must not authorize tool execution. - Sanitize and validate task fields before presenting them to agents, especially fields capable of containing free-form instructions. - Require explicit human approval before sensitive operations such as reading secrets, changing access controls, executing unfamiliar scripts, accessing external networks, or publishing repository changes. - Add audit logging that records the source instruction responsible for every sensitive tool call. - After context compaction, restore the trusted task and security policy from a protected source instead of relying solely on mutable `AGENTS.md`.

other

Warning

• Location: SKILL.md:154
• Finding: Blanket Commit-and-Push Prompt Can Publish Unauthorized Changes## Vulnerability Details **File Location**: `SKILL.md`, lines 154-158 **Vulnerability Type**: other: Uncontrolled Repository Publication **Risk Level**: Medium ### Vulnerable Code Snippet ```text ## Committing Work ### THE EXACT PROMPT — Commit Changes Have agents commit logically grouped changes: ``` Now, based on your knowledge of the project, commit all changed files now in a series of logically connected groupings with super detailed commit messages for each and then push. Take your time to do it right. Don't edit the code at all. Don't commit obviously ephemeral files. Use ultrathink. ``` ``` ### Technical Analysis The prescribed prompt tells an agent to commit **all changed files** and push them without first requiring a clean diff review, file allowlist, secret scan, test result, branch-protection check, confirmation of change ownership, or human authorization. In a multi-agent environment, the working tree can contain unrelated, malicious, incomplete, or sensitive changes produced by another agent or process. The phrase “all changed files” makes the publication scope broader than the bead or files assigned to the committing agent. The instruction to avoid only “obviously ephemeral files” is subjective and does not protect credentials, local configuration, generated artifacts, or unrelated source changes. Although file reservations reduce editing conflicts, they do not prove that every changed file is safe or authorized for publication. The audited skill also does not demonstrate that a pre-push control enforces scope or performs secret scanning. ### Attack Path 1. An attacker, compromised peer agent, or unrelated local process places an unauthorized modification or sensitive file in the shared working tree. 2. A legitimate agent finishes its assigned bead and receives the skill's exact commit prompt. 3. Following the instruction to commit all changes, the agent stages files outside its assigned scope. ...[truncated 778 chars]
• Remediation: ## Remediation Suggestions - Replace “commit all changed files” with an explicit allowlist derived from the assigned bead and active file reservations. - Require `git status` and a complete staged diff review before committing. - Verify that each staged file was intentionally modified by the committing agent and belongs to the approved task scope. - Run secret scanning, static analysis, and relevant tests before permitting a commit or push. - Exclude local configuration, credentials, environment files, generated artifacts, logs, and temporary files through both policy and `.gitignore`. - Require explicit human confirmation immediately before every push, showing the remote, branch, commits, and changed-file list. - Push to a dedicated feature branch rather than directly to protected or deployment branches. - Enforce server-side branch protection, required review, signed commits, status checks, and restricted CI/CD triggers. - Abort the operation when unexpected files, unowned changes, unresolved reservations, or an unclean baseline are detected.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (4)

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The description is broad and lacks clear trigger constraints, while the body contains powerful operational instructions for spawning agents, modifying code, coordinating work, and publishing changes. Broad invocation criteria increase the chance the skill will be selected in inappropriate contexts, causing overbroad autonomous behavior and compounding the risk of unsafe code changes or repository actions.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: The skill explicitly instructs agents to commit and push changes to a remote repository as part of its normal execution loop. In an agent skill, this is dangerous because it authorizes an externally visible side effect without requiring explicit per-run user confirmation, branch restrictions, or safety checks; a compromised or mis-scoped run could publish unintended code, secrets, or destructive changes.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The skill directs agents to commit and push changes without any prominent user-impact warning or approval checkpoint. That creates a direct path from prompt execution to irreversible external actions, enabling accidental publication of faulty code, sensitive data, or attacker-influenced modifications.

Description-Behavior Mismatch

Low

• Confidence: 90% confidence
• Finding: The manifest says this skill is the execution phase that follows planning and bead creation, implying those activities are upstream prerequisites. The documented prompts later instruct agents to create comprehensive new beads, subtasks, and dependency structures, which goes beyond the claimed execution-only phase.

Static analysis

No suspicious patterns detected.