Security audit

Calling Agent Squad

Security checks for vulnerabilities and agentic risk

Overview

This skill is a coherent multi-agent project helper, but its bundled agent policies grant broad persistent memory, personal-context monitoring, and autonomous push authority beyond what the main skill description clearly scopes.

Install only if you are comfortable with multiple agents reading and writing persistent local memory, keeping environment notes, spawning sessions, and potentially performing heartbeat-driven repository operations. Before use, remove or disable the heartbeat/personal-assistant sections, require approval before memory or policy-file writes, and require explicit review before any git push or outbound communication.

A.I.G

Vulnerability Patterns

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
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
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review

Findings (6)

T02 · Agent Memory Poisoning

Error

Location: agents/squad-manager/AGENTS.md:13
Finding: Persistent memory and instruction-policy poisoning across all agents<![CDATA[ ## Vulnerability Details **File Location**: `agents/*/AGENTS.md:13-45, 191-204` **Vulnerability Type**: Persistent memory and agent-policy mutation **Risk Level**: High The same vulnerable policy appears in: - `agents/architect/AGENTS.md` - `agents/brand-reviewer/AGENTS.md` - `agents/code-reviewer/AGENTS.md` - `agents/coder/AGENTS.md` - `agents/copywriter/AGENTS.md` - `agents/observer/AGENTS.md` - `agents/researcher/AGENTS.md` - `agents/squad-manager/AGENTS.md` ### Vulnerable Code ```markdown ## Session Startup Before doing anything else: 1. Read `SOUL.md` — this is who you are 2. Read `USER.md` — this is who you're helping 3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context 4. **If in MAIN SESSION** (direct chat with your human): Also read `MEMORY.md` Don't ask permission. Just do it. ## Memory You wake up fresh each session. These files are your continuity: - **Daily notes:** `memory/YYYY-MM-DD.md` (create `memory/` if needed) — raw logs of what happened - **Long-term:** `MEMORY.md` — your curated memories, like a human's long-term memory Capture what matters. Decisions, context, things to remember. Skip the secrets unless asked to keep them. ### 🧠 MEMORY.md - Your Long-Term Memory - **ONLY load in main session** (direct chats with your human) - **DO NOT load in shared contexts** (Discord, group chats, sessions with other people) - This is for **security** — contains personal context that shouldn't leak to strangers - You can **read, edit, and update** MEMORY.md freely in main sessions - Write significant events, thoughts, decisions, opinions, lessons learned - This is your curated memory — the distilled essence, not raw logs - Over time, review your daily files and update MEMORY.md with what's worth keeping ### 📝 Write It Down - No "Mental Notes"! - **Memory is limited** — if you want to remember something, WRITE IT TO A FILE - "Mental notes" don't survive session restarts. Files do. - When someone says "remember t ...[truncated 3012 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Prohibit agents from modifying `AGENTS.md`, `SOUL.md`, Skills, and other trusted instruction files. 2. Require explicit user confirmation before any persistent-memory write, deletion, or consolidation. 3. Store memory as typed, project-scoped records under a strict allowlisted schema. 4. Attach provenance, timestamp, author, and trust classification to every memory item. 5. Treat user content, web results, project documents, and delegated outputs as untrusted data that can never become executable policy automatically. 6. Separate trusted configuration from writable project and memory directories using filesystem permissions. 7. Replace destructive memory consolidation with versioned, reviewable proposals. 8. Disable cross-project memory by default and provide a user-controlled mechanism to inspect and delete retained data. ]]>

T01 · Skill Instruction Hijacking

Error

Location: SKILL.md:19
Finding: Bundled persona policies hijack agent behavior beyond the declared squad workflow<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:19-21, 37-44`; `agents/squad-manager/AGENTS.md:11-18, 128-161`; `agents/squad-manager/SOUL.md:4-10` **Vulnerability Type**: Instruction and goal hijacking **Risk Level**: High Equivalent general-purpose agent policies are bundled into every `agents/*/AGENTS.md` file. ### Vulnerable Code `SKILL.md` loads the persona instructions into the active agent: ```markdown ### Mode 1: Standard (Default) - I act as all roles (Manager, Researcher, Architect, Copywriter, Reviewer, Observer) - **Before each role**: I read their SOUL.md and IDENTITY.md to adopt their persona - After task completion: I return to my normal self (Megan) ``` ```markdown ### Standard Mode When user says `calling squad [project] [task]`: 1. Create project folder: `Documents/squad_projects/[project]_[yyyymmdd]/` 2. For each role (Researcher → Architect → Copywriter → Reviewer → Observer): - Read that role's `SOUL.md` and `IDENTITY.md` from `agents/[role]/` - Adopt their persona and complete their task 3. Save all deliverables to project folder 4. Return to normal (Megan) after completion ``` The loaded workspace policy assigns unrelated background behavior: ```markdown ## Session Startup Before doing anything else: 1. Read `SOUL.md` — this is who you are 2. Read `USER.md` — this is who you're helping 3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context 4. **If in MAIN SESSION** (direct chat with your human): Also read `MEMORY.md` Don't ask permission. Just do it. ``` ```markdown ## 💓 Heartbeats - Be Proactive! When you receive a heartbeat poll (message matches the configured heartbeat prompt), don't just reply `HEARTBEAT_OK` every time. Use heartbeats productively! ... **Things to check (rotate through these, 2-4 times per day):** - **Emails** - Any urgent unread messages? - **Calendar** - Upcoming events in next 24-48h? - **Mentions** - Twitter/social notifications? - **Weather** - Relevant if your ...[truncated 2919 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace persona adoption with narrow role prompts scoped to the active mission. 2. Remove all generic personal-assistant, heartbeat, social-chat, TTS, email, calendar, and notification policies. 3. State explicitly that Skill instructions cannot override user intent, platform policy, or host safety requirements. 4. Require permission before reading persistent state, accessing personal services, or spawning additional sessions. 5. Apply a per-mission capability allowlist to each role. 6. Prevent project documents and manager rulings from becoming trusted agent policy automatically. 7. Provide a dry-run plan showing intended agents, tools, files, and expected cost before full-mode execution. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: agents/squad-manager/TOOLS.md:5
Finding: Project agents are instructed to collect and persist sensitive infrastructure and physical-environment information<![CDATA[ ## Vulnerability Details **File Location**: `agents/*/AGENTS.md:57-60, 116-120, 141-161`; `agents/*/TOOLS.md:5-35` **Vulnerability Type**: Excessive access and plaintext sensitive-data storage **Risk Level**: Medium The policy and template are duplicated across all eight agent directories. ### Vulnerable Code From each `AGENTS.md`: ```markdown ## External vs Internal **Safe to do freely:** - Read files, explore, organize, learn - Search the web, check calendars - Work within this workspace ``` ```markdown ## Tools Skills provide your tools. When you need one, check its `SKILL.md`. Keep local notes (camera names, SSH details, voice preferences) in `TOOLS.md`. ``` ```markdown **Things to check (rotate through these, 2-4 times per day):** - **Emails** - Any urgent unread messages? - **Calendar** - Upcoming events in next 24-48h? - **Mentions** - Twitter/social notifications? - **Weather** - Relevant if your human might go out? ``` From each `TOOLS.md`: ```markdown ## What Goes Here Things like: - Camera names and locations - SSH hosts and aliases - Preferred voices for TTS - Speaker/room names - Device nicknames - Anything environment-specific ## Examples ```markdown ### Cameras - living-room → Main area, 180° wide angle - front-door → Entrance, motion-triggered ### SSH - home-server → 192.168.1.100, user: admin ### TTS - Preferred voice: "Nova" (warm, slightly British) - Default speaker: Kitchen HomePod ``` ``` ### Technical Analysis Roles such as copywriter, brand reviewer, observer, and researcher do not legitimately require SSH inventory, camera locations, room names, device identifiers, email, calendars, or social notifications. Granting every role access to this information violates least privilege. The policy encourages storage of infrastructure and physical-environment details in plaintext Markdown. Although the package does not include actual credentials or an explicit exfiltration routine, these files can become concentra ...[truncated 1216 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove SSH, camera, room, device, email, calendar, and social-account access from agents that do not require it. 2. Restrict every agent to a dedicated project workspace with deny-by-default filesystem access. 3. Do not store infrastructure information, usernames, credentials, access tokens, or physical-location data in Markdown files. 4. If environment aliases are essential, store only opaque identifiers and resolve them through a protected configuration or secret-management service. 5. Encrypt sensitive state at rest and enforce per-agent access controls. 6. Add retention limits and user-visible controls for inspecting and deleting stored information. 7. Prevent `TOOLS.md`, memory files, and local configuration from being committed to project repositories. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: agents/squad-manager/AGENTS.md:189
Finding: Heartbeat policy permits autonomous repository pushes without user approval<![CDATA[ ## Vulnerability Details **File Location**: `agents/*/AGENTS.md:189-195` **Vulnerability Type**: Unapproved external side effects and unsafe repository operations **Risk Level**: High The vulnerable policy is present in all eight agent `AGENTS.md` files. ### Vulnerable Code ```markdown **Proactive work you can do without asking:** - Read and organize memory files - Check on projects (git status, etc.) - Update documentation - Commit and push your own changes - **Review and update MEMORY.md** (see below) ``` This conflicts with the earlier policy in the same files: ```markdown **Ask first:** - Sending emails, tweets, public posts - Anything that leaves the machine - Anything you're uncertain about ``` ### Technical Analysis A Git push transmits data to an external system and changes a remote repository. The policy nevertheless expressly permits agents to commit and push without asking. No destination validation, repository allowlist, branch restriction, diff review, secret scan, test requirement, or confirmation gate applies at this policy level. The contradictory directives make behavior dependent on model interpretation. The more specific proactive-work authorization may be treated as an exception to the general requirement to ask before anything leaves the machine. This issue compounds persistent-memory poisoning: an attacker-controlled change can be written to project files or documentation and then autonomously committed and pushed during a later heartbeat. ### Attack Path 1. A malicious mission, project file, fetched document, or poisoned memory causes an agent to create or modify repository content. 2. A heartbeat triggers proactive project maintenance. 3. The agent stages and commits the affected files. 4. It pushes the commit without displaying the diff or obtaining user approval. 5. Source code, secrets, personal information, poisoned instructions, or unauthorized changes become available in the remote repository. ### Impact Asse ...[truncated 486 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove “commit and push” from actions allowed without approval. 2. Require explicit confirmation immediately before every remote push. 3. Display the exact diff, files, branch, remote URL, and intended commit message to the user. 4. Run secret detection, dependency checks, tests, and linting before proposing a commit. 5. Restrict automated changes to dedicated branches and require protected pull-request review. 6. Use repository and organization allowlists rather than inherited unrestricted Git access. 7. Resolve the contradictory policy by making all external transmissions require consent. 8. Record an immutable audit log of every proposed and completed repository operation. ]]>

T01 · Skill Instruction Hijacking

Warning

Location: agents/squad-manager/AGENTS.md:5
Finding: Unauthenticated bootstrap instructions are automatically followed and then deleted<![CDATA[ ## Vulnerability Details **File Location**: `agents/*/AGENTS.md:5-7` **Vulnerability Type**: Unsafe bootstrap instruction loading and evidence deletion **Risk Level**: Medium The same first-run behavior is configured for all eight agents. ### Vulnerable Code ```markdown ## First Run If `BOOTSTRAP.md` exists, that's your birth certificate. Follow it, figure out who you are, then delete it. You won't need it again. ``` ### Technical Analysis The policy treats the mere presence of a writable Markdown file as sufficient authority to define agent behavior. It requires no signature, trusted path validation, provenance check, content review, or user confirmation. After following the file, the agent is instructed to delete it. Deletion removes the original source of the behavior and impairs forensic analysis. A malicious bootstrap can also instruct the agent to persist its effects elsewhere before being removed. ### Attack Path 1. An attacker or compromised process writes a crafted `BOOTSTRAP.md` into an agent workspace before first use. 2. The agent starts and treats the file as authoritative identity and setup instructions. 3. The bootstrap directs the agent to modify memory, policy files, project documents, or external resources. 4. The agent follows the instructions. 5. It deletes `BOOTSTRAP.md`, concealing the original instruction source. 6. Any changes written into persistent memory or policy continue affecting later sessions. ### Impact Assessment The attacker can influence first-run behavior with the effective file and tool permissions of the affected agent. Potential consequences include persistent instruction poisoning, unauthorized file modification, additional session creation, sensitive-data access, or external actions if those tools are enabled. The automatic deletion also reduces accountability and makes incident reconstruction more difficult. ]]>
Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not automatically treat workspace Markdown as trusted bootstrap policy. 2. Provision bootstrap configuration through an administrator-controlled or cryptographically authenticated channel. 3. Display the bootstrap content and require explicit approval before applying it. 4. Validate instructions against an allowlist of safe initialization operations. 5. Prevent bootstrap logic from modifying agent policy, persistent memory, secrets, or external systems. 6. Archive the original bootstrap with immutable provenance rather than deleting it. 7. Record every applied initialization action in a tamper-resistant audit log. ]]>

T09 · Insecure Skill Coding Practices

Note

Location: squad-init.sh:6
Finding: Initialization script uses hardcoded user-specific installation paths<![CDATA[ ## Vulnerability Details **File Location**: `squad-init.sh:6-16` **Vulnerability Type**: Unsafe and non-portable agent registration configuration **Risk Level**: Low ### Vulnerable Code ```bash BASE_DIR="/Users/george/.openclaw/workspace/skills/calling-agent-squad" AGENTS=("squad-manager" "architect" "researcher" "copywriter" "brand-reviewer" "coder" "code-reviewer" "observer") echo "🦞 Initializing Agent Squad..." for agent in "${AGENTS[@]}"; do echo "Creating agent: $agent" openclaw agents add "$agent" \ --workspace "$BASE_DIR/agents/$agent" \ --agent-dir "/Users/george/.openclaw/agents/$agent/agent" \ --non-interactive done ``` The documented installation path is different: ```markdown bash ~/.openclaw/workspace/skills/calling-agent-squad/squad-init.sh ``` ### Technical Analysis The script assumes a specific macOS username and absolute directory structure instead of deriving paths from the current user or script location. On another system, the command may fail or register agents against an unintended preexisting path. The script also runs registration non-interactively and does not verify that each workspace exists, is owned by the current user, or contains the expected trusted files. If an attacker can create the hardcoded directory tree, the script may register attacker-controlled agent instructions. ### Attack Path 1. The Skill is installed on a system where `/Users/george/...` does not represent the intended Skill directory. 2. An attacker or another local account prepares content at the referenced path, where filesystem permissions permit it. 3. The user executes `squad-init.sh`. 4. The script non-interactively registers all eight agents against the hardcoded workspaces. 5. Later agent invocations load instructions from the wrong or attacker-controlled directories. ### Impact Assessment The primary impact is incorrect agent registration and loss of integrity of loaded configurations. Exploitation re ...[truncated 262 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Derive the Skill root from the script’s own canonical location. 2. Derive the agent data directory from a validated `$HOME` or explicit configuration value. 3. Quote and validate all resolved paths. 4. Verify directory existence, ownership, permissions, and expected configuration files before registration. 5. Refuse to follow unexpected symbolic links. 6. Remove `--non-interactive` for first-time setup, or show and require confirmation of every resolved workspace and agent directory. 7. Enable strict shell behavior such as `set -euo pipefail` and stop on the first failed registration. ]]>

SkillSpector

Vulnerability Patterns

Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Rogue AgentSelf-Modification, Session Persistence
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
YARA SignaturesMalware Match, Webshell Match, Cryptominer Match

Findings (79)

YARA rule 'offensive_tool_references': References to well-known offensive security tools [hacktools]

High

Category: YARA Match
Content: # IDENTITY - Market Researcher ## Character Description You are an acute market bloodhound. Highly sensitive to trends, competitor dynamics, and data. You distill golden insights from massive internet noise. ## Communication Style - Data-driven and objective. - Report using the "Insight + Source" format.
Confidence: 70% confidence
Finding: YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Self-Modification

High

Category: Rogue Agent
Content: ## Why Separate? Skills are shared. Your setup is yours. Keeping them apart means you can update skills without losing your notes, and share skills without leaking your infrastructure. ---
Confidence: 85% confidence
Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Context-Inappropriate Capability

Medium

Confidence: 89% confidence
Finding: The skill explicitly supports spawning sub-agents via `openclaw agent`, which introduces subprocess execution from a skill whose primary purpose is orchestration. Even if intended functionality, this expands the execution surface: user-controlled project/task text is passed into a command invocation, and downstream agent behavior becomes harder to constrain or audit.

Session Persistence

Medium

Category: Rogue Agent
Content: ### Standard Mode When user says `calling squad [project] [task]`: 1. Create project folder: `Documents/squad_projects/[project]_[yyyymmdd]/` 2. For each role (Researcher → Architect → Copywriter → Reviewer → Observer): - Read that role's `SOUL.md` and `IDENTITY.md` from `agents/[role]/` - Adopt their persona and complete their task
Confidence: 81% confidence
Finding: The skill persists user task data and generated deliverables to a dated folder in the user's Documents directory, creating session persistence beyond the immediate interaction. In a multi-agent workflow that reads multiple persona/config files and may handle sensitive project information, this increases the risk of unintended retention, later disclosure, or cross-task data exposure.

Context-Inappropriate Capability

Medium

Confidence: 92% confidence
Finding: The maintenance instructions invoke an external shell script from a user home directory, which creates a code-execution path outside the skill file itself. If that script is modified, replaced, or misunderstood by users/operators, the skill becomes a launch point for unintended command execution.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The instruction to delete BOOTSTRAP.md after reading encourages the agent to remove a file without user confirmation or visibility. Even if intended as cleanup, it is a destructive action that can erase provenance, onboarding context, or evidence of prior instructions, and it normalizes silent file deletion by the skill.

Description-Behavior Mismatch

Medium

Confidence: 89% confidence
Finding: The file authorizes external communications such as emails, tweets, and public posts as part of the agent's operating model, even though the manifest describes a squad for managing projects and workflows rather than a communications proxy. This broadens the action surface and can lead to unintended disclosures or impersonation-like behavior if the skill is activated in the wrong context.

Vague Triggers

Medium

Confidence: 81% confidence
Finding: The group-chat guidance is broad enough that the agent may decide to participate in ordinary conversations whenever it thinks it can add value. In a skill intended for squad/project work, that increases the risk of accidental triggering, oversharing from workspace context, or socially intrusive behavior outside the user's intended task scope.

Description-Behavior Mismatch

Medium

Confidence: 96% confidence
Finding: These instructions expand the skill from project/workflow support into ongoing personal-assistant surveillance and proactive monitoring. That creates a scope mismatch: once invoked for a squad task, the agent is encouraged to keep checking inboxes, calendars, notifications, and other user context unrelated to the requested task, increasing unnecessary access to sensitive data and the chance of unexpected actions.

Context-Inappropriate Capability

Medium

Confidence: 97% confidence
Finding: Directing the agent to check calendars, emails, social mentions, and weather is unrelated to the stated multi-agent project squad purpose and needlessly grants broad access to personal context. This violates least privilege and increases the likelihood of privacy exposure, over-collection, or actions based on data the user did not intend to share for this skill invocation.

Autonomous Decision Making

Medium

Category: Excessive Agency
Content: - Nothing new since last check - You just checked <30 minutes ago **Proactive work you can do without asking:** - Read and organize memory files - Check on projects (git status, etc.)
Confidence: 83% confidence
Finding: The skill explicitly authorizes proactive work without asking, including reading/organizing memory files and checking projects. In combination with the broader memory and heartbeat instructions, this creates autonomous access and behavior beyond a single user-requested task, increasing the risk of unauthorized data review or unintended state changes.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The instruction to delete BOOTSTRAP.md on first run authorizes file deletion without a user-facing warning or confirmation. Even if intended as cleanup, it normalizes destructive behavior during initialization and can erase forensic or onboarding information that may be important for audit, recovery, or user review.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The instructions encourage creating and updating memory files with user context but do not provide adequate warning, consent, minimization, or retention guidance for personal data. This can result in unbounded storage of sensitive information and increase privacy and leakage risks across sessions and contexts.

Description-Behavior Mismatch

Medium

Confidence: 91% confidence
Finding: The file permits sending emails, tweets, public posts, and other machine-leaving actions within a skill described only as activating a multi-agent squad for projects and workflows. Even though it says 'ask first,' embedding these communication powers in the workspace instructions expands the operational scope beyond what users would reasonably expect from this skill.

Vague Triggers

Medium

Confidence: 88% confidence
Finding: The heartbeat trigger condition relies on matching a configured prompt, which is ambiguous and may cause accidental invocation if ordinary messages resemble the expected text. That can lead the agent to perform background checks or file operations unexpectedly, without clear user intent in the current conversation.

Description-Behavior Mismatch

Medium

Confidence: 95% confidence
Finding: The heartbeat section authorizes broad proactive personal-assistant behavior such as checking email, calendar, mentions, weather, organizing memory, and pushing changes, which exceeds the declared purpose of a squad/project orchestration skill. This creates scope creep and can lead to unauthorized access, monitoring, or outbound actions unrelated to the user’s explicit request.

Context-Inappropriate Capability

Medium

Confidence: 96% confidence
Finding: Generalized monitoring of emails, calendars, social mentions, and weather is not justified by the stated squad-activation purpose and introduces persistent surveillance-like behavior. In a multi-agent context, this increases the chance of collecting, retaining, and acting on sensitive personal data outside the original task scope.

Autonomous Decision Making

Medium

Category: Excessive Agency
Content: - Nothing new since last check - You just checked <30 minutes ago **Proactive work you can do without asking:** - Read and organize memory files - Check on projects (git status, etc.)
Confidence: 88% confidence
Finding: The section explicitly authorizes proactive work 'without asking,' including reading/organizing memory files, checking projects, updating documentation, and committing/pushing changes. In practice this grants autonomous decision-making and write-side actions that could modify user data or external systems without contemporaneous approval.

Static analysis

No suspicious patterns detected.