mano-afk

• Outcome: Review
• Latest audit: Sep 16, 2026 · 7:29 AM UTC
• Version: 1.0.8

Overview

The skill is a coherent autonomous app builder, but it gives an agent broad build/deploy authority and can persist unreviewed learned rules into future projects.

Use this skill only for disposable or clearly separated app-build workspaces. Review the Homebrew tap/source before installing, do not enable cloud E2E unless screenshots and task descriptions may leave your machine, avoid real production databases, and inspect references/rules.md and references/preferences.md after runs because they can affect future projects.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• 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 (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:5
• Finding: Unpinned Executable Installed from a Mutable Custom Homebrew Tap## Vulnerability Details **File Location**: `SKILL.md:5` **Vulnerability Type**: Supply-chain exposure through an unpinned third-party executable **Risk Level**: Medium **Vulnerable Code Snippet**: ```yaml metadata: {"openclaw": {"emoji": "⚙️", "install": [{"id": "brew", "kind": "brew", "formula":"Mininglamp-AI/tap/mano-afk", "bins":["mano-afk"],"label": "Install mano-afk (brew)"}]}} ``` ### Technical Analysis The skill installs the `mano-afk` executable from the custom Homebrew tap `Mininglamp-AI/tap` without specifying an immutable package version, source commit, artifact checksum, or other integrity constraint. A custom tap is an externally controlled supply-chain source whose formula and referenced artifacts can change after this skill has been reviewed. The installed executable is subsequently trusted for configuration, environment checks, and browser-based E2E operations. Because the audited project does not contain the executable's implementation, those behaviors cannot be verified from the skill package itself. The finding does not establish that the current package is malicious; it identifies the lack of controls preventing a future compromised or modified release from being installed and executed. ### Attack Path 1. An attacker compromises the custom Homebrew tap, its release infrastructure, or an artifact referenced by its formula. 2. The attacker modifies the formula or release so that `mano-afk` contains malicious code. 3. A user installs the skill, causing Homebrew to resolve the mutable `Mininglamp-AI/tap/mano-afk` formula. 4. The malicious executable is installed under the trusted `mano-afk` command name. 5. The skill invokes commands such as `mano-afk check`, `mano-afk config`, or `mano-afk run`. 6. The substituted code executes with the privileges of the user running the agent. ### Impact Assessment Successful exploitation would provide code execution with the current user's privileges. The executa ...[truncated 367 chars]
• Remediation: ## Remediation Suggestions 1. Pin installation to a specific, immutable release rather than the latest formula state. 2. Verify downloaded artifacts with a cryptographic SHA-256 checksum maintained in reviewed skill metadata. 3. Pin the tap or formula definition to a reviewed commit where the installation platform permits it. 4. Publish the resolved source and binary artifact URLs so reviewers can audit the actual executable. 5. Use signed releases and verify signatures before installation. 6. Prefer a trusted package source with reproducible builds and transparent provenance. 7. Add automated dependency monitoring and require security review before changing the pinned version or checksum.

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:166
• Finding: Unvalidated Sub-Agent Rules Can Persist Across Future Projects## Vulnerability Details **File Location**: `SKILL.md:166-168`; related rule-generation instruction at `references/build-pipeline.md:153-154` **Vulnerability Type**: Persistent agent memory poisoning **Risk Level**: High **Vulnerable Code Snippets**: `SKILL.md:166-168`: ```markdown - Summarize to the user: total tests, pass/fail, project directory - **Update rules:** Review the fix loop history. If any error pattern would prevent the same class of bug in a future project, add a general rule to `references/rules.md` (max 100, remove least valuable if full). Also merge any `new-rules.md` the build sub-agent wrote in the project root. - **Update preferences:** If the user gives follow-up feedback (styling, features), update `references/preferences.md` ``` `references/build-pipeline.md:153-154`: ```markdown 6. If new rules were learned (general patterns that would prevent this class of bug in future projects), write them to `new-rules.md` in the project root > **Update progress.md** — `status: ready_for_testing, detail: Fixed: {brief summary of changes}` ``` ### Technical Analysis The workflow permits a build sub-agent to write `new-rules.md` inside a user-influenced project and directs the main agent to merge that content into the persistent `references/rules.md` file. Future build sub-agents explicitly read and follow `rules.md`, so merged text can influence subsequent projects and sessions. No validation boundary is specified for this merge. In particular, the workflow does not require a constrained rule schema, provenance checks, semantic filtering, rejection of tool or security directives, or explicit user approval. Although `new-rules.md` is intended to contain generalized engineering lessons, it is produced by a sub-agent processing user-controlled requirements, project files, and failure descriptions. A crafted request or project artifact could therefore induce the sub-agent to emit behavioral instructions rather ...[truncated 2024 chars]
• Remediation: ## Remediation Suggestions 1. Never merge `new-rules.md` automatically. Present each proposed rule to the user or a trusted reviewer for explicit approval. 2. Replace free-form Markdown ingestion with a strict structured schema containing only narrowly defined engineering fields. 3. Reject entries containing agent-control instructions, tool invocations, shell commands, external URLs, credential handling, permission changes, or directives that weaken safety controls. 4. Normalize and validate each rule before storage, enforcing length limits and an allowlist of acceptable rule categories. 5. Record provenance for every entry, including originating project, timestamp, triggering failure, producing agent, and approving reviewer. 6. Store project-specific lessons within the project rather than in shared persistent memory. 7. Isolate persistent rules by trusted user or workspace to prevent one project from affecting unrelated users or repositories. 8. Show a diff before any update and maintain a rollback-capable audit log. 9. Treat existing `rules.md` content as untrusted data when constructing sub-agent prompts, clearly delimiting it and stating that it cannot override system, safety, or task-boundary instructions. 10. Periodically review and expire persistent rules instead of retaining them indefinitely.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (16)

Self-Modification

High

• Category: Rogue Agent

Content

---
name: mano-afk
description: Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferences and development pitfalls to self-evolve across projects. Use when the user explicitly requests a fully autonomous end-to-end app build.
homepage: https://github.com/Mininglamp-AI/mano-afk
metadata: {"openclaw": {"emoji": "⚙️", "install": [{"id": "brew", "kind": "brew", "formula":"Mininglamp-AI/tap/mano-afk", "bins":["mano-afk"],"label": "Install mano-afk (brew)"}]}}
---

• Confidence: 95% confidence
• Finding: The skill is explicitly designed to persist lessons and preferences across projects and to update rules after fix loops, creating a self-modifying behavior that changes future execution. Persistent cross-project state is risky because poisoned rules, bad heuristics, or adversarially induced preferences can silently propagate into later builds and testing decisions.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

## Orchestration

**AFK rule:** Step 0 is the only user interaction window. From Step 1 onward, make all decisions autonomously — never ask the user. Ambiguous decisions (8bit vs float, React vs Vue, port selection) use the most reasonable default and document in PRD.md. Only stop if completely infeasible (missing hardware, no permissions, 10 fix iterations exhausted).

### Step 0: User Setup (interactive)

• Confidence: 89% confidence
• Finding: The skill mandates autonomous decision-making after a single setup window and forbids further user interaction, while also authorizing building, deploying, testing, and iterative fixes. In this context, the danger is not the autonomy alone but that it combines with code execution, deployment actions, and state changes, reducing opportunities for user approval before risky operations.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill instructs the agent to clear all application tables or delete and reinitialize the SQLite file before E2E testing, but it does not require a prominent user warning or explicit consent for destructive data loss. In an autonomous AFK workflow, this increases the chance of deleting real project data without the user realizing the consequence.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The skill states that the evolving reference files are only read by build and adversary sub-agents, but other sections instruct the main agent to read and modify them directly. This is a trust-boundary and transparency mismatch: operators may rely on the documented scope, while the actual workflow gives the main agent direct access to persistent state that can influence future runs.

Intent-Code Divergence

Medium

• Confidence: 91% confidence
• Finding: The privacy section claims there are no external calls beyond opt-in cloud E2E execution, but the skill metadata and instructions rely on installing mano-afk from a remote Homebrew tap. That discrepancy can mislead users about network activity and supply-chain exposure, especially in a skill that builds and executes code autonomously.

Description-Behavior Mismatch

Medium

• Confidence: 97% confidence
• Finding: The manifest describes this skill as handling the entire app lifecycle, explicitly including testing and bug fixing. However, the pipeline states that the builder 'do[es] not run tests' and delegates all testing to the caller, which materially narrows the implemented behavior relative to the claimed capability.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Project Setup

- Create the project in its own independent directory (never inside an existing project)
- Python projects: always use a virtual environment
- The references directory path is provided in your prompt. Read `rules.md`, `preferences.md`, and templates from it as needed.

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 78% confidence
• Finding: The pipeline permits deployment via `npx serve` without pinning an exact package version. In an autonomous build/deploy skill, this creates a supply-chain risk because each invocation may fetch whatever version is currently published, enabling unexpected behavior changes or compromise if the upstream package is tampered with.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: These lines instruct the skill to generate API/E2E test cases for README.md rather than execute them. Combined with fix mode depending on externally supplied test failures, the documented behavior supports test authoring and bug fixing, but not autonomous test execution as promised by the manifest.

Session Persistence

Medium

• Category: Rogue Agent

Content

5. Verify accessible (curl health endpoint or check port). On failure, read log files immediately.
6. If the app uses LLM/API features, verify the API key is accessible from the running backend (e.g., `curl` the AI endpoint).

Create `deploy/start.sh` — idempotent, one-command startup. If the app requires environment variables (e.g., API keys), the script must explicitly pass only the required variables — do NOT source the user's shell profile (`~/.zshrc`, `~/.bashrc`, etc.) as it exposes unrelated secrets. Use `export VAR_NAME="${VAR_NAME}"` at the top of the script for each required variable.

> **Update progress.md** — `phase: 4, status: ready_for_testing, title: Deploy`

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

### E2E Tests (VLA via mano-afk)

**Writing rules:**
- **task**: Operation path only — clicks, inputs, navigation. No verification verbs (verify, check, ensure). No conditionals (if, any). Targets must be specific ("the first item", not "any item").
- **expect**: Observable page state only — what is visible after operations. No conditionals. No instructions.
- Tests run sequentially top-to-bottom. Use Depends to declare state dependencies.
- `--url` opens the page before the agent starts — do not include URL navigation in task.

• Confidence: 75% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

### E2E Tests (VLA via mano-afk)

**Writing rules:**
- **task**: Operation path only — clicks, inputs, navigation. No verification verbs (verify, check, ensure). No conditionals (if, any). Targets must be specific ("the first item", not "any item").
- **expect**: Observable page state only — what is visible after operations. No conditionals. No instructions.
- Tests run sequentially top-to-bottom. Use Depends to declare state dependencies.
- `--url` opens the page before the agent starts — do not include URL navigation in task.

• Confidence: 75% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Scope Creep

Low

• Category: Excessive Agency

Content

1. **Read references** — read `rules.md`, `preferences.md`, and `prd-template.md` from the references directory.
2. **Understand the request** — identify core functionality, target user, data model, and scope boundary.
3. **Fill in gaps autonomously** — for any detail not specified by the user (visual design, validation rules, error messages, layout, interaction details), make reasonable decisions based on rules and preferences. Document each decision.
4. **Expand scope** — add standard features the user didn't mention but would expect: error handling, responsive layout, input validation, empty states.
5. **Apply styling** — read `preferences.md` for global taste, then derive a project-specific color palette and component styles from the product's domain.
6. **Generate `PRD.md`** — write a complete PRD using the `prd-template.md` structure. Every feature must have acceptance criteria (Given-When-Then) with L1/L2/L3 levels. Every error scenario must have an explicit message and behavior. The PRD is the single source of truth for what to build.

• Confidence: 75% confidence
• Finding: Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.

Missing User Warnings

Low

• Confidence: 92% confidence
• Finding: The template explicitly tells authors to reference a user-specific `preferences.md` file, which encourages incorporation of persisted personal preference data into new project artifacts without any notice about consent, minimization, or sensitivity boundaries. In an autonomous app-building skill that remembers user preferences across projects, this increases the chance of unintended cross-project data reuse or privacy leakage, even if the referenced data is not highly sensitive by default.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: The instruction 'Default to light mode' imposes a specific visual preference as a default behavior in natural language. Under the policy rule for language/locale-style constraints, this is a user-preference constraint stated without offering explicit user choice or opt-in.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: The document uses prescriptive natural language ('always use a virtual environment') that imposes a specific environment/setup policy on all Python projects. This is a natural-language policy constraint without any stated opt-in, exception path, or context-specific justification.

Static analysis

No suspicious patterns detected.