Helm trust center
Everything your vendor review asks for, in one place.
Helm is a local-first control plane: it runs on your own machine, keeps a signed evidence trail, and never sends your data anywhere it does not itemize below. This page collects the security self-assessment, threat model, software bill of materials, and the itemized network behavior a bank or enterprise IT security review needs before it approves a new tool. Self-assessed today; independent attestation is on the roadmap and noted where it applies.
Related documents
Network behavior
Every request Helm can make: endpoint, payload shape, and what triggers it. Includes the relay-blocked, fully offline path.
Local Network Access (LNA) one-pager
Paste-ready LocalNetworkAccessAllowedForUrls policy JSON for managed Chrome/Edge, plus what LNA is and why Helm needs it.
Power Automate coexistence
"Power Automate moves it, Helm proves it": how Helm sits alongside the desktop RPA incumbent instead of competing with it.
CAIQ-Lite self-assessment
A condensed, CSA Consensus Assessments Initiative Questionnaire (CAIQ)-style self-assessment across the domains a procurement questionnaire typically asks about. This is a vendor self-assessment, not an independent audit: no SOC 2, ISO 27001, or ISO 42001 certification exists yet for Helm. It is dated and versioned so it can be diffed against a future formal attestation.
| Domain | Status | Detail |
|---|---|---|
| Application & interface security | Yes | Loopback API binds to 127.0.0.1 only, checks exact Host and Origin, requires a bearer token on every call, no side effects on GET. Verified by an automated test suite, not just design intent (7/7 server tests). |
| Audit assurance & compliance | Partial | No third-party certification. Every run produces a signed, offline-verifiable evidence bundle designed for auditor consumption (see helm.html). Independent SOC 2/ISO attestation is a future revive-trigger item, not committed to a date. |
| Business continuity & operational resilience | Partial | Local-first by design: Helm has no central service whose outage affects you. Best-effort maintainer support model, documented in the project's operations runbook. No formal SLA. |
| Change control & configuration management | Yes | CI-gated release pipeline; every tagged release ships a dual-signed (Ed25519 + ML-DSA-44) DSSE manifest covering all binaries, verified fail-closed before publish. |
| Data security & information lifecycle | Yes | Zero PII collection by design across the AINumbers.co suite Helm is built on. OAuth tokens live only in the OS keychain/DPAPI (native tier) or an encrypted local fallback; journal and evidence exports redact secrets and raw payloads by default. |
| Datacenter security | N/A | No datacenter: Helm runs on your machine. The only remote calls are the itemized ones in the network-behavior doc. |
| Encryption & key management | Yes | Native OS keychain (macOS Keychain, Windows DPAPI, Linux Secret Service) is the default secret store; a passphrase/PRF-derived AES-256-GCM fallback exists for headless or browser-only use. Release signing keys never touch the repo. |
| Governance & risk management | Yes | Published threat model (below) with an explicit adversary list, defenses-in-place mapped to automated tests, and open findings tracked to closure. |
| Human resources | N/A | Small team, no managed-service staff with standing access to your data (there is no service to have access to). |
| Identity & access management | Yes | OAuth 2.0 + PKCE (RFC 8252 loopback flow) for every connector; a connector only ever sees its own scoped vault slice, never another connector's tokens. |
| Infrastructure & virtualization security | N/A | Runs as a local Node.js process or in-browser; no shared infrastructure to isolate. |
| Interoperability & portability | Yes | Evidence bundles are plain-format, offline-verifiable, and export via .helm.json (versioned, secrets-stripped) so a workflow is not locked into Helm. |
| Mobile security | N/A | Desktop/browser only; no mobile client. |
| Security incident management | Yes | Documented incident-response process; security contact [email protected]. |
| Supply chain management | Partial | npm trusted publishing (OIDC) from CI, build-provenance attestation, 2FA-enforced maintainers, committed lockfile. CycloneDX SBOM publication per release is in progress (see below). |
| Threat & vulnerability management | Yes | Adversarial security review performed pre-launch and re-run per phase; findings tracked as board rows to closure (see threat model below). |
Threat model summary
Source of truth: docs/THREAT-MODEL.md in the Helm repository (one SSOT; this is a summary, not a fork). Helm is reviewed differently from the rest of AINumbers.co's static tools because it holds live OAuth tokens, calls private APIs, and keeps a durable signed journal.
Assets in scope: OAuth access/refresh tokens, the loopback pairing bearer token, release signing keys, the journal and evidence bundles, and the vendored kernel/verify libraries that evidence trust depends on.
Adversaries considered: a malicious local web page trying to reach the daemon (DNS rebinding, CSRF), a local unprivileged process on the same machine, a malicious or compromised connector/workflow trying to exfiltrate data past the egress allowlist, a supply-chain attacker tampering with vendored code or the release pipeline, and a network attacker sitting between Helm and an OAuth/token endpoint.
Review status: the initial adversarial pass (HELM-R1) filed six findings. All six have since been remediated and closed (an egress-allowlist redirect bypass, a Windows secret-on-command-line exposure, a vendored-code integrity gate, an OAuth endpoint scheme check, and two accepted/documented residual-risk items). Helm's residual-risk posture: no write-capable connector ships un-reviewed, and evidence-bundle offline verifiability is a structural property, independent of whether any connector or the daemon itself is still maintained.
Software bill of materials (SBOM)
Helm is a zero-dependency Node.js project by design (no runtime npm packages beyond Node itself), which keeps the dependency surface small on its face, but a real SBOM covers the toolchain and CI action pins too, not just runtime deps. A CycloneDX-format SBOM generated and attached to each tagged GitHub release is on the near-term roadmap; it is not yet automated as of this writing.
Until automated per-release SBOM publication ships, request the current dependency and toolchain manifest directly: [email protected]. This page will link the generated sbom.cdx.json artifact once the release pipeline produces it, and the claim above will be updated to match, not left stale.
Questions for a vendor review
For anything not covered here, including a fuller CAIQ, a signed NDA-gated deeper review, or a call with the team running the security review process, reach out to [email protected].