Helm for OpenClaw and AutoClaw

One evidence engine, three doorways

Your agent plans and calls. Helm re-computes each step deterministically, keeps an append-only journal, and seals the run into a bundle anyone can verify offline. Three doorways connect your agent to it:

• helmd’s MCP endpoint on http://127.0.0.1:4173/mcp: eight tools your agent calls over loopback.
• The daemon-free CLI: helmd check, helmd verify, run-template for recomputes with no daemon running.
• The action-log importer: seals what your agent actually did into a bundle that carries its own verifier.

New to Helm itself? Start with the Helm page or the walkthrough; this page assumes you want the agent integration.

Pick your agent, paste one block

All paths assume helmd is installed and running (see the seven-step install). Everything below stays on loopback.

Path 1 · OpenClaw: the mcp.servers block

Paste this block into openclaw.json (OpenClaw reads mcp.servers):

{
  "mcpServers": {
    "helm": {
      "transport": "streamable-http",
      "url": "http://127.0.0.1:4173/mcp",
      "headers": {
        "Authorization": "Bearer ${HELM_TOKEN}",
        "Origin": "http://127.0.0.1:4173"
      },
      "toolFilter": {
        "exclude": [
          "workflow.run",
          "evidence.export"
        ]
      }
    }
  }
}

The Origin header line is required today: helmd’s origin gate accepts a request only when it carries an exact matching Origin (or a same-origin fetch marker a non-browser client cannot send). The header is dropped automatically once the helm side accepts an absent Origin on /mcp.

The default toolFilter excludes workflow.run and evidence.export: your agent can check, verify, and read evidence, but a real run and an evidence export stay human decisions.

Save the file, restart the gateway, and run the smoke test: openclaw mcp probe helm.

Path 1b · OpenClaw: exec allowlist

Allow your agent to run exactly these helmd commands, and nothing else:

{
  "exec": {
    "allow": [
      "helmd check",
      "helmd verify",
      "helmd status --json",
      "helmd list-scenarios"
    ],
    "safeBinTrustedDirs": [
      "<the directory where the helmd binary is installed>"
    ],
    "note": "Never list node or a shell as a safe bin."
  }
}

Path 1c · OpenClaw: cron and heartbeat

A nightly recompute plus an hourly heartbeat, as OpenClaw automations:

{
  "cron": [
    {
      "name": "helm-nightly-check",
      "schedule": "nightly",
      "command": "helmd check <pack> --glob \"extracts/*.json\" --json"
    }
  ],
  "heartbeat": {
    "command": "helmd status --json"
  }
}

Path 2 · AutoClaw: skill import

One command (or the UI path; AutoClaw cannot edit openclaw.json):

autoclaw skill install https://raw.githubusercontent.com/PostOakLabs/ainumbers-helm/main/agent-kit/helm-skill.zip

Then confirm it landed: autoclaw skill list

In the AutoClaw UI: Plugins > Skills > import SKILL.md or ZIP (lands in ~/.autoclaw/skills/, zip-slip protected).

The zip URL is https://raw.githubusercontent.com/PostOakLabs/ainumbers-helm/main/agent-kit/helm-skill.zip. It 404s until the helm agent kit lands; that is expected and tracked in the site’s dead-link baseline.

Path 3 · ClawHub (when listed)

Once the helm skill is published on ClawHub, this section will show clawhub install helm-evidence with the published version. The version string is rendered from the helm kit’s published_version field and is deliberately absent until that field exists, so nothing here can go stale by hand.

What Helm never does

• Loopback only: the hub listens on 127.0.0.1, with a bearer token per client plus Host and Origin checks.
• No telemetry, analytics, or crash reporting anywhere in the helm repo.
• Evidence export needs a human consent ticket; an agent cannot mint one, and the export tier is unreachable from MCP tools/call.
• Connectors are unreachable from tools/call; each one is scope-limited to its own allowlisted host.

OpenClaw’s own security posture carries over unchanged: run openclaw security audit --deep after adding any MCP server, and treat exec approvals as guardrails for operator intent rather than hostile multi-tenant isolation. “Allow Always” grants stay scoped to the exact agent, server, and tool.

Every outbound call helmd can make, copied from the helm repo’s docs/TRUST.md §1 (vendor copy: data/helm-kit/TRUST-endpoints.json):

No telemetry, analytics, or crash-reporting library exists in the helm repo. Exporting evidence needs a human consent ticket the agent cannot mint, and the export tier is unreachable from MCP tools/call.

Prompts that use the doorways

Bodies come from the site’s prompt catalog by id; a prompt renders here only once its id exists there, so nothing on this page is hand-typed or drifting.

Nightly loop for a paired helmd: recompute your packs and post only the failures.

1. helmd catalog.search for each pack family you own (for example "2052a"); record the workflow ids and manifest digests.
2. For each pack, helmd workflow.dry_run against today's extract files. Record any dry-run gate failures; those are your input problems, fix them before the real run.
3. helmd workflow.run each pack for real. Poll helmd artifact.get for each run's execution_hash and per-step digests.
4. helmd artifact.verify each run against its manifest digest. Classify: VERIFIED, FAILED, or STALE (digest drifted from yesterday).
5. Compare each execution_hash with yesterday's note. A hash that changes when the extract did not change is your top alarm; quote the changed step.
6. Give me the per-pack table: workflow id, digest, execution_hash, class.
7. Write the nightly note for your channel: failures first, then the table, then the one command a teammate runs on their own helmd to reproduce any line. State plainly that nothing here required trusting your machine: every line re-verifies from the manifest digest.

Turn a raw agent gateway action log into a sealed, offline-verifiable bundle.

1. Export the gateway's action log for the window you care about (timestamp, actor, tool, input digest, output digest per line). Do not edit lines; gaps are findings, not noise.
2. On your paired helmd, catalog.search for a pack that ingests an action log; if your deployment has one, note its workflow id. Otherwise use the generic evidence workflow.
3. helmd workflow.run that workflow with the log as input. The run folds each line's digests into the pack's hash tree.
4. helmd artifact.get the run: record execution_hash and the per-step digests.
5. helmd artifact.verify the run against its manifest digest. State pass/fail and which steps are covered.
6. helmd evidence.export the bundle. Confirm it carries: the log digests, the manifest digest, the execution_hash, and a verify command that needs no network.
7. Give me the bundle path and a three-line handover note for your auditor: what the log covers, what the seal attests (digests, not behavior), and the exact offline command they run. Anyone with the bundle and helmd verifies it without contacting us.

Make a deployment gate read a Helm run's evidence instead of a human's thumbs-up.

1. On your paired helmd, pick one completed workflow run. helmd artifact.get it; record the execution_hash and per-step digests.
2. helmd artifact.verify the run against its manifest digest. A run that fails verify must never reach the gate; confirm your policy rejects it.
3. helmd evidence.export the run as its in-toto statement export. Record the statement's subject digests.
4. Inspect the statement: confirm the subjects name the artifacts your deployment actually consumes, not a superset.
5. Negative test: modify one byte of a subject artifact and re-verify the statement; confirm verification fails. Quote the failure.
6. Wire the gate: your policy engine (cosign verify or a Kyverno verify rule against the exported statement) checks the statement before allowing the deployment. Record the policy rule text.
7. Give me the gate decision output for one allowed and one blocked deployment.
8. Write the runbook entry for the platform channel: the export command, the policy rule, the two test outputs, and the line that the gate reads digests, not opinions.

Offline, with the bundle alone

The sealed bundle carries its own verifier page inside the archive, so a recipient who has never installed Helm can open it and see the same result. With helm installed, verification is one command:

helmd verify bundle.json --keys publicKeys.json

Check the ledger and anchors at the hash resolver. Every claim on this page reduces to a digest someone else can recompute; nothing requires trusting our servers or your agent’s say-so.

Run the hub view in a Canvas node

The hub interface can open inside OpenClaw’s Canvas with canvas.navigate pointed at http://127.0.0.1:4173/#token=…, with the node command listed under gateway.nodes.commands.allow. This recipe is recorded from a Linux run; a macOS run has not recorded it yet, hence the tag above.

Questions we expect

Go deeper

• Helm · the product page and its install steps
• Walkthrough · a run you can replay in the browser
• docs/AGENTS.md · the agent-kit entry point on GitHub (ships with the kit)
• ClawHub listing · placeholder until the skill is published
• MCP registry entry · placeholder until listed
• SECURITY.md · how to report a security issue

OpenClaw and AutoClaw are third-party marks of their respective owners, used here descriptively only. HelmClaw is AINumbers’ nickname for this page; the product is Helm. No affiliation or endorsement is implied, and no third-party logos appear here.