Github Webhook Architect
Security checks across malware telemetry and agentic risk
Overview
This instruction-only skill is coherent and purpose-aligned, but it helps create a public GitHub-to-agent webhook with secrets and server configuration changes that users should review carefully.
Before using this skill, make sure you are comfortable exposing a GitHub-triggered webhook to an OpenClaw agent. Use HTTPS, strong secrets, least-privileged agent permissions, scoped workflow triggers, backups for Nginx/OpenClaw config, and per-issue or per-PR session keys. Do not let the agent modify server or repository settings unless you have reviewed and approved the exact change.
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.
Issues, comments, pull request reviews, or other configured repository events may start agent work automatically.
The documented architecture intentionally lets GitHub repository events reach an OpenClaw agent. This is purpose-aligned, but a bad or unexpected GitHub event could be propagated into agent activity after setup.
GitHub Action -> Nginx -> Localhost OpenClaw -> Mapped Hook -> Agent
Use a least-privileged agent, restrict workflow triggers where possible, consider trusted-actor checks, and require human approval for any write or deployment actions the agent can perform.
A wrong configuration change could expose the OpenClaw gateway, break existing routes, or interrupt service.
The skill allows configuration edits and server-tool use, which can affect public routing, firewall behavior, and TLS setup. It is disclosed and requires explicit authorization, so this is a notice rather than a concern.
if `nginx`, `ufw`, or `certbot` are present on the system, you may use them to inspect or write configuration files (`openclaw.json`, Nginx server blocks) ... Only proceed if explicitly authorized.
Back up existing Nginx/OpenClaw configuration, review generated changes before applying them, test with non-production routing first, and keep HTTPS enabled.
Anyone who obtains the hook token could send requests to the configured OpenClaw hook.
The integration depends on a bearer token stored in GitHub Secrets and accepted by OpenClaw. This is expected for the webhook design, and the artifact advises using secrets, but token exposure would allow webhook access.
`Authorization: Bearer <token>` ... `OPENCLAW_HOOK_TOKEN`: The secure token defined in `openclaw.json`.
Use a strong unique token, store it only in GitHub Secrets or equivalent secret storage, rotate it after any HTTP test or suspected exposure, and avoid logging it.
Content from one GitHub event may be retained alongside later events, which could confuse future agent handling if the session is reused as context.
Consolidating webhook runs under one session key can mix context or logs from multiple GitHub events. The workflow snippet also shows per-issue or per-PR session grouping, which can reduce this risk.
Suggest setting a `"defaultSessionKey"` to consolidate webhook runs into a single session log file.
Prefer per-issue or per-PR session keys, avoid treating old session content as trusted instructions, and periodically clear or archive webhook sessions.
A user may have less certainty that the displayed registry entry and embedded skill metadata refer to the exact same release.
The reviewed registry version does not match the version embedded in the skill metadata. There is no code package here, but the mismatch is a provenance detail worth checking.
Registry Version: 1.1.2; SKILL.md metadata and _meta.json version: 1.1.1
Confirm the publisher and intended version before relying on the instructions, especially for production webhook or server configuration.