Phoenix Shield
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If followed, the agent could make broad production system changes that affect packages, services, and availability.
The skill documents high-impact system mutation through raw command strings, privileged hooks, and automatic rollback, but does not show clear approval, scoping, or safety boundaries.
phoenix-shield deploy \ --command "apt update && apt upgrade -y" \ --health-check "systemctl status nginx" \ --health-check "systemctl status mysql" \ --pre-hook "/root/notify-start.sh" \ --post-hook "/root/notify-complete.sh" \ --auto-rollback
Require explicit user confirmation for each update and rollback, prefer dry runs first, restrict allowed commands, and test in staging before production.
Users may be led to run or install an unverified external tool to perform safety-critical backups and rollbacks.
The instructions depend on a phoenix-shield executable, but no reviewed installer, source, required binary, or package provenance is provided.
No install spec — this is an instruction-only skill.
Provide a verifiable source, pinned installation instructions, required binary declarations, and implementation artifacts before relying on it for production changes.
A user or agent could over-trust the skill during critical updates and assume recovery guarantees that are not evidenced by the provided artifacts.
The skill makes strong reliability and safety claims, but the artifact set contains only documentation and no implementation that can substantiate those protections.
**Solution:** PhoenixShield provides a complete safety net with automatic rollback when things go wrong. ... 🛡️ **Zero-Downtime** - Graceful degradation when possible
Treat the reliability claims as unverified until the tool is installed from a trusted source and tested against non-production systems.
The system could continue monitoring and making recovery changes after the initial update command, potentially affecting services without timely human review.
The documented configuration enables long-running monitoring and autonomous rollback behavior, but the artifacts do not define containment, stop controls, or when human approval is required.
monitoring: enabled: true duration: 24h ... rollback: strategy: smart # smart, full, manual auto_rollback: true max_attempts: 3
Define explicit monitoring duration, stop commands, logging, alerting, and human approval requirements before enabling automatic rollback.
Running these workflows could require broad administrator privileges across production hosts.
The examples imply root-level local hooks and multi-server administrative access, but the registry declares no credentials, config paths, or permission boundaries.
--pre-hook "/root/notify-start.sh" \ --post-hook "/root/notify-complete.sh" \ --target "$server"
Use least-privilege accounts, restrict target hosts, document required credentials, and require explicit approval before privileged or remote actions.
Sensitive configuration, database, and system information may be stored in backup locations.
Broad persistent backups are purpose-aligned for a rollback tool, but they can contain secrets, private data, and operational context.
**Backup includes:** - Configuration files - Database dumps - System state - Process list - Network connections - Health metrics baseline
Encrypt backups, restrict file permissions, define exclusions for secrets, and verify retention and deletion behavior.