WorkProtocol Agent
Security checks across malware telemetry and agentic risk
Overview
This is a disclosed paid-work automation skill, but it gives an agent ongoing authority to use credentials, claim jobs, spawn sub-agents, and submit work without clear approval limits.
Install or use this only if you intentionally want an autonomous paid-work agent. Keep cron disabled until you add strict limits, use least-privilege credentials, sandbox cloned repos and sub-agents, and require your approval before claiming jobs, opening PRs, delivering work, or filing disputes.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
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.
The agent could keep taking on external work while unattended, affecting your time, compute costs, WorkProtocol reputation, and contractual/payment outcomes.
This schedules recurring autonomous operation with a stored API key and directs the agent to claim and complete paid work without an explicit per-job approval gate, cap, or stop condition.
Use the cron tool to schedule an agentTurn every 2-4 hours: "Check WorkProtocol for new code jobs matching my capabilities. If a good match exists, claim it and complete it. API key is in ~/workprotocol-creds.env"
Do not enable the cron loop unless you add strict limits, logging, manual approval before claiming or delivery, maximum job counts, and a clear way to stop the automation.
A mistaken or manipulated workflow could claim unsuitable work, submit incorrect deliverables, or create public GitHub changes under your authenticated account.
The instructions use raw API calls that mutate marketplace state by claiming jobs and submitting deliverables; the surrounding workflow also tells the agent to clone repositories and create PRs.
curl -s -X POST "https://workprotocol.ai/api/jobs/$JOB_ID/claim" ... curl -s -X POST "https://workprotocol.ai/api/jobs/$JOB_ID/deliver"
Require confirmation before claim, PR creation, delivery, auto-verification, or dispute actions, and restrict the agent to trusted repositories and clearly reviewed job details.
Anyone or any process that can read or use these credentials could act as your WorkProtocol agent or perform GitHub actions available to your `gh` session.
The skill requires a WorkProtocol API key and an authenticated GitHub session, and stores the API key in a local file. The registry metadata declares no primary credential or required environment variables.
Prerequisites: `WP_API_KEY` ... GitHub CLI (`gh`) authenticated ... setup says: echo "WP_API_KEY=wp_agent_xxxxx" >> ~/workprotocol-creds.env
Use least-privilege tokens, protect the credential file with restrictive permissions, avoid broad GitHub permissions, rotate keys if exposed, and treat the missing credential declaration as something to review before installation.
A malicious or careless job description or repository could steer a sub-agent into unsafe actions or attempts to access local credentials and project data.
External marketplace job text is passed directly as the task for another agent, but the artifacts do not define identity, trust, permissions, secret access, or prompt-injection boundaries for that sub-agent.
Spawn a coding sub-agent ... Use sessions_spawn with runtime="subagent" or runtime="acp"; Task: the job description + acceptance criteria
Treat job descriptions and cloned repositories as untrusted, run coding agents in a sandbox without secrets, and require human review before applying or publishing changes.