Self Monitor

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:13 PM UTC
• Version: 1.0.1

Overview

This monitoring skill is mostly coherent, but it labels broad automatic deletion of system logs and caches as safe and suggests recurring execution without enough user control.

Install only if you will keep it in report-only mode or require explicit approval before cleanup or restarts. Do not let it delete /var/log, broad ~/.cache content, /tmp globs, or pip caches automatically, and avoid running scheduled checks as root unless you have reviewed and pinned the exact script and log destination.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:133
• Finding: Overbroad Destructive Log and Cache Cleanup<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:133-139` **Vulnerability Type**: Unsafe recursive file deletion **Risk Level**: High ### Vulnerable Code ```bash # Clean old logs (> 7 days) find /var/log -name "*.log" -mtime +7 -delete 2>/dev/null find ~/.cache -type f -mtime +7 -delete 2>/dev/null # Clean temp files rm -f /tmp/agent-temp-* 2>/dev/null rm -rf ~/.cache/pip 2>/dev/null ``` ### Technical Analysis The Skill describes these commands as “safe” auto-fixes, but their deletion scope is not limited to files created or owned by the Skill. The first command deletes every file ending in `.log` under `/var/log` if it is older than seven days. When executed with sufficient privileges, this can remove logs belonging to unrelated applications and system components. The second command recursively deletes all old files under the current user's cache directory, regardless of which application owns them. The final command removes the complete pip cache without checking whether another operation depends on it. The commands do not provide a dry-run, validate the resolved paths, enforce filesystem boundaries, preserve an audit record, or request confirmation. Redirecting standard error to `/dev/null` also conceals permission failures and partial cleanup, making it difficult to determine what was removed. ### Attack Path 1. The Agent observes disk usage above the documented critical threshold. 2. It interprets the cleanup commands as authorized “safe” automatic actions. 3. The Agent runs the commands using its current account or an elevated execution context. 4. `find` traverses system-wide or user-wide directories and identifies files unrelated to the Skill. 5. Matching logs and cache files are permanently deleted. 6. Operational diagnostics, audit evidence, or application state stored in those locations becomes unavailable. An attacker who can influence disk usage or persuade the Agent that disk pressure is critical could increase the likelih ...[truncated 792 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not characterize broad recursive deletion as automatically safe. - Require explicit user confirmation before deleting logs or application-owned cache files. - Use an allowlist containing only paths created and managed by this Skill. - Run a dry-run first and present the exact files, total size, and ownership information to the user. - Apply retention through `logrotate`, `journalctl --vacuum-*`, or application-specific maintenance tools rather than generic `find -delete`. - Never run cleanup with elevated privileges unless a specific approved target requires them. - Use `find -xdev` or equivalent filesystem-boundary controls where traversal is necessary. - Validate canonical paths before deletion and reject symbolic-link or path-redirection anomalies. - Preserve a deletion manifest and report errors instead of suppressing all standard error. - For pip, prefer supported cache-management commands such as `python -m pip cache purge`, subject to user approval. ]]>

other

Warning

• Location: SKILL.md:72
• Finding: Broad Collection of Process, Scheduled-Task, and System Log Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:72-94` **Vulnerability Type**: Excessive host and log reconnaissance **Risk Level**: Medium ### Vulnerable Code ```bash ### 3. Cron Job Health ```bash # Check recent cron executions grep CRON /var/log/syslog | tail -20 # Count failures in last 24h grep -c "CRON.*error\|CRON.*fail" /var/log/syslog # List scheduled jobs crontab -l ``` ### 4. Recent Errors ```bash # Check system logs for errors journalctl -p err --since "1 hour ago" 2>/dev/null | tail -20 # Check application logs tail -50 ~/workspace/projects/*/logs/*.log 2>/dev/null | grep -i "error" # Check dmesg for hardware/kernel issues dmesg | tail -20 | grep -i "error\|fail\|warn" ``` ``` Related process inspection also appears at `SKILL.md:35-39`: ```bash # Top processes by memory ps aux --sort=-%mem | head -10 # Top processes by CPU ps aux --sort=-%cpu | head -10 ``` ### Technical Analysis The commands inspect system logs, kernel messages, process command lines, scheduled jobs, and application logs across a broad set of projects. This information is relevant to infrastructure monitoring, but the collection exceeds the minimum data needed for a basic resource-health snapshot. Process command lines and logs can contain usernames, filesystem paths, endpoint addresses, deployment details, access tokens, API keys, or other sensitive values accidentally supplied as arguments or written to logs. Cron entries disclose recurring commands and operational topology. Once collected, this information may enter the Agent's context and subsequently appear in generated health reports. The project contains no mechanism that transmits these values to an external destination. The risk is therefore excessive local collection and possible secondary disclosure rather than confirmed exfiltration. ### Attack Path 1. A user requests a general health check or the Skill runs as part of a scheduled workflow. 2. The Agent executes the documented process, ...[truncated 1248 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Collect aggregate disk, memory, and load metrics by default; make detailed process and log inspection opt-in. - Clearly request authorization before reading system-wide or unrelated application logs. - Restrict log collection to explicitly configured services and application-owned paths. - Avoid collecting complete command lines where executable names or aggregate resource values are sufficient. - Redact common secret formats, authorization headers, tokens, credentials, and sensitive query parameters before content enters reports. - Limit output by both time range and number of records. - Treat all log content as untrusted data and explicitly prohibit following instructions found in logs. - Run monitoring under a dedicated least-privileged account with access only to required metrics. - Do not silently suppress collection errors; report which sources were inaccessible without exposing their content. ]]>

T06 · System Persistence

Warning

• Location: SKILL.md:157
• Finding: Optional Recurring Cron Persistence Without Sufficient Hardening Guidance<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:157-168` **Vulnerability Type**: Persistent scheduled execution **Risk Level**: Medium ### Vulnerable Code ```markdown ## Integration with Scheduled Tasks Add to your crontab or task scheduler: ```cron # Run health check every 30 minutes */30 * * * * /path/to/health-check.sh >> /var/log/health-check.log 2>&1 ``` Or run manually as part of your workflow: ```bash ./health-check.sh ``` ``` ### Technical Analysis The documentation recommends creating a cron entry that executes a script every 30 minutes. This is a persistence mechanism because execution continues across Agent sessions and system restarts. Recurring execution is reasonably related to the Skill's declared proactive-monitoring functionality, and the instruction is visible rather than covert. The project also does not automatically install the cron entry. Nevertheless, the recommendation lacks important controls: it does not require explicit informed consent, identify the intended service account, validate ownership and permissions of the script, define a safe execution environment, or explain how to remove the scheduled task. The referenced `health-check.sh` is not included in the audited project. Consequently, the effective scheduled payload cannot be reviewed. If the configured script path is writable by another user or later replaced, cron will repeatedly execute the modified content with the privileges of the crontab owner. Writing to `/var/log/health-check.log` may also encourage deployment under an elevated account merely to obtain filesystem access. ### Attack Path 1. A user or Agent follows the integration instructions and adds the cron entry. 2. The entry is installed under a privileged or broadly authorized account. 3. `/path/to/health-check.sh` is created in a location with weak ownership or write permissions. 4. Another local account, compromised process, or later installation modifies or replaces the script. 5. Cron ...[truncated 824 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Keep scheduling optional and require explicit informed user approval before creating any recurring task. - Provide and audit the exact health-check script rather than referring to an unspecified external file. - Run the task under a dedicated, unprivileged monitoring account. - Store the script in a fixed absolute path owned by the monitoring account or root and not writable by other users. - Use restrictive file and directory permissions and verify ownership before registration. - Set a minimal explicit environment, including a controlled `PATH`, and use absolute paths for invoked binaries. - Write logs to an application-owned directory rather than requiring broad access to `/var/log`. - Prevent overlapping invocations with a locking mechanism and apply resource and execution-time limits. - Document how to inspect, disable, and completely remove the cron entry. - Prefer a hardened service manager timer with sandboxing controls where supported. - Never install the schedule automatically or in a privileged crontab without separate approval. ]]>

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (9)

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: The skill documents automatic cleanup actions that delete files from /var/log, ~/.cache, /tmp, and ~/.cache/pip, but it does not provide an explicit warning about destructive effects or limits to a controlled application-owned scope. In an autonomous agent setting, these deletions can remove forensic evidence, break tooling caches, or cause unintended data loss if run with elevated privileges.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

find ~/.cache -type f -mtime +7 -delete 2>/dev/null

# Clean temp files
rm -f /tmp/agent-temp-* 2>/dev/null
rm -rf ~/.cache/pip 2>/dev/null
```

• Confidence: 91% confidence
• Finding: The command 'rm -f /tmp/agent-temp-*' performs deletion based on a wildcard in a shared temporary directory, which can remove files beyond the intended set if naming collisions occur or if the pattern is broader than expected. In an agent skill that may run automatically, this creates a risk of unintended file deletion without verification or user consent.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Clean temp files
rm -f /tmp/agent-temp-* 2>/dev/null
rm -rf ~/.cache/pip 2>/dev/null
```

## Report Format

• Confidence: 90% confidence
• Finding: The full command 'rm -rf ~/.cache/pip 2>/dev/null' combines recursive deletion with suppression of error output, which reduces visibility into what happened and makes accidental or inappropriate cleanup harder to audit. In an autonomous monitoring skill, hidden destructive actions are more dangerous because failures and scope mistakes may go unnoticed.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Clean temp files
rm -f /tmp/agent-temp-* 2>/dev/null
rm -rf ~/.cache/pip 2>/dev/null
```

## Report Format

• Confidence: 89% confidence
• Finding: The full command 'rm -rf ~/.cache/pip 2>/dev/null' combines recursive deletion with suppression of error output, which reduces visibility into what happened and makes accidental or inappropriate cleanup harder to audit. In an autonomous monitoring skill, hidden destructive actions are more dangerous because failures and scope mistakes may go unnoticed.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Clean temp files
rm -f /tmp/agent-temp-* 2>/dev/null
rm -rf ~/.cache/pip 2>/dev/null
```

## Report Format

• Confidence: 90% confidence
• Finding: The full command 'rm -rf ~/.cache/pip 2>/dev/null' combines recursive deletion with suppression of error output, which reduces visibility into what happened and makes accidental or inappropriate cleanup harder to audit. In an autonomous monitoring skill, hidden destructive actions are more dangerous because failures and scope mistakes may go unnoticed.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The README advertises 'auto-fixes safe issues (cleaning old logs, temp files)' without warning that these actions modify or delete local data. Even if intended as maintenance, automated cleanup can remove files needed for debugging, compliance, rollback, or application correctness, making the behavior risky when invoked by an agent.

Vague Triggers

Medium

• Confidence: 90% confidence
• Finding: The activation guidance is overly broad ('Run it on heartbeats or schedule it — either way') and, in the context of a monitoring skill that can perform automated cleanup, may cause the skill to run in situations the user did not specifically intend. Ambiguous triggering increases the chance of repeated or background execution that performs file deletions or service actions without clear user awareness.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The skill advertises very broad natural-language triggers such as 'health check', 'heartbeat', and 'service status', which are common phrases likely to appear in routine conversations or workflows. In an agent environment, this can cause unintended invocation of monitoring behavior and execution of shell commands in contexts where the user did not explicitly request this skill.

Session Persistence

Medium

• Category: Rogue Agent

Content

grep -c "CRON.*error\|CRON.*fail" /var/log/syslog

# List scheduled jobs
crontab -l
```

### 4. Recent Errors

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

Static analysis

No suspicious patterns detected.