Sysclaw Ops

SysClaw operator skill for processing agent requests and managing the cross-agent communication system. Use when SysClaw needs to check for pending agent req...

Security Scan

The SKILL.md describes a server-side operator that legitimately needs database credentials and messaging access, but the registry metadata does not declare any required env vars and the instructions grant broad execution abilities (DB writes, SSH/command execution, cron creation) without clearly specifying how credentials/privileges are provided or limited.

Purpose & Capability

The skill's stated purpose (server-side SysClaw operator) reasonably requires DB credentials and a Telegram token; the SKILL.md explicitly lists SYSCLAW_DB_* and a Telegram bot token. However the registry metadata declares no required env vars or primary credential — a clear mismatch. The SKILL.md also describes capabilities beyond simple notification handling (executing approved requests such as installs, config edits, restarts) that imply SSH or elevated system privileges; those access needs are not declared in the registry.

Instruction Scope

SKILL.md instructs the agent to read/write multiple DB tables, process verdicts, write security assessments, and (when approving requests) execute actions on infrastructure. It assumes the agent session has access to SSH and DB tools and describes creating an OpenClaw cron job. This grants the runtime the ability to execute arbitrary commands on hosts based on DB records/payloads — a high-impact operation. The docs also contain inconsistent terminology (resolvers/escalation fields referencing 'virus' in places), suggesting sloppy editing and potential hidden assumptions.

Install Mechanism

Instruction-only skill with no install spec and no code files reduces surface area for supply-chain installs. No downloads or package installs are requested by the skill itself.

Credentials

SKILL.md requests a full set of DB credentials (host, port, db name, user, password) and a Telegram token; it also requires DB privileges that include UPDATE on verdict/status columns and INSERT on notifications — significant write privileges. The registry metadata, however, lists no required env vars, so callers would not be warned about providing these secrets. The SKILL.md also implies need for SSH/session access but does not declare how keys/credentials are supplied or limited. The combination (DB write + potential remote command execution + messaging token) is high privilege and should be justified and constrained.

Persistence & Privilege

always:false (normal), but the skill documents creating an OpenClaw cron job that will run periodically with access to DB and SSH tools. Periodic autonomous runs plus broad execution power increases blast radius even though 'always' isn't set. Verify who can create/approve such cron jobs and whether the cron job will run with least privilege.

What to consider before installing

Do not enable this skill in production until you confirm the missing pieces and harden privileges. Specific checks: (1) Ask the publisher why registry metadata declares no required env vars while SKILL.md requires DB creds and a Telegram token. (2) Require a dedicated DB role with the minimal GRANTS listed, verify those grants in your DB, and ensure the role cannot run arbitrary SQL beyond the intended updates. (3) Confirm how SSH/command execution is performed — prefer ephemeral jump-host sessions or human-approved runbooks rather than automatic execution based on DB payloads. (4) Require OpenClaw cron job creation to be approved by an operator and limit its session capabilities. (5) Verify secure storage/rotation of the Telegram token and that escalations require human approval for high-risk actions. (6) Ask for the concrete implementation (code or agent session policy) to audit parameterized queries, input validation (avoid executing commands derived from untrusted payloads), and logging/immutable audit trails. The presence of leftover 'virus' strings and metadata mismatches is a quality signal — request publisher clarification before trusting the skill.

SysClaw Ops (Server)

Server-side operations for the cross-agent communication system. This skill covers how SysClaw processes incoming requests, manages notifications, and communicates with agents.

Required Credentials

Credential	Purpose	Minimal Privileges
SYSCLAW_DB_HOST	PostgreSQL host (MB-ClawTool-01)	Network access to port 5432
SYSCLAW_DB_PORT	PostgreSQL port (5432)	—
SYSCLAW_DB_NAME	Database name (system_comm)	CONNECT privilege
SYSCLAW_DB_USER	DB role for SysClaw	See privileges below
SYSCLAW_DB_PASSWORD	DB password	—
Telegram bot token	For escalating urgent requests to the human operator	Configured via OpenClaw

Minimal DB privileges required:

-- agent_requests table
GRANT SELECT, UPDATE (verdict, security_assessment, resolved_at, resolved_by, escalated, escalation_reason)
  ON agent_requests TO <sysclaw_role>;

-- issues table
GRANT SELECT, UPDATE (status, resolved_at, resolved_by) ON issues TO <sysclaw_role>;

-- notifications table
GRANT SELECT, INSERT, UPDATE (read) ON notifications TO <sysclaw_role>;

Installation

This skill is designed for the SysClaw operator (an OpenClaw agent running on the server that manages infrastructure). It is not a standalone daemon.

Components

1. This SKILL.md — Instructions for the SysClaw agent on processing requests
2. OpenClaw cron job — sysclaw-notification-check (see below)
3. Telegram integration — Via OpenClaw's session delivery to the human operator

Cron Job Setup

The sysclaw-notification-check is an OpenClaw cron job, not a system binary. It runs as an isolated agent session within OpenClaw:

{
  "name": "sysclaw-notification-check",
  "schedule": { "kind": "cron", "expr": "*/15 * * * *", "tz": "Europe/Copenhagen" },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "Check for new agent notifications and process requests. Use sysclaw-ops skill for workflow.",
    "timeoutSeconds": 120
  },
  "delivery": { "mode": "announce" }
}

Created via OpenClaw cron API. The agent session has access to SSH and DB tools — no separate binary needed.

Telegram Integration

Escalated requests are flagged in the database by the cron job. SysClaw checks for escalated requests during its normal session workflow and notifies the human operator on Telegram using OpenClaw's messaging. The cron job itself does not send Telegram messages.

Database Tables

agent_requests — Requests from agents

Column	Type	Notes
id	serial	PK
requesting_agent	varchar(50)	Agent name
request_type	varchar(30)	access, software, resource, config, service, deployment, info
action	varchar(30)	install, remove, create, modify, restart, grant, check, deploy
target	varchar(255)	What this applies to
justification	text	Why it's needed
payload	jsonb	Request-specific details
urgency	varchar(20)	low, normal, urgent
verdict	varchar(20)	pending → approved
security_assessment	text	SysClaw writes risk analysis
escalated	boolean	Whether the human operator was notified
created_at	timestamp
resolved_at	timestamp	Set by SysClaw
resolved_by	varchar(50)	sysclaw or the human operator
source_host	varchar(100)	Originating machine

issues — Issues reported by agents

Column	Type	Notes
id	serial	PK
source	varchar(50)	Agent name
severity	varchar(20)	info, warning, critical
category	varchar(50)	disk, service, error, resource, network, config, other
title	varchar(255)	Short description
details	text	Extended context
status	varchar(20)	open → resolved
created_at	timestamp
source_host	varchar(100)	Originating machine

notifications — Agent ↔ SysClaw communication

Column	Type	Notes
id	serial	PK
recipient	varchar(50)	Agent name or 'sysclaw'
sender	varchar(50)	Who sent it
related_request	integer	FK → agent_requests(id)
message	text	Notification content
urgency	varchar(20)	low, normal, urgent
read	boolean	Whether recipient has processed it
created_at	timestamp

worklog — SysClaw action log

Column	Type	Notes
id	serial	PK
request_id	integer	FK → agent_requests(id)
action	varchar(50)	What was done
target	varchar(255)	Where it was done
executed_by	varchar(50)	sysclaw or agent name
command	text	Command or action taken
result	text	Outcome
status	varchar(20)	in_progress, completed, failed, verified
started_at	timestamp
completed_at	timestamp

Full schema reference: See references/db-schema.md for detailed column constraints, indexes, role permissions, and status flows.

Processing Workflow

Check for new notifications

SELECT * FROM notifications WHERE recipient = 'sysclaw' AND read = FALSE ORDER BY created_at ASC;

Process a pending request

Agents submit requests because they can't do it themselves. When SysClaw approves, SysClaw executes.

Note: These queries show the pattern. Use parameterized queries or your agent's DB tooling — never interpolate values directly.

-- 1. Read the request
SELECT * FROM agent_requests WHERE id = <request_id>;

-- 2. Assess and update verdict
UPDATE agent_requests
SET verdict = 'approved',
    security_assessment = 'Low risk: standard package install on managed VM',
    resolved_at = NOW(),
    resolved_by = 'sysclaw'
WHERE id = <request_id>;

-- 3. Log to worklog
INSERT INTO worklog (request_id, action, target, command, status)
VALUES (<request_id>, '<action>', '<target>', '<what SysClaw will do>', 'in_progress');

-- 4. Execute the action (SSH to target, run command, verify)

-- 5. Update worklog with result
UPDATE worklog SET status = 'completed', result = '<outcome>', completed_at = NOW() WHERE id = <worklog_id>;

-- 6. Write response notification back to agent
INSERT INTO notifications (recipient, sender, related_request, message, urgency)
VALUES ('jobhunter', 'sysclaw', <request_id>, 'Request #5 DONE: cron installed and verified on MB-OpenClaw-01', 'normal');

-- 7. Mark sysclaw's notification as read
UPDATE notifications SET read = TRUE WHERE id = <notification_id>;

Execution by Request Type

Request type	Action
info	SSH to target, run check, write result to worklog + notification
software	SSH to target, install package, verify service running
config	SSH to target, apply config change, verify
service	SSH to target, restart/stop/start service, verify status
resource	Create DB/user/allocation if SysClaw has access; escalate infrastructure requests
deployment	SSH to target, deploy per request details, verify
access	Escalate to human operator — never auto-approved

Escalate to the human operator

For urgent requests or high-risk actions:

1. Set verdict = 'escalated', escalated = TRUE, escalation_reason = '<reason>'
2. The request is now flagged for human review
3. SysClaw checks for escalated requests during its next session and notifies the human operator on Telegram
4. The human operator reviews and decides
5. SysClaw updates the verdict and notifies the requesting agent

Note: The cron job does NOT send Telegram messages directly. It flags requests as escalated. SysClaw handles Telegram notification during its normal session workflow.

4. SysClaw updates verdict and notifies the requesting agent

Resolve an issue

UPDATE issues SET status = 'resolved', resolved_at = NOW(), resolved_by = 'sysclaw' WHERE id = <issue_id>;

Decision Guidelines

Auto-approve (low risk):

• Software installs on managed VMs (standard packages)
• Info/check requests (disk, service status)
• Config changes to agent's own workspace

escalate to the human operator (high risk):

• Access requests (SSH keys, DB credentials, new users)
• Firewall or network changes
• Production service restarts
• Anything modifying shared infrastructure
• Requests marked urgency = 'urgent'

The human operator and infrastructure owner. All high-risk decisions require the human operator's approval.

Deny:

• Requests without clear justification
• Dangerous operations (rm -rf, chmod 777)
• Conflicts with security policy

Cron Job Behavior

The sysclaw-notification-check OpenClaw cron job runs every 15 minutes:

1. Checks notifications WHERE recipient = 'sysclaw' AND read = FALSE
2. For each notification, reads the related request
3. Assesses risk per Decision Guidelines above
4. Low risk → approves, executes the action, logs to worklog, notifies agent with result
5. High risk → flags as verdict='escalated' for human review
6. Marks processed notifications as read

This is not a system cron job or binary. It runs within the OpenClaw framework as an isolated agent session with access to SSH and DB tools.

SysClaw Escalation Handling

SysClaw checks for escalated requests during its heartbeat and regular sessions:

1. Query: SELECT * FROM agent_requests WHERE verdict = 'escalated' AND resolved_at IS NULL
2. For each escalated request, notify the human operator on Telegram with request details
3. Wait for human operator's decision
4. Update verdict, write security_assessment, set resolved_at/resolved_by
5. Write response notification back to the requesting agent

This is configured in SysClaw's HEARTBEAT.md to run on every heartbeat cycle.

Useful Queries

-- Pending requests
SELECT id, requesting_agent, request_type, action, target, urgency, created_at
FROM agent_requests WHERE verdict = 'pending' ORDER BY created_at;

-- Recent activity
SELECT * FROM agent_requests ORDER BY created_at DESC LIMIT 10;

-- Open issues
SELECT id, source, severity, title, status FROM issues WHERE status = 'open';

-- Unread notifications by recipient
SELECT recipient, COUNT(*) FROM notifications WHERE read = FALSE GROUP BY recipient;

Security Considerations

• Principle of least privilege: DB role should only have UPDATE on specific columns, not full table access
• Audit trail: All verdict changes are logged via resolved_at, resolved_by, and security_assessment
• Human oversight: High-risk requests always escalate to the human operator — SysClaw never auto-approposes access/infra changes
• No secrets in skill: Credentials are provided via OpenClaw environment, not stored in this skill