ClawHub
Back to skill

Security audit

Phoenix Loop

Security checks for vulnerabilities and agentic risk

Overview

This skill is locally focused but asks the agent to create and update future skills automatically, including on a recurring heartbeat, without enough user control.

Install only if you are comfortable with a skill that can alter the agent's reusable skill set and memory over time. Before use, require manual review before any write to skills/local, any HEARTBEAT.md change, or any generated recovery skill being enabled; treat memory/task logs as untrusted input and verify redaction yourself.

A.I.G

Vulnerability Patterns
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • 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:16
Finding

Untrusted Memory Can Be Converted into Persistent Executable Agent Instructions

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 16-66
Vulnerability Type: Persistent agent memory poisoning
Risk Level: High

Vulnerable Code

powershell
# Read recent blocked items
Get-Content memory/blocked-items.md | Select-String "Blocker" -Context 3

# Extract failure patterns
Get-Content memory/tasks.md | Select-String "Status: failed" -Context 5
markdown
### 3. Crystallize

Write the lesson to a local skill:

skills/local/{pattern_name}-recovery.md
markdown
### 4. Verify

Next time a similar issue occurs:
1. Search `skills/local/` for matching skills
2. Execute recovery steps
3. Log result to `memory/{date}.md`
4. Update skill if needed

Technical Analysis

The skill treats content from memory/blocked-items.md and memory/tasks.md as a source for reusable recovery instructions. It then directs the agent to write extracted lessons into skills/local/, execute those instructions during future matching situations, and update them based on subsequent results.

The process does not define a trust boundary between historical task data and executable agent instructions. It also lacks provenance checks, an action allowlist, safety-policy revalidation, or mandatory user approval before a generated skill becomes active. The documented sensitive-data filter addresses selected privacy patterns but does not detect hostile instructions embedded in task or blocker records.

Consequently, an attacker who can influence memory content could cause attacker-controlled text to be crystallized into a persistent local skill. The issue is persistence through the agent's own skill and memory mechanisms rather than an operating-system privilege escalation.

Attack Path

  1. An attacker, untrusted task, or compromised process causes malicious recovery guidance to appear in memory/blocked-items.md or memory/tasks.md.
  2. Phoenix Loop reads the affected memory entry during diagnosis.
  3. The malicious guidance is interpret ...[truncated 989 chars]
Remediation
View remediation

Remediation Suggestions

  1. Treat all task history, blocker records, logs, and memory files as untrusted data.
  2. Do not directly convert free-form memory content into executable skill instructions.
  3. Represent proposed recoveries using a strict schema with validated triggers and an allowlist of permitted actions.
  4. Require explicit user review and approval before creating, enabling, updating, or executing a generated skill.
  5. Reapply the agent's current safety and authorization policies to every generated recovery step.
  6. Record the source and provenance of every proposed instruction in an immutable audit log.
  7. Separate generated drafts from enabled skills; generated content should be inactive by default.
  8. Reject instructions that request command execution, credential access, network access, configuration changes, or unrelated file operations unless separately authorized.
  9. Add expiration and revocation controls for generated skills.
  10. Test the mechanism against indirect prompt injection placed in task descriptions, error messages, blocker records, and tool output.

T06 · System Persistence

Error
Location
SKILL.md:136
Finding

Heartbeat Modification Establishes Autonomous Cross-Session Persistence

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 136-144
Vulnerability Type: Persistent recurring agent configuration
Risk Level: High

Vulnerable Code

markdown
## Heartbeat Integration

Add to `HEARTBEAT.md`:

```markdown
## Self-Check (Every 24 Hours)
1. Check `memory/blocked-items.md` for blockers older than 24h
2. Run phoenix-loop diagnosis on each long-term blocker
3. If reusable pattern found, create or update skill
text

### Technical Analysis

The documentation instructs the agent to modify `HEARTBEAT.md` so Phoenix Loop runs every 24 hours. The recurring process reads mutable memory and can create or update other local skills without requiring a new invocation of the original task.

This creates a persistent cross-session hook in the agent's configuration. Although it is not an operating-system service or scheduled task, it has the equivalent persistence effect within the agent environment: behavior remains active after the initiating skill run and can continuously generate or modify executable agent instructions.

The risk is compounded by the memory-poisoning issue because each recurring execution processes data that may have been influenced by untrusted tasks or tool output.

### Attack Path

1. Phoenix Loop is loaded and its heartbeat integration instructions are followed.
2. The agent modifies `HEARTBEAT.md` to add the 24-hour self-check.
3. An attacker causes a crafted blocker or failure record to remain in `memory/blocked-items.md`.
4. On a later heartbeat, the agent automatically runs Phoenix Loop diagnosis.
5. The attacker-controlled record is classified as a reusable pattern.
6. The recurring process creates or updates a local recovery skill.
7. Future heartbeat runs or matching tasks continue to preserve, modify, or execute the resulting behavior.

### Impact Assessment

The modification can maintain autonomous behavior across agent sessions and beyond the lifetime of the task that installed it. It can repeated
...[truncated 405 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove automatic instructions to modify HEARTBEAT.md.
  2. Make recurring execution explicitly opt-in and disclose its frequency, scope, and side effects.
  3. Require user confirmation before every heartbeat configuration change.
  4. Do not allow heartbeat processing to create, enable, or update executable skills automatically.
  5. Run recurring diagnostics in a read-only sandbox and emit recommendations rather than modifying files.
  6. Add expiration dates, maximum run counts, and a clearly documented disable mechanism.
  7. Bind recurring jobs to an authenticated owner and preserve an audit trail of installation and execution.
  8. Revalidate the trust and provenance of every memory entry on each run.
  9. Detect and prevent duplicate heartbeat entries or self-replication.
  10. Ensure rollback removes both the generated skills and the persistent heartbeat entry.

T09 · Insecure Skill Coding Practices

Warning
Location
references/privacy-checklist.md:5
Finding

Incomplete Sensitive-Data Validation Can Produce False Privacy Assurance

Content
View full analysis

Vulnerability Details

File Location: references/privacy-checklist.md, lines 5-11 and 42-49; related filtering requirements in SKILL.md, lines 72-84
Vulnerability Type: Incomplete secret and personal-data detection
Risk Level: Medium

Vulnerable Code

powershell
# Scan for sensitive patterns
Get-ChildItem skills/local/ -Recurse -File | ForEach-Object {
    $content = Get-Content $_.FullName -Raw
    if ($content -match 'apiKey|token|secret|password|Bearer |sk-|OPENCLAW_') {
        Write-Warning "Sensitive content: $($_.FullName)"
    }
}
powershell
# Run check
$files = Get-ChildItem skills/local/phoenix-loop* -Recurse -File
foreach ($f in $files) {
    $c = Get-Content $f.FullName -Raw
    if ($c -match '(?i)apiKey|token|secret|password') {
        throw "Sensitive content detected: $($f.FullName)"
    }
}
Write-Host "Privacy check passed"

The related requirements in SKILL.md state:

markdown
**Sensitive Data Filter**:
Before writing to any memory or skill, check and remove:
- `apiKey`, `token`, `secret`, `password`
- `Bearer `, `sk-`, `OPENCLAW_`
- Personal emails, phones, addresses

Technical Analysis

The privacy requirements promise removal of credentials and personal information, including email addresses, telephone numbers, and addresses. The implemented PowerShell checks use a small keyword-based regular expression and do not implement detection for several promised data classes.

The pre-publish check is narrower than the initial scan: it tests only apiKey, token, secret, and password. It can therefore print Privacy check passed even when files contain bearer credentials, keys using an unrecognized prefix, personal contact information, user-specific paths, addresses, or secret values without one of the expected labels.

The scans also focus on local skill files. They do not comprehensively scan the memory files from which content is extracted. The first scan only emits a warning, which allows ...[truncated 1228 chars]

Remediation
View remediation

Remediation Suggestions

  1. Replace the limited keyword scan with structured secret and personal-data detection.
  2. Cover all promised data classes, including emails, telephone numbers, addresses, bearer credentials, private keys, connection strings, access tokens, user-specific absolute paths, and common provider-specific key formats.
  3. Scan secret values and entropy patterns rather than relying only on nearby labels such as token or password.
  4. Scan every generated skill and all relevant memory files before and after writing.
  5. Make all detections fail closed instead of emitting warnings and continuing.
  6. Do not print Privacy check passed unless every required scan has completed successfully.
  7. Minimize retained content by storing normalized pattern names and generic recovery steps rather than copied task text.
  8. Apply deterministic redaction before persistence and verify the redacted output with a second independent scan.
  9. Add tests containing unlabeled secrets, mixed-case prefixes, emails, international phone numbers, addresses, and absolute paths.
  10. Require user review when automated redaction is uncertain, and provide a secure deletion process for previously persisted sensitive content.

SkillSpector

Vulnerability Patterns
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (4)

Self-Modification

High
Category
Rogue Agent
Confidence
94% confidence
Finding

The instruction to 'update skill if needed' enables self-modification of the agent's reusable skill set based on prior outputs and failure logs. This is dangerous because it creates a persistence mechanism where flawed, unsafe, or adversarially influenced behavior can be codified and re-executed automatically in future sessions.

Content

Scanner excerpt · SKILL.md (reported line 75)May include surrounding context.

md
1. Search `skills/local/` for matching skills
2. Execute recovery steps
3. Log result to `memory/{date}.md`
4. Update skill if needed

## Privacy Security

Self-Modification

High
Category
Rogue Agent
Confidence
95% confidence
Finding

The scheduled self-check that can 'create or update skill' every 24 hours introduces recurring autonomous self-modification with persistence over time. This increases risk because unsafe logic, prompt-injected content from memory files, or erroneous diagnoses can be repeatedly promoted into trusted local skills without user awareness.

Content

Scanner excerpt · SKILL.md (reported line 151)May include surrounding context.

Self-Check (Every 24 Hours)

  1. Check memory/blocked-items.md for blockers older than 24h
  2. Run phoenix-loop diagnosis on each long-term blocker
  3. If reusable pattern found, create or update skill
text

## Rollback

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill is triggered by broad conditions such as 'blockers, failures, or repeated friction,' which are subjective and can cause the skill to activate in many unrelated situations. Because it performs persistent writes and recovery actions, ambiguous invocation increases the chance of unintended file changes and autonomous behavior outside the user's expectations.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
89% confidence
Finding

The skill explicitly creates, updates, renames, and deletes files in memory and skills directories, but it does not present a clear upfront warning or require user approval for those system-changing actions. In agent environments, silent persistence and modification of local files can alter future behavior and create hard-to-audit state changes.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.