Hogwarts Magical Claw for Research Laboratory

• Outcome: Review
• Latest audit: Sep 12, 2026 · 6:24 AM UTC
• Version: 1.0.0

Overview

The skill is a coherent team-collaboration assistant, but it also directs recurring member monitoring, repository writes, commits, pushes, and scheduled execution without enough consent and approval controls.

Install only for a team that explicitly wants AI-assisted project tracking and has agreed to member activity processing. Before enabling it, keep heartbeat monitoring and scheduled execution off by default, require human review before Git commit or push, limit readable member files, and document how members can opt out or disable reminders.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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

Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:153
• Finding: Unbounded monitoring of team-member activity through privileged workspace state<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 153–167 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Instructions The following is an English translation of the relevant source instructions: ```markdown **Configuration location**: `/root/.openclaw/workspace/HEARTBEAT.md` **Check frequency**: - Execute every 30-minute heartbeat - Complete at least 2–3 meaningful checks each day #### 1. Member communication check (every 30 minutes) Read `memory/members-touch.md` to obtain the last communication time for members. Check whether any member has not communicated with the agent for more than three hours. If so, proactively mention the member in the group, ask to inspect the ToDo list, and discuss progress. After each communication, update the timestamp in `members-touch.md`. ``` ### Technical Analysis The skill directs the agent to access state under `/root/.openclaw/workspace`, repeatedly inspect persistent communication records, determine individual inactivity, and update those records after contacting members. This crosses a least-privilege boundary because meeting and document collaboration do not inherently require access to a root-owned agent workspace or continuous monitoring of every member's communication history. The instructions do not require administrator authorization, member consent, project-level isolation, data minimization, or a retention period. The issue does not demonstrate an operating-system privilege-escalation exploit. Rather, it instructs an already capable agent to use access broader than the collaboration task legitimately requires. ### Attack Path 1. A user installs or activates the skill in an environment where the agent can read `/root/.openclaw/workspace`. 2. A recurring heartbeat invokes the monitoring workflow every 30 minutes. 3. The agent reads `memory/members-touch.md`, exposing persistent member interaction metadata. 4. It ident ...[truncated 883 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Store heartbeat state in a project-scoped, non-root directory with permissions limited to the service account running the skill. 2. Require explicit administrator approval before enabling recurring monitoring. 3. Obtain informed consent from members whose interaction metadata will be processed. 4. Track task-level status rather than communication frequency or personal inactivity. 5. Disable automatic member outreach by default and require human approval before sending reminders. 6. Define a short retention period and automatically delete obsolete interaction records. 7. Record an audit log identifying which records were read, why they were needed, and which messages were sent. 8. Provide a documented command or configuration switch that immediately disables the monitoring workflow. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/protocol.md:32
• Finding: Centralized profiling and remote synchronization of member-derived metadata<![CDATA[ ## Vulnerability Details **File Location**: `references/protocol.md`, lines 32–47, 66–71, and 128–134 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Instructions The following is an English translation of the relevant source instructions: ```markdown Files that must be read, in priority order: 1. `README.md` 2. `docs/team/intro.md` 3. `docs/team/charter.md` 4. The three most recent meeting records under `meetings/2026/` 5. All active project descriptions under `projects/*/README.md` 6. Every member's current status page under `members/*/README.md` Generate a summary in: `members/RunWheezy/knowledge-base/current-context.md` The summary includes: - This week's primary team objectives - Active projects and important milestones - A snapshot of each member's current tasks - A list of unresolved blockers ``` ```markdown Convert unstructured information into machine-readable data under: `members/RunWheezy/knowledge-base/` - `project-roadmaps.json`: project timelines, dependencies, and milestone dates - `member-skills-index.json`: member specialties, current workload, and availability - `blocker-tracker.md`: current blockers and responsible members ``` ```bash git add members/RunWheezy/tasks/weekly/2026-wYY.md members/RunWheezy/knowledge-base/ git commit -m "docs(ai): weekly review wXX & plan for wYY" git push origin ai-assistant ``` ### Technical Analysis The protocol combines three sensitive operations: 1. Enumeration and reading of every member's status information. 2. Derivation of centralized profiles describing specialties, workload, availability, tasks, and blockers. 3. Staging, committing, and pushing the resulting knowledge base to the configured Git remote. Aggregating member data creates a more sensitive dataset than the original distributed records. The resulting profile can reveal staffing constraints, individual availability, project dependencies, and organizational b ...[truncated 1779 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace repository-wide member enumeration with an explicit allowlist of files required for the current task. 2. Require member opt-in before processing personal workload, availability, or communication data. 3. Remove availability and behavioral fields from `member-skills-index.json` unless a documented business need exists. 4. Store only minimum task-related facts and avoid creating centralized personnel profiles. 5. Classify generated files and exclude sensitive records from Git using `.gitignore` or a separate access-controlled store. 6. Validate the Git remote URL against an administrator-managed allowlist before pushing. 7. Display the complete staged diff and require human approval before any commit or push containing member-derived data. 8. Apply branch protection and repository access controls to the destination branch. 9. Establish retention and deletion procedures that account for copies retained in Git history. 10. Add automated secret and sensitive-data scanning as a mandatory pre-commit and pre-push control. ]]>

T06 · System Persistence

Warning

• Location: references/protocol.md:336
• Finding: Persistent scheduled execution without lifecycle or least-privilege controls<![CDATA[ ## Vulnerability Details **File Location**: `references/protocol.md`, lines 336–343 **Vulnerability Type**: `T06: System Persistence` **Risk Level**: Medium ### Vulnerable Instructions The following is an English translation of the relevant source instructions: ```markdown ## Initial Deployment Checklist - [ ] Create the `members/RunWheezy/` directory structure. - [ ] Perform the initialization scan and generate `current-context.md`. - [ ] Create the first weekly plan. - [ ] Test the Git commit workflow and confirm write access. - [ ] Test the human-in-the-loop workflow. - [ ] Configure scheduled reminders, such as cron or calendar events, to trigger the daily and weekly protocol. ``` ### Technical Analysis The deployment checklist directs the installer to configure cron or another scheduler that survives the initiating skill run. The scheduled protocol includes recurring reads, writes, progress checks, notifications, Git commits, and potentially Git pushes. The documentation does not specify: - Which operating-system account should own the schedule. - The exact command to be executed. - A project-scoped working directory. - Environment and credential restrictions. - Human approval before consequential actions. - Logging and failure handling. - An expiration date. - Disable, removal, or uninstall procedures. This creates persistence risk because the agent's workflows may continue across sessions and after the original user interaction has ended. If configured under a privileged account, the scheduled task may inherit access to repositories, credentials, communication services, and filesystem locations available to that account. ### Attack Path 1. An installer follows the deployment checklist. 2. A cron entry or equivalent calendar-triggered automation is registered. 3. The schedule invokes the daily or weekly agent protocol without a new interactive request. 4. The protocol reads team and member records, updates persistent files, and ...[truncated 772 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make scheduling an optional, explicit administrator-controlled feature rather than an installation requirement. 2. Run scheduled workflows under a dedicated non-root service account with project-scoped filesystem permissions. 3. Publish the exact scheduler entry, executable command, working directory, environment, and required permissions. 4. Separate read-only checks from write, messaging, commit, and push operations. 5. Require human approval before scheduled workflows send messages, modify shared files, or push Git commits. 6. Add structured logs for each invocation, including files accessed and external actions performed. 7. Configure failure limits and automatically disable the task after repeated errors. 8. Set an expiration date or maximum lifetime for every scheduled entry. 9. Provide documented status, disable, and uninstall procedures. 10. During uninstallation, remove the scheduler entry, revoke related credentials, and verify that no background process remains. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• 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

Findings (10)

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The description says the skill triggers whenever knowledge management, progress monitoring, or document collaboration is needed, which is overly broad and lacks enforceable boundaries. Because the skill also reads files, updates records, pings members, and can commit to Git, this ambiguity increases the chance of unintended activation and unauthorized workflow actions.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The meeting trigger list includes broad colloquial phrases like '讨论一下', '碰一下', and '拉通', which can cause the skill to activate in ordinary conversation without clear user intent. In a collaboration agent with authority to drive workflows, mention users, and initiate follow-up behavior, over-triggering can lead to unnecessary monitoring-style interactions and unintended operational actions.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The HEARTBEAT workflow instructs the agent to periodically read and update member communication logs and proactively contact members who have not interacted recently, but it does not require transparent notice or consent. This creates a surveillance-like behavior pattern and enables persistent tracking of individuals' activity, which is especially sensitive in a team collaboration context.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill includes automatic Git add/commit commands affecting member task logs and knowledge-base content without requiring an approval checkpoint or warning about repository writes. In practice, this can create unauthorized or accidental modifications, commit sensitive internal information, and leave an audit trail of AI-generated changes that users did not explicitly approve.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The skill directs the agent to automatically generate and update files in the repository during initialization and ongoing operation, but does not prominently warn users that invoking the skill can change repository contents. In a collaboration repository, silent writes can alter planning documents, knowledge bases, and task records in ways users may not expect or immediately review.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The protocol includes automatic git add/commit/push behavior, which can publish repository changes to a remote branch without a clear, explicit warning or approval step. In practice, this can propagate incorrect content, sensitive information, or prompt-influenced edits beyond the local workspace, making rollback and containment harder.

Context-Inappropriate Capability

Medium

• Confidence: 93% confidence
• Finding: The protocol explicitly tells the agent to set up cron or calendar-based triggers so it can act proactively without a fresh user request. That expands the skill from a reactive collaboration helper into a semi-autonomous actor, increasing the chance of unsupervised repository reads/writes, notifications, and other side effects beyond the user's immediate intent.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: 文件的名称与描述整体以中文定义助手职责和输出模式，未见提供可选语言、用户偏好继承或显式 opt-in。根据规则，若技能强制特定语言而无用户选择，属于自然语言层面的语言/locale 策略问题。

Natural-Language Policy Violations

Low

• Confidence: 83% confidence
• Finding: The skill title and entire protocol are written as a Chinese-only operating specification, and no section offers users a language or locale choice. Under the policy, forcing a specific language without opt-in is a natural-language policy concern unless the locale limitation is explicitly justified.

Intent-Code Divergence

Low

• Confidence: 95% confidence
• Finding: L021 states that all operations must be traceable through Git commits, implying a fully repository-auditable workflow. However, later lines direct the assistant to send summaries and urgent notifications in team chat channels, which contradicts that absolute traceability claim because those actions occur outside Git history.

Static analysis

No suspicious patterns detected.