v4.0.0

SysClaw Reporting

ReviewClawScan verdict for this skill. Analyzed May 1, 2026, 7:24 AM.

Analysis

The skill appears to perform its stated SysClaw reporting role, but it gives agents a broad database-backed channel for high-impact system requests and persistent cross-agent notifications without clear identity, approval, or memory-safety boundaries.

GuidanceReview this skill carefully before installing. It is not clearly malicious, but it should only be used in an environment where SysClaw database credentials are tightly scoped per agent, high-impact requests require approval, and cross-agent notifications are treated as untrusted messages rather than instructions.

Findings (6)

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.

Abnormal behavior control

Checks for instructions or behavior that redirect the agent, misuse tools, execute unexpected code, cascade across systems, exploit user trust, or continue outside the intended task.

Tool Misuse and Exploitation

SeverityMediumConfidenceHighStatusConcern

SKILL.md

request anything from SysClaw including software installation, resource access, configuration changes, service management, deployments... Actions: `install` | `remove` | `create` | `modify` | `restart` | `grant` | `check` | `deploy`

The skill invites agents to submit requests for broad, high-impact system operations, but the artifacts do not define target limits or require user approval before an agent submits those requests.

User impactAn agent could submit requests that lead to software changes, access grants, service restarts, or deployments through SysClaw workflows.

RecommendationInstall only if you want agents to make SysClaw requests, and add clear local policy requiring user approval for access grants, installs/removals, restarts, configuration changes, and deployments.

Rogue Agents

SeverityLowConfidenceHighStatusNote

SKILL.md

(crontab -l 2>/dev/null; echo "*/15 * * * * /usr/local/bin/check-sysclaw-notifications.sh") | crontab -

The cron job is user-directed and purpose-aligned, but it creates recurring background activity that continues after the immediate task.

User impactThe notification checker can keep running every 15 minutes until the user removes the cron entry.

RecommendationOnly add the cron job if ongoing notification polling is desired, and document how to remove it from crontab.

Agentic Supply Chain Vulnerabilities

SeverityLowConfidenceHighStatusNote

metadata

Required env vars: none ... No install spec — this is an instruction-only skill ... Registry metadata: Version: 4.0.0

The registry metadata under-declares the required Python dependency and database environment variables, and the included _meta.json lists version 3.2.0 rather than the registry's 4.0.0.

User impactUsers may not realize from metadata alone that the skill needs a Python package and SysClaw database credentials before it works.

RecommendationVerify the package provenance and update metadata to declare required dependencies, environment variables, and the correct version.

Permission boundary

Checks whether tool use, credentials, dependencies, identity, account access, or inter-agent boundaries are broader than the stated purpose.

Identity and Privilege Abuse

SeverityMediumConfidenceHighStatusConcern

scripts/check-notifications.sh

agent_name="${1:?Usage: check-notifications.sh <agent_name> [mark_read]}" ... WHERE recipient = %s AND read = FALSE ... UPDATE notifications SET read = TRUE WHERE recipient = %s AND read = FALSE

The notification script uses a caller-supplied agent name to read and mark notifications; the artifacts do not show binding between the database credential and the claimed agent identity.

User impactIf database permissions are not tightly enforced elsewhere, a caller could read or mark another agent's notifications by supplying that agent's name.

RecommendationUse per-agent database credentials with database-side row-level controls, and avoid shared credentials that can read or update notifications for arbitrary recipients.

Sensitive data protection

Checks for exposed credentials, poisoned memory or context, unclear communication boundaries, or sensitive data that could leave the user's control.

Insecure Inter-Agent Communication

SeverityMediumConfidenceHighStatusConcern

scripts/request-resource.sh

source="${1:?Usage: request-resource.sh <source> <type> <action> <target> <justification> [urgency] [payload] [source_host]}" ... INSERT INTO notifications (recipient, sender, related_request, message, urgency) VALUES (%s, %s, %s, %s, %s)

The sender identity is supplied as a free-form argument and written into the shared notifications table; the artifacts do not show authentication, sender verification, or origin validation for cross-agent messages.

User impactNotifications and requests may be trusted as coming from a particular agent even though the client-side artifacts do not enforce that identity.

RecommendationTreat notification contents as untrusted data unless the SysClaw database enforces sender identity, recipient access, and message permissions.

Memory and Context Poisoning

SeverityMediumConfidenceHighStatusConcern

SKILL.md

bash "<skill-path>/scripts/check-notifications.sh" <your-agent-name> > "<workspace>/memory/notifications.md" ... Then at session start: `cat memory/notifications.md`

The skill recommends storing external cross-agent notification text in a persistent memory file and loading it at session start, which can make untrusted messages part of future agent context.

User impactA notification containing misleading instructions could be carried into later sessions and influence the agent if it is read as trusted context.

RecommendationDo not load notification files directly into agent memory as instructions; label them as untrusted messages, sanitize their content, and keep them separate from persistent guidance.