S2G - General Purpose Workflow Engine

Connect to S2G (s2g.run) visual workflow automation platform over WebSocket. Execute workflow nodes as tools — password generators, hash functions, date math...

Key things to consider before installing: - Network exposure: By default the bridge's HTTP API is documented as binding to the host network (docs note 0.0.0.0) and sets Access-Control-Allow-Origin: *. Ensure the service is bound to localhost only (127.0.0.1) or protected by firewall rules so other machines cannot call /execute or /reconnect. If you must use 0.0.0.0, restrict access via host firewall. - Authentication: Set an Auth Secret on the OpenClaw node and start the bridge with --secret (or S2G_SECRET). Do not leave the OpenClaw node unauthenticated if the workflow exposes privileged nodes. - Limit workflow node exposure: When designing the S2G workflow that the bridge connects to, only wire the OpenClaw node to the specific, minimal set of tool nodes you trust. Avoid exposing DB, cloud connectors, or file-write nodes unless explicitly needed. - Secrets & credentials: The docs show examples using an X-API-Key and even reading a local ~/.config/s2g/credentials.json — avoid placing other service credentials in widely readable files, and do not let the bridge or workflows access unrelated secrets. Prefer short-lived keys and least privilege for any API keys configured in S2G. - Logs & data retention: The bridge writes logs (logs/s2g-bridge.log) and may record incoming payloads. Ensure log directories are protected and rotated, and that sensitive payloads are not retained longer than necessary. - Run as an unprivileged user: If you run the bridge as a service, run it under a dedicated, restricted user account, and avoid giving it access to unrelated files or system credentials. - Review the workflow node list and schemas: Before executing unfamiliar nodes, query the node schema (catalog) to understand exact parameters and what the node can do. Be particularly careful with Knowledge, Database, Cloud connector, and Custom_ nodes that may execute arbitrary code or access external systems. - If unsure, test in an isolated environment: Run the bridge from an isolated VM or container with no sensitive network access until you are confident about the workflow and its behavior. If you want, I can: (a) point to the exact lines in the bridge script that open sockets, bind the HTTP server, and write logs; (b) suggest a minimal patch to force the HTTP server to listen on localhost only; or (c) highlight which node types (from the provided catalog) are highest-risk.

Type: OpenClaw Skill Name: s2g-workflow-engine Version: 1.0.0 The skill provides a bridge (`s2g-bridge.js`) that exposes a local HTTP API (default port 18792) to allow the OpenClaw agent to interact with the S2G workflow automation platform. This bridge binds its HTTP API to `0.0.0.0` by default, making it accessible from other machines on the network if not explicitly firewalled, as noted in `references/operations.md`. While the skill's documentation (`SKILL.md`, `README.md`, `references/api.md`) clearly outlines the extensive capabilities it grants (e.g., executing database queries, interacting with AI models, managing S2G workflows, and executing custom JavaScript within S2G's sandboxed environment), these powerful features, combined with the default network binding, present a significant attack surface. There is no evidence of intentional malicious behavior such as data exfiltration or backdoor installation by the skill itself, but the broad capabilities and network exposure risk classify it as suspicious.