Gateway Self-Heal Watchdog

• Outcome: Review
• Latest audit: Sep 11, 2026 · 6:47 AM UTC
• Version: 1.0.0

Overview

The skill is a real OpenClaw gateway watchdog, but it installs persistent scheduled execution and includes unsafe cron and root-service guidance that users should review carefully before installing.

Install only if you explicitly want a persistent OpenClaw gateway watchdog. Before running setup, back up your crontab and OpenClaw config, avoid the root systemd example unless rewritten for an unprivileged user, replace broad cron removal with exact markers, set restrictive permissions on ~/.openclaw/watchdog.sh and config backups, and add retry/retention limits so transient failures do not repeatedly roll back config or fill disk.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (5)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/setup-watchdog.sh:121
• Finding: Overbroad Cron Filtering Can Delete Unrelated Scheduled Tasks<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup-watchdog.sh`, lines 121-125 **Vulnerability Type**: Unsafe modification of user cron configuration **Risk Level**: Medium ### Vulnerable Code ```bash # Remove existing watchdog cron if any (crontab -l 2>/dev/null | grep -v "watchdog.sh") | crontab - # Add new cron job (crontab -l 2>/dev/null; echo "$CRON_JOB") | crontab - ``` Related unsafe removal instructions also appear in: ```bash crontab -l | grep -v watchdog | crontab - ``` at `SKILL.md:44` and `scripts/setup-watchdog.sh:137`. ### Technical Analysis The installer removes every cron entry containing the generic substring `watchdog.sh`, rather than removing only the exact entry owned by this skill. The documented uninstall command is even broader and removes every line containing `watchdog`. Consequently, unrelated monitoring, backup, security, or maintenance tasks can be silently deleted. The read-filter-write approach also lacks synchronization: a concurrent cron update occurring between the two `crontab -l` operations can be lost. The watchdog's user-level cron registration is consistent with its declared self-healing function and does not itself exceed the required privilege boundary. The unsafe matching and modification strategy, however, affects cron entries outside the skill's ownership. ### Attack Path 1. The user already has an unrelated cron task whose command or path contains `watchdog.sh` or `watchdog`. 2. The user runs `scripts/setup-watchdog.sh`, or follows the documented removal command. 3. `grep -v` removes the unrelated entry along with the OpenClaw entry. 4. The modified cron table is installed without warning or backup. 5. The unrelated monitoring or maintenance task ceases to run, potentially concealing failures or causing service disruption. A local process that can race cron modifications could also arrange for legitimate concurrent changes to be overwritten. ### Impact Assessment The impact is limited t ...[truncated 252 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Install a uniquely marked cron entry, for example: ```cron # BEGIN OPENCLAW_GATEWAY_WATCHDOG * * * * * /home/user/.openclaw/watchdog.sh # END OPENCLAW_GATEWAY_WATCHDOG ``` - Remove only the exact command or the content between those unique markers. - Avoid generic filters such as `grep -v watchdog`. - Back up the current crontab before modification. - Generate the complete replacement in a secured temporary file and verify it before installation. - Prefer an idempotent installer that detects an exact existing entry and leaves all unrelated lines unchanged. - Provide a dedicated uninstall script using the same exact ownership markers. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/systemd.md:9
• Finding: Documented Systemd Watchdog Runs Persistently as Root Without Demonstrated Need<![CDATA[ ## Vulnerability Details **File Location**: `references/systemd.md`, lines 9-31 **Vulnerability Type**: Excessive privilege in a persistent service **Risk Level**: High ### Vulnerable Code ```ini [Service] Type=oneshot ExecStart=/root/.openclaw/watchdog.sh User=root [Timer] # /etc/systemd/system/openclaw-watchdog.timer [Unit] Description=Run OpenClaw Watchdog every minute [Timer] OnCalendar=*:0/1 Persistent=true [Install] WantedBy=timers.target ``` ```bash sudo systemctl enable openclaw-watchdog.timer sudo systemctl start openclaw-watchdog.timer ``` ### Technical Analysis The systemd alternative explicitly executes the watchdog as `root` every minute and enables it persistently across reboots. The declared functionality only requires access to the OpenClaw user's configuration and the ability to manage that user's gateway process. No requirement for unrestricted root access is established. The watchdog invokes multiple external programs and the `openclaw` CLI and can overwrite configuration files and stop or start processes. Running that logic as root magnifies any defect or compromise in the script, CLI, configuration handling, or dependency chain into root-level code execution or filesystem modification. The persistence mechanism itself is expected for a watchdog. The security issue is combining persistent scheduling with unrestricted root execution when a dedicated unprivileged account or user-level systemd timer would satisfy the stated purpose. ### Attack Path 1. An administrator follows the documentation and places the watchdog under `/root/.openclaw/watchdog.sh`. 2. The administrator enables the timer with `sudo systemctl enable`. 3. Systemd executes the script as root every minute and after reboot because `Persistent=true` is configured. 4. If the script or any executable it invokes is subsequently replaced, compromised, or resolved from an unsafe execution path, the injected behavior runs automatically as root. 5. The compromise pe ...[truncated 738 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Use a user-level systemd service and timer under `~/.config/systemd/user/`. - Run the service as the same dedicated, unprivileged account that owns the OpenClaw gateway and configuration. - If a system service is unavoidable, define a dedicated account and apply hardening such as: ```ini User=openclaw Group=openclaw NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ReadWritePaths=/home/openclaw/.openclaw RestrictSUIDSGID=true LockPersonality=true ``` - Use absolute paths for every executable invoked by the watchdog and set a fixed, minimal `PATH`. - Restrict ownership and permissions on the watchdog script and configuration. - Document disablement and removal commands alongside installation. - Separate the service and timer examples into valid, clearly named files to reduce configuration mistakes. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/setup-watchdog.sh:50
• Finding: Broad Process Matching and Single-Sample Health Checks Can Trigger Incorrect Recovery Actions<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup-watchdog.sh`, lines 50-94 **Vulnerability Type**: Unsafe process detection and destructive recovery logic **Risk Level**: Medium ### Vulnerable Code ```bash # Level 1: Process check if ! pgrep -f "openclaw" > /dev/null 2>&1; then log "LEVEL1: Gateway process not found → restarting" openclaw gateway start >> "$LOG" 2>&1 sleep 5 if pgrep -f "openclaw" > /dev/null 2>&1; then log "LEVEL1: Restart successful" else log "LEVEL1: Restart failed → trying config rollback" # Fall through to Level 2 fi fi # Level 2: Health check (process alive but possibly broken) if pgrep -f "openclaw" > /dev/null 2>&1; then HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "http://localhost:$HEALTH_PORT/health" --max-time 10 2>/dev/null || echo "000") if [ "$HTTP_CODE" = "200" ]; then # Healthy → update backup with current good config cp "$CONF" "$BAK" # Silent success, no log spam exit 0 fi # Health check failed log "LEVEL2: Health check failed (HTTP $HTTP_CODE)" if [ -f "$BAK" ]; then # Save broken config for debugging cp "$CONF" "$CONF.broken.$(date +%s)" # Rollback to last known good cp "$BAK" "$CONF" log "LEVEL2: Config rolled back from backup" ``` ### Technical Analysis `pgrep -f "openclaw"` searches complete command lines for a generic substring. It does not verify the gateway's executable, arguments, PID file, ownership, or service identity. It can match unrelated OpenClaw commands, attacker-created processes, and potentially command lines containing the `.openclaw` directory or watchdog path. The recovery decision is then based on one HTTP request. A single timeout, temporary startup delay, overloaded gateway, or transient local networking failure is interpreted as configuration corruption. The script immediately preserves the current configuration, replaces it with the backup, and restarts the gateway. There is no re ...[truncated 1554 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Identify the gateway through a trusted PID file, exact executable path, systemd unit state, or strict command-line pattern tied to the expected user. - Verify the PID owner and executable through `/proc/<pid>/exe` on Linux or an equivalent platform API. - Require multiple consecutive health-check failures before rollback. - Add a startup grace period and distinguish connection failures from application-level authentication or configuration failures. - Validate the backup before restoration and compare configuration versions or hashes. - Attempt a non-destructive restart before rolling back configuration unless there is direct evidence of configuration corruption. - Correct curl status handling, for example: ```bash if ! HTTP_CODE=$(/usr/bin/curl -sS -o /dev/null -w '%{http_code}' \ --max-time 10 "http://127.0.0.1:${HEALTH_PORT}/health"); then HTTP_CODE="000" fi ``` - Add an exclusive lock so only one watchdog instance can perform recovery at a time. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/setup-watchdog.sh:77
• Finding: Unbounded Broken-Configuration Archives Permit Disk Exhaustion and Retain Sensitive Data<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup-watchdog.sh`, lines 77-81 **Vulnerability Type**: Unbounded file creation and sensitive configuration retention **Risk Level**: Medium ### Vulnerable Code ```bash if [ -f "$BAK" ]; then # Save broken config for debugging cp "$CONF" "$CONF.broken.$(date +%s)" # Rollback to last known good ``` The generated watchdog is scheduled every minute: ```bash CRON_JOB="* * * * * $WATCHDOG" ``` ### Technical Analysis Every failed health check creates a complete timestamped copy of `openclaw.json`. There is no file-count limit, age-based cleanup, total-size quota, or deduplication. A persistent failure can therefore produce approximately one additional copy per minute. Configuration files may contain authentication material, service endpoints, or other sensitive settings. Retaining every failed version unnecessarily increases the number and lifetime of sensitive artifacts. The script also does not explicitly enforce restrictive permissions on the generated copies, relying on existing file modes and the user's environment. ### Attack Path 1. The gateway process is considered present and its health check repeatedly fails. 2. Cron invokes the watchdog every minute. 3. Each invocation copies the full configuration to a new `.broken.<timestamp>` file. 4. The files accumulate indefinitely. 5. Over time, the user's filesystem or quota can be exhausted, disrupting OpenClaw and other applications. 6. Any account or process with read access to the directory gains additional opportunities to recover historical configuration secrets. A local attacker who can keep the health endpoint unavailable can accelerate this condition, but ordinary persistent service failure is sufficient. ### Impact Assessment The primary impact is denial of service through disk or quota exhaustion. Secondary impact includes unnecessary retention and potential disclosure of historical configuration secrets. The scope normall ...[truncated 113 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Retain a small fixed number of broken configurations, such as the most recent three. - Delete artifacts older than a documented retention period. - Avoid creating a new archive when its hash matches the latest archived failure. - Set a restrictive umask before creating backups: ```bash umask 077 ``` - Explicitly set backup ownership and mode to match the protected source. - Consider redacting credentials from diagnostic copies where feasible. - Monitor available disk space and stop creating archives below a safe threshold. - Use a single rotating recovery snapshot if historical copies are not operationally required. ]]>

T08 · Insecure Dependencies

Warning

• Location: references/docker.md:3
• Finding: Docker Example Installs an Unpinned Package as Root<![CDATA[ ## Vulnerability Details **File Location**: `references/docker.md`, lines 3-4 **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```dockerfile FROM node:22-slim RUN npm i -g openclaw ``` ### Technical Analysis The Docker example installs the latest package published under the `openclaw` name without pinning an exact version or verifying integrity. Package behavior can therefore change between builds without any project change. NPM lifecycle scripts execute during installation, and the installation occurs as the image's default root user. The base image is also selected by a mutable tag rather than an immutable digest. A compromised package release, registry account, dependency, or changed base tag could introduce code into future images after this skill has been reviewed. There is no evidence in the audited project that the package is currently malicious. The finding concerns the absence of supply-chain controls. ### Attack Path 1. The upstream package, one of its transitive dependencies, or its publishing account is compromised. 2. A malicious version becomes the version resolved by `npm i -g openclaw`. 3. A user rebuilds the documented Dockerfile. 4. NPM downloads the changed package and executes any lifecycle scripts as root during the image build. 5. Malicious files or startup behavior are embedded into the resulting image. 6. The image is subsequently run with `--restart=always`, causing the compromised application to execute persistently whenever the container starts. Build-time access is initially scoped to the build environment, but embedded payloads execute with the container's runtime permissions and access to the mounted `openclaw-data` volume. ### Impact Assessment A compromised dependency could alter the image, steal build-time data available to it, access the container's persistent OpenClaw volume at runtime, or execute arbitrary code inside the container. Host impact ...[truncated 99 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin `openclaw` to an audited exact version rather than installing the latest release. - Use a lockfile where supported and verify package integrity or provenance. - Pin the base image by digest, for example `node:22-slim@sha256:<audited-digest>`. - Build in a controlled environment and scan the resulting image and dependency tree. - Disable lifecycle scripts when they are not required, or separately audit all required scripts. - Use a multi-stage build and run the final application as a dedicated non-root user. - Establish an update process that reviews and tests dependency changes before changing pinned versions. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (24)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The skill advertises autonomous backup, rollback, restart, and recovery behavior, but the visible file only provides descriptive claims and manual commands. This mismatch is dangerous because users and orchestration systems may trust the skill to provide self-healing safeguards that do not actually exist, leading to unsafe changes, failed recovery, or false assurance during outages.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 96% confidence
• Finding: The skill clearly instructs the agent to run shell commands and install persistence via scripts and cron, but it declares no tool scope or permissions boundary. That creates an authorization gap where a model or runner could invoke system-changing shell behavior without the skill explicitly constraining or signaling those capabilities.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The trigger phrases include broad operational language such as watchdog, self-heal, gateway down, and config recovery, which can match many routine troubleshooting requests. Over-broad activation can cause this skill to be selected in contexts where the user did not intend persistence, restart behavior, or config manipulation, increasing the chance of unsafe system actions.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The markdown instructs installation of a cron-based watchdog, automatic rollback, restart behavior, and config backup without clearly warning that these actions alter system persistence, may overwrite backups, and can revert configuration unexpectedly. In a system-management context, omission of impact warnings increases the risk of accidental disruption, loss of desired config changes, or unauthorized persistence on the host.

Session Persistence

Medium

• Category: Rogue Agent

Content

```

This will:
- Create the watchdog script at `~/.openclaw/watchdog.sh`
- Register it as a cron job (every minute)
- Take an initial config backup

• Confidence: 91% confidence
• Finding: Creating ~/.openclaw/watchdog.sh and registering it as a cron job creates a persistent execution path that continues outside the immediate interaction. In the context of an agent skill, this is sensitive because it writes executable content and schedules recurring execution, which can be abused or cause unintended long-lived changes if selected in the wrong context.

Session Persistence

Medium

• Category: Rogue Agent

Content

cat ~/.openclaw/watchdog.log | tail -20

# Disable watchdog
crontab -l | grep -v watchdog | crontab -
```

## Recovery Levels

• Confidence: 88% confidence
• Finding: The skill includes commands to manipulate crontab entries, which establishes or removes persistent scheduled execution on the host. Even though the stated purpose is operational maintenance, persistence mechanisms are security-sensitive because they can survive the session and continue executing without ongoing user awareness.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Session Persistence

Medium

• Category: Rogue Agent

Content

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>

• Confidence: 75% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>

• Confidence: 75% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>

• Confidence: 75% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>

• Confidence: 75% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>

• Confidence: 75% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>

• Confidence: 75% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
# Replace USERNAME in the plist first
sed -i '' "s/USERNAME/$(whoami)/g" ~/Library/LaunchAgents/ai.openclaw.watchdog.plist

launchctl load ~/Library/LaunchAgents/ai.openclaw.watchdog.plist
```

• Confidence: 75% confidence
• Finding: Loading a LaunchAgent establishes persistent automatic execution at login, which can be abused if the referenced `watchdog.sh` is modified, unsafe, or attacker-controlled. In this skill context the persistence is intentional and operationally justified, but it still increases attack surface because any compromise of the script or its writable directory will execute repeatedly without further prompts.

Session Persistence

Medium

• Category: Rogue Agent

Content

# Replace USERNAME in the plist first
sed -i '' "s/USERNAME/$(whoami)/g" ~/Library/LaunchAgents/ai.openclaw.watchdog.plist

launchctl load ~/Library/LaunchAgents/ai.openclaw.watchdog.plist
```

• Confidence: 84% confidence
• Finding: `launchctl load` activates persistent execution of the watchdog from the user's LaunchAgents directory, creating a durable foothold if the underlying script is unsafe or later tampered with. Although the stated purpose is benign self-healing, persistence mechanisms are security-relevant because they can be repurposed for unauthorized code execution within the user session.

Session Persistence

Medium

• Category: Rogue Agent

Content

# Replace USERNAME in the plist first
sed -i '' "s/USERNAME/$(whoami)/g" ~/Library/LaunchAgents/ai.openclaw.watchdog.plist

launchctl load ~/Library/LaunchAgents/ai.openclaw.watchdog.plist
```

• Confidence: 84% confidence
• Finding: `launchctl load` activates persistent execution of the watchdog from the user's LaunchAgents directory, creating a durable foothold if the underlying script is unsafe or later tampered with. Although the stated purpose is benign self-healing, persistence mechanisms are security-relevant because they can be repurposed for unauthorized code execution within the user session.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```

```bash
sudo systemctl enable openclaw-watchdog.timer
sudo systemctl start openclaw-watchdog.timer
```

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```

```bash
sudo systemctl enable openclaw-watchdog.timer
sudo systemctl start openclaw-watchdog.timer
```

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Session Persistence

Medium

• Category: Rogue Agent

Content

```

```bash
sudo systemctl enable openclaw-watchdog.timer
sudo systemctl start openclaw-watchdog.timer
```

• Confidence: 80% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

CRON_JOB="* * * * * $WATCHDOG"

# Remove existing watchdog cron if any
(crontab -l 2>/dev/null | grep -v "watchdog.sh") | crontab -

# Add new cron job
(crontab -l 2>/dev/null; echo "$CRON_JOB") | crontab -

• Confidence: 92% confidence
• Finding: The script installs a cron entry that runs every minute, creating persistence on the host without additional confirmation or scoping. Although this appears intended for legitimate watchdog functionality, persistence mechanisms are security-relevant because they survive the initiating session and can be abused if the script path or watched files are later modified.

Session Persistence

Medium

• Category: Rogue Agent

Content

(crontab -l 2>/dev/null | grep -v "watchdog.sh") | crontab -

# Add new cron job
(crontab -l 2>/dev/null; echo "$CRON_JOB") | crontab -
echo "✅ Cron 등록 완료 (매분 실행)"

# 5. Initial run

• Confidence: 92% confidence
• Finding: Adding the watchdog script to crontab every minute establishes automatic recurring execution, which is a classic persistence behavior. In this skill context the intent is operational resilience, but the mechanism still increases attack surface because any compromise of the referenced script or environment yields repeated code execution.

Session Persistence

Medium

• Category: Rogue Agent

Content

echo "=========================="

# Cron registered?
if crontab -l 2>/dev/null | grep -q "watchdog.sh"; then
  echo "✅ Cron: 등록됨 (매분 실행)"
else
  echo "❌ Cron: 미등록"

• Confidence: 85% 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

echo "=========================="

# Cron registered?
if crontab -l 2>/dev/null | grep -q "watchdog.sh"; then
  echo "✅ Cron: 등록됨 (매분 실행)"
else
  echo "❌ Cron: 미등록"

• Confidence: 85% 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.

Natural-Language Policy Violations

Low

• Confidence: 98% confidence
• Finding: Several user-facing status messages are written in Korean, and the script does not provide any opt-in, configuration, or explanation for this locale choice. This can violate language/locale policy when users are not given a choice and the region-specific constraint is not documented.

Static analysis

No suspicious patterns detected.