OpenServ Multi Agent Workflows
ReviewAudited by ClawScan on May 10, 2026.
Overview
Prompt-injection indicators were detected in the submitted artifacts (system-prompt-override); human review is required before treating this skill as clean.
Install or use this skill only if you intend to build OpenServ workflows. Before running any example, use a sandbox project, a dedicated low-balance wallet, pinned package versions, and vetted agent IDs; avoid real sensitive data until you understand which agents and webhooks will receive it. ClawScan detected prompt-injection indicators (system-prompt-override), so this skill requires review even though the model response was benign.
Findings (5)
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.