OpenServ Multi Agent Workflows
v1.0.2Multi-agent workflow examples to work together on the OpenServ Platform. Covers agent discovery, multi-agent workspaces, task dependencies, and workflow orch...
⭐ 0· 1.2k·5 current·6 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The content describes building and provisioning multi-agent workflows on the OpenServ platform (agent discovery, triggers, x402 paid triggers, on‑chain registration). That capability legitimately requires wallet authentication and platform client calls, so most of the instructions are coherent with the stated purpose. However, the registry metadata lists no required environment variables or primary credential while many example scripts repeatedly reference process.env.WALLET_PRIVATE_KEY (and some examples reference OPENAI_API_KEY). This mismatch between declared requirements and the instructions is an inconsistency worth noting.
Instruction Scope
The SKILL.md instructs the operator/agent to read/write .env and use process.env.WALLET_PRIVATE_KEY (authenticate with client.authenticate(privateKey)), to call provision() which may write wallet state, and to reload .env after provision(). Those actions involve sensitive local state and private keys. The instructions also include running local code (npm scripts) and starting a local agent tunnel (run(agent)). The file contains strong prescriptive guidance (e.g., always define edges) but also shows operations that access secrets and local files — this broad scope is not declared in the metadata and increases risk if a user or automated agent follows instructions without review.
Install Mechanism
This is an instruction-only skill with no install spec and no code files to execute on install. That lowers installation risk — nothing is downloaded or written by an installer. The examples do call third-party npm packages when run locally, but those installs are part of example projects the user must run explicitly.
Credentials
Although the registry metadata declares no required environment variables, many examples require WALLET_PRIVATE_KEY and several examples reference OPENAI_API_KEY. Requesting a wallet private key is proportional to features like x402 paid triggers and on‑chain registration, but the metadata omission is misleading. Requiring secrets (private key, API keys) in examples without declaring them in the skill manifest is disproportionate and can lead to accidental secret disclosure if users copy/paste without auditing.
Persistence & Privilege
The skill does not request permanent inclusion (always: false) and does not modify other skills. However, examples call provision(), which the docs say auto-populates WALLET_PRIVATE_KEY into .env and instructs the user to reload .env afterward — this implies the examples will write secrets to disk. Writing a private key to a local .env file is a potentially persistent change; it is not intrinsically a platform privilege escalation, but users should be aware of the side effect before running provisioning.
Scan Findings in Context
[system-prompt-override] unexpected: The pre-scan flagged a 'system-prompt-override' pattern in SKILL.md. The document is primarily API/docs content, so a prompt-injection-style pattern is unexpected; this may be a false positive (e.g., YAML header like 'name:'), but it could also indicate phrases that an LLM could misinterpret as control instructions. Treat SKILL.md content as untrusted input to models and avoid blindly concatenating it into model prompts.
What to consider before installing
This skill appears to be genuine documentation/examples for OpenServ workflows, but there are a few red flags you should consider before running any example code:
- Secrets: Examples expect WALLET_PRIVATE_KEY (and in one example OPENAI_API_KEY) even though the skill metadata doesn't declare required env vars. Do not paste your real wallet private key or high-value API keys into example .env files. Use a throwaway wallet with minimal funds for testing.
- Provisioning side effects: provision() is documented as auto-writing a WALLET_PRIVATE_KEY to .env. Inspect what provision() does in the official SDK before running it and keep backups. If you don't want secrets written to disk, run steps manually or use ephemeral credentials.
- Prompt-injection scanner: The SKILL.md was flagged for 'system-prompt-override' patterns. That is likely a false positive, but be cautious about feeding the raw SKILL.md into any model prompt that has system-level control — treat those files as untrusted.
- Source provenance: The skill's homepage and source are unknown. Prefer official documentation or a verified source. If you still want to use these examples, copy only the snippets you understand, verify the SDK functions locally, and run in an isolated/test environment.
- Best practice: Review and audit the code paths that call client.authenticate(), provision(), and any code that writes files or transmits webhooks. Limit permissions, use ephemeral keys, and never run code that contains secrets you can't replace.Like a lobster shell, security has layers — review code before you run it.
latestvk975kf175drbjh9drtccy5wamh819g6e
License
MIT-0
Free to use, modify, and redistribute. No attribution required.