OpenServ Multi Agent Workflows
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: openserv-multi-agent-workflows Version: 1.0.2 The skill bundle provides examples and documentation for setting up multi-agent workflows on the OpenServ platform. All code snippets and instructions are aligned with the stated purpose of creating, managing, and interacting with AI agents and workflows, including authentication with a wallet (`WALLET_PRIVATE_KEY`) and on-chain registration via ERC-8004. There is no evidence of data exfiltration, malicious execution, persistence mechanisms, or prompt injection attempts against the AI agent for harmful objectives. The use of `WALLET_PRIVATE_KEY` is for legitimate platform interactions (authentication, payments, on-chain registration) and is not misused or exfiltrated.
Findings (0)
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.
If a user exposes or reuses a valuable wallet key, they could risk funds, identity, or on-chain/account actions tied to that wallet.
The example uses a wallet private key from the local environment to authenticate with OpenServ; this is expected for the platform examples but is a high-impact credential.
WALLET_PRIVATE_KEY=0x...; await client.authenticate(process.env.WALLET_PRIVATE_KEY)
Use a dedicated low-balance wallet for testing, keep `.env` private, and verify the OpenServ packages and code before running examples that authenticate or register on-chain.
Running the examples unchanged could add unintended marketplace agents or create active workflows that receive webhook requests.
The setup scripts select the first marketplace agent result and then create, activate, and run a workflow. This is aligned with the skill purpose, but it mutates the user's OpenServ workspace.
const grokResearch = grokResult.items[0] ... await client.triggers.activate({ workflowId: workflow.id, id: trigger.id }); await workflow.setRunning()Inspect marketplace results, pin known agent IDs, review workflow tasks and edges, and activate workflows only after confirming the selected agents are trusted.
Personal or sensitive intake data may be processed by OpenServ and the selected marketplace agents.
The life-coaching example collects personal intake data and routes it through agents discovered from the marketplace. This is central to the workflow example, but it crosses agent/platform boundaries.
input: { clientName, currentSituation, goals, obstacles, timeframe, coachingStyle } ... agentId: researcher.idAvoid real sensitive data during testing, verify agent providers and privacy expectations, and use trusted or owned agents for confidential workflows.
The local agent may continue serving workflow traffic until the process is stopped, and the tunnel may expose the agent to platform requests.
The paid-image example runs a local agent and exposes it through a tunnel as part of the workflow. This is disclosed and purpose-aligned, but it is a persistent service while running.
`run(agent)` starts the local agent with built-in tunnel
Run it only in a controlled environment, stop the process when finished, and disable or delete test workflows/triggers that should no longer be reachable.
A future package update or compromised dependency could change behavior when users follow the setup commands.
The examples install external npm packages without pinned versions or a lockfile in the artifact. This is common for documentation examples, but package versions can change.
npm i @openserv-labs/client dotenv; npm i -D @types/node tsx typescript
Pin dependency versions, commit a lockfile in real projects, and install packages from trusted registries/accounts.