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.

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## 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
## 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## 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 ``` ``` ### 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
## 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## 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
## 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.
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
Content
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
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.

Self-Modification

High
Category
Rogue Agent
Content
## 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
```

## Rollback
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.

Vague Triggers

Medium
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.

Missing User Warnings

Medium
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.

Static analysis

No suspicious patterns detected.