---
title: "Getting Started with HELM Launchpad"
canonical: "https://helm.docs.mindburn.org/start/launchpad"
source: "app-docs-platform/content/docs/start/launchpad.md"
edit: "https://github.com/Mindburn-Labs/app-docs-platform/edit/main/content/docs/start/launchpad.md"
section: "start"
access: "public"
sensitivity: "public"
last_reviewed: "2026-05-28"
checksum_sha256: "sha256:29a710cc62ee0913c471c34dd335d3ed38f146fd95191428b97aae2698568c9e"
build_timestamp: "2026-06-10T22:15:26.620Z"
---
# Getting Started with HELM Launchpad

HELM Launchpad is HELM's adoption surface for protecting AI agent frameworks. It runs real AI apps through HELM's fail-closed execution boundary, producing signed receipts and offline-verifiable EvidencePacks for every action.

Launchpad is the fastest path from zero to governed AI execution. You launch a supported framework, HELM intercepts every side-effect, and you receive cryptographic proof of what happened.

## Supported Frameworks

| Framework | Command | What HELM protects |
| --- | --- | --- |
| OpenClaw | `helm up openclaw` | Tool calls, file writes, network egress |
| Hermes | `helm up hermes --target local` | MCP tool invocations, sandbox escapes |
| OpenCode | `helm-ai-kernel launch opencode local-container --headless --output json` | Code execution, filesystem mutations |
| Kilo Code | `helm-ai-kernel launch kilocode local-container --headless --output json` | Agent actions, resource access |

All four frameworks are `oss_supported` with signed OCI artifacts, policy packs, and live conformance evidence.

## Quick Start

### 1. Register at Console

Create your Mindburn account at the HELM Console:

```text
https://console.helm.mindburn.org
```

Console registration gives you access to run dashboards, receipt inspection, and EvidencePack review.

### 2. Install the CLI

```bash
brew install mindburnlabs/tap/helm-ai-kernel
helm-ai-kernel --version
```

The published binary ships as `helm-ai-kernel`. Release builds also provide `helm` as the primary product command.

### 3. Login

```bash
helm-ai-kernel login
```

### 4. Pair with Console

```bash
helm-ai-kernel console pair
```

Pairing links your local CLI to the Console so that runs, receipts, and EvidencePacks appear in your dashboard.

### 5. Run Your First Protection

For the instant no-secret demo path:

```bash
helm up openclaw --demo
```

For live mode with a real model, bind a scoped secret first:

```bash
export OPENROUTER_API_KEY='<key>'
helm-ai-kernel launch secrets set model_gateway --provider openrouter --value-env OPENROUTER_API_KEY
helm up openclaw --live
```

The command prints a Console URL and an offline verification command:

```text
http://127.0.0.1:7714/runs/<run_id>
```

### 6. View Results in Console Dashboard

Open the Console URL to inspect the run. The dashboard shows:

- Verdict timeline — every ALLOW, DENY, and ESCALATE decision
- Receipt chain — signed, hash-linked proof of each action
- EvidencePack status — exportable offline verification bundle
- Sandbox state — filesystem, network, and process isolation boundaries

## What Happens During a Run

Every Launchpad run passes through these verification stages:

| Stage | What happens |
| --- | --- |
| 1. Registry resolution | Resolve the app's registry entry and signed OCI artifact digest |
| 2. Policy validation | Load and validate the app's policy pack |
| 3. Artifact verification | Verify the signed container image digest matches the registry |
| 4. Sandbox preparation | Prepare scoped filesystem and isolation boundary |
| 5. Network policy | Apply deny-by-default network rules |
| 6. Secret binding | Project model gateway secret only inside launch scope |
| 7. MCP manifest | Pin MCP server/tool schemas; quarantine unknown servers |
| 8. Healthcheck | Run container healthcheck before accepting traffic |
| 9. Execution receipts | Emit signed receipts for launch, install, and healthcheck |
| 10. Runtime verdicts | Issue ALLOW, DENY, or ESCALATE for each intercepted action |
| 11. Teardown | Clean teardown with signed teardown receipt |
| 12. EvidencePack export | Assemble offline-verifiable EvidencePack archive |

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        Registry["Registry entry"]
        Plan["Deterministic launch plan"]
    end

    subgraph Evaluation["2. Evaluation & Policy Plane"]
        Policy["Policy pack"]
    end

    subgraph Execution["3. Execution & Verdict Plane"]
        Gate["ALLOW / DENY / ESCALATE"]
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        Receipt["Signed receipt"]
        Evidence["Offline EvidencePack"]
    end

    %% Operational Flow Edges
    Registry --> Policy
    Policy --> Plan
    Plan --> Gate
    Gate --> Receipt
    Receipt --> Evidence

    %% Styling
    style Policy fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style Gate fill:#e53e3e,stroke:#9b2c2c,stroke-width:2px,color:#fff
    style Receipt fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
    style Evidence fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
```

## Understanding Your Receipt

Every verdict produces a signed receipt. Key fields:

| Field | Description |
| --- | --- |
| `verdict` | `ALLOW`, `DENY`, or `ESCALATE` — the execution decision |
| `action_id` | The tool call or side-effect that was intercepted |
| `policy_id` | Which policy rule governed the decision |
| `payload_hash` | SHA-256 of the JCS-canonicalized (RFC 8785) verdict payload |
| `signature` | Ed25519/JWS asymmetric signature over the payload hash |
| `proof_refs.receipt_hash` | Hash-linked pointer into the ProofGraph DAG |
| `proof_refs.lamport_clock` | Monotonic causality counter for ordering |
| `proof_refs.prev_hash` | Link to the previous receipt in the session chain |

Receipts are tamper-evident: modifying any field invalidates the signature and breaks the hash chain.

### Verify Offline

```bash
helm-ai-kernel verify --bundle <evidence-pack.tar>
helm-ai-kernel evidence inspect <evidence-pack.tar>
helm-ai-kernel evidence inspect <evidence-pack.tar> --json
```

Verification succeeds only when the EvidencePack contains the required roots, proof material, and receipts.

### Compare Runs

```bash
helm-ai-kernel evidence diff <pack-a> <pack-b>
```

## Next Steps

- **Try another framework** — run `helm up hermes --target local` or launch OpenCode
- **Explore the launch matrix** — `helm-ai-kernel launch matrix --json` shows all app × substrate combinations
- **Configure policies** — customize execution rules with policy packs
- **Review the boundary** — `helm-ai-kernel boundary status --json` inspects the live execution boundary
- **Set up MCP authorization** — `helm-ai-kernel mcp authorize-call --server-id <id> --tool-name <tool> --json`
- **Inspect receipts** — `helm-ai-kernel receipts tail --agent <agent_id> --server http://127.0.0.1:7714`
- **Read the architecture** — [Proof and Replay](/company-ai-os/proof-and-replay) explains ProofGraph and EvidencePack internals

## Troubleshooting

| Symptom | First check |
| --- | --- |
| `helm up` exits before healthcheck | Check `helm-ai-kernel launch logs <launch_id>` for container startup failures |
| Launch reaches `REPAIR_REQUIRED` | Run `helm-ai-kernel launch evidence <launch_id> --export --json` and inspect the failure receipts |
| EvidencePack verification fails | Ensure the pack is complete and unmodified; run `helm-ai-kernel verify --bundle <pack>` |
| MCP tool call quarantined | Server identity, tool schema, and scopes must be approved before execution |
| Model gateway secret missing | Run `helm-ai-kernel launch secrets status` to check binding state |

## Source Truth

- CLI entrypoint: `helm-ai-kernel` → `core/cmd/helm-ai-kernel/launch_cmd.go`
- Runtime package: `core/pkg/launchpad/`
- App and substrate registry: `registry/launchpad/`
- Policy packs: `policies/launchpad/`
- Contract schemas: `schemas/launchpad/`
- Console run dashboard: `app-helm-console` → `/runs/<run_id>`
- Kernel quickstart: `helm-ai-kernel/docs/QUICKSTART.md`
- Launchpad reference: `helm-ai-kernel/docs/LAUNCHPAD.md`