Back to skill

Security audit

Employee

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent and not deceptive, but it needs review because it creates persistent AI employees, stores task memory, loads other skills, and can delegate high-impact actions with incomplete guardrails.

Install only if you are comfortable with persistent local employee profiles under ~/employee, task logs, and document-derived memory being reused by subagents. Before using it with sensitive work, add controls for safe employee identifiers, backups, memory review/deletion, prompt-injection filtering for training documents, and pinned or verified skill sources. Keep employees at draft-only or review autonomy until permissions, file access, messaging, and spawning are tightly scoped.

Vulnerability Patterns
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T02 · Agent Memory Poisoning

Error
Location
SKILL.md:31
Finding
Persistent Prompt Injection Through Employee Memory## Vulnerability Details **File Location**: `SKILL.md:31-34`; related execution flow in `routing.md:43-48` and write behavior in `lifecycle.md:28-39` **Vulnerability Type**: Persistent memory poisoning **Risk Level**: High ### Vulnerable Code `SKILL.md:31-34` ```markdown ### 2. Memory is Mandatory - Load `memory/context.md` before every task - Employees remember context across sessions - Log learnings after each task ``` `routing.md:43-48` ```text 1. Load employee.json → get config 2. Load skill (linked/embedded/clawhub) 3. Inject memory/context.md as context 4. Spawn as subagent with employee's model 5. Execute task 6. Log to logs/YYYY-MM-DD.md ``` `lifecycle.md:28-39` ```markdown ## Train **Syntax:** `train {name} on [documents/context]` **Actions:** - Append to `memory/context.md` - Optionally create domain-specific files - Update employee stats **Example:** ``` User: "Train Luna on our company style guide" ``` ### Technical Analysis The Skill permits content derived from arbitrary documents or context to be appended to persistent employee memory. That memory is subsequently injected into the subagent context before every task. The design does not require: - Separation of factual data from executable instructions. - Prompt-injection detection or instruction filtering. - Source provenance and trust classification. - Human approval before new persistent rules become active. - Integrity protection or review of later memory modifications. - A rule that memory content must be treated as untrusted reference data. Consequently, an attacker-controlled training document can contain instructions that are persisted as memory and interpreted as authoritative behavioral guidance in future sessions. The vulnerability crosses session boundaries because the poisoned content remains in `memory/context.md`. ### Attack Path 1. An attacker creates or modifies a document that ...[truncated 1140 chars]
Remediation
## Remediation Suggestions 1. Treat all training documents and retrieved content as untrusted data rather than instructions. 2. Extract memory into a structured schema containing facts, preferences, source identifiers, timestamps, and trust levels. 3. Reject or quarantine imperative language, tool-use requests, policy changes, encoded content, and instructions directed at the agent. 4. Require explicit human approval before persistent memory is created or changed. 5. Delimit injected memory with an instruction stating that it is non-authoritative reference material and cannot modify system policies, permissions, or task goals. 6. Preserve source provenance and provide a reviewable diff for every memory update. 7. Apply integrity checks and maintain version history so poisoned changes can be detected and rolled back. 8. Restrict the employee's runtime permissions independently of prompt instructions so poisoned memory cannot grant itself additional capabilities.

T09 · Insecure Skill Coding Practices

Error
Location
lifecycle.md:3
Finding
Filesystem and Shell Injection Through Unvalidated Employee Names## Vulnerability Details **File Location**: `lifecycle.md:3-12` **Vulnerability Type**: Unsanitized user input in filesystem commands **Risk Level**: High ### Vulnerable Code ```markdown ## Hire **Syntax:** `hire {name} as {role}` or `create employee {name} for {purpose}` **Actions:** ```bash mkdir -p ~/employee/employees/{name}/memory mkdir -p ~/employee/employees/{name}/logs # Create employee.json with role config # Update registry.json ``` ### Technical Analysis The employee name originates from user input and is embedded directly into shell command examples. The documented requirements only state that the name must be unique; they do not impose a safe identifier grammar, quoting requirements, canonical path validation, or directory-containment checks. If an implementation performs direct textual substitution, a crafted name can introduce: - Path traversal sequences that escape `~/employee/employees`. - Absolute or home-relative path components. - Shell separators, substitutions, redirections, or whitespace that alter the command. - Option-like values that change utility behavior in related commands. Even if the implementation avoids a shell, unrestricted path separators can still cause directory creation outside the intended employee directory. ### Attack Path 1. An attacker supplies a specially crafted value in the `{name}` position of a hire request. 2. The Agent follows the documented lifecycle procedure and substitutes that value into the `mkdir` commands. 3. Shell metacharacters may be interpreted as additional commands, or traversal components may resolve outside the intended employee root. 4. The process creates or modifies filesystem locations using the privileges of the Agent. 5. Subsequent configuration, memory, and registry operations may write additional attacker-influenced content into the escaped location. ### Impact Assessment Successful exploitation may create directorie ...[truncated 485 chars]
Remediation
## Remediation Suggestions 1. Require employee identifiers to match a strict allowlist such as `^[a-z0-9][a-z0-9_-]{0,63}$`. 2. Reject path separators, traversal components, whitespace, control characters, shell metacharacters, and leading hyphens. 3. Do not build shell commands by interpolating user input. Use filesystem APIs or argument-array process execution. 4. Resolve the canonical destination path and verify that it remains beneath the canonical `~/employee/employees` root. 5. Create directories with restrictive permissions and fail if symbolic links are encountered in the destination chain. 6. Use the validated identifier for filesystem paths and store the human-readable display name separately. 7. Apply the same validation to clone, retire, train, assign, and other lifecycle commands that accept employee names.

T08 · Insecure Dependencies

Error
Location
employee-template.md:61
Finding
Unverified Dynamic Loading of Local and Registry Skills## Vulnerability Details **File Location**: `employee-template.md:61-67`; related loading behavior in `routing.md:43-46` **Vulnerability Type**: Untrusted Skill dependency loading **Risk Level**: High ### Vulnerable Code `employee-template.md:61-67` ```markdown ## Skill Linking Modes | Mode | Use Case | Config | |------|----------|--------| | linked | Uses existing skill | `"type": "linked", "path": "~/path/to/skill/"` | | embedded | Skill inside employee folder | `"type": "embedded"` (uses `./skill/SKILL.md`) | | clawhub | Published skill | `"type": "clawhub", "slug": "author/skill-name"` | ``` `routing.md:43-46` ```text 1. Load employee.json → get config 2. Load skill (linked/embedded/clawhub) 3. Inject memory/context.md as context 4. Spawn as subagent with employee's model ``` ### Technical Analysis The routing process dynamically loads linked, embedded, or registry-hosted Skills and then starts a subagent using their instructions. The specification does not require immutable version pinning, content hashes, signature validation, trusted-publisher restrictions, path ownership checks, or renewed review when Skill content changes. A linked local path is mutable after employee creation. A ClawHub slug similarly identifies a source without documenting an immutable version or integrity digest. Therefore, the effective instructions executed at task time can differ from those reviewed when the employee was configured. This is a supply-chain trust-boundary failure: externally controlled or later-modified Skill content is granted the employee's runtime context and permissions. ### Attack Path 1. A user configures an employee with a linked path or ClawHub Skill slug. 2. An attacker compromises the publisher, registry artifact, local Skill directory, or another process with write access to the linked path. 3. The attacker replaces the Skill instructions with malicious content. 4. A task is routed to t ...[truncated 792 chars]
Remediation
## Remediation Suggestions 1. Pin registry Skills to immutable versions and cryptographic content hashes rather than mutable slugs. 2. Verify signed manifests and restrict installation to explicitly trusted publishers. 3. Resolve and validate linked local paths, require trusted ownership and restrictive permissions, and reject symbolic-link escapes. 4. Audit Skill content before activation and store the approved digest in `employee.json`. 5. Recalculate the digest before every load and block execution if the content differs from the approved artifact. 6. Require explicit user approval and a new security review whenever a Skill version or digest changes. 7. Execute third-party Skills in a sandbox with minimal tool, file, network, and messaging permissions. 8. Record the exact Skill version, digest, source, and publisher in task logs for traceability.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (7)

Vague Triggers

Medium
Confidence
91% confidence
Finding
The implicit routing rule matches requests against roles in `registry.json`, which is a broad trigger that can cause accidental delegation when user intent is ambiguous. In a skill that manages semi-persistent, potentially autonomous sub-agents, unintended invocation is more dangerous because it may expose memory/context or cause actions to be taken by the wrong employee within their permissions.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The Train command explicitly reads user-provided documents, extracts information, and appends it into persistent memory without any privacy boundary, consent prompt, retention policy, or warning about sensitive data handling. In a skill built around persistent AI employees, this increases the chance that confidential internal documents, personal data, or secrets are stored long-term and later surfaced to subagents or future tasks.

Vague Triggers

Medium
Confidence
91% confidence
Finding
The routing logic allows unmentioned requests to be analyzed and potentially auto-routed based on broad role matching, which can delegate user tasks without explicit user intent. In a skill that spawns subagents, loads external skills, and injects persistent memory, this increases the chance of unintended context exposure, execution under the wrong role, or task handling by a less appropriate employee.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The execution flow states that delegated tasks inject memory/context.md and log activity, but the routing description does not require warning the user that their request and stored context may be shared with a subagent and written to logs. This creates a real privacy and security risk because sensitive data may be exposed to delegated agents or persisted without informed consent.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
- ❌ Routing to inactive/retired employees
- ❌ Routing outside employee's permissions
- ❌ Auto-delegating without checking autonomy level
- ❌ Routing urgent tasks to shadow-level employees
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.

Missing User Warnings

Low
Confidence
95% confidence
Finding
The setup instructions create directories and overwrite `~/employee/registry.json` using shell commands without any warning, confirmation step, or backup guidance. While the commands are simple and not overtly malicious, they can cause unintended filesystem changes or destroy existing data if a user runs them in an environment where `~/employee` already contains important state.

Missing User Warnings

Low
Confidence
87% confidence
Finding
The Hire command performs filesystem mutations by creating directories and updating employee records, but the user-facing flow does not clearly warn that persistent on-disk state will be created or modified. While this is expected behavior for lifecycle management, hidden persistence can still surprise users, create unwanted local artifacts, and contribute to later privacy or integrity issues if users do not realize data is being stored.

Static analysis

No suspicious patterns detected.