ReleaseGuard, Sentinel, and the MCP Security Checklist

Helixar Labs has published three open-source security tools in Q1 2026, each targeting a distinct gap in the current security stack: artifact-level policy enforcement, MCP server configuration hardening, and live MCP traffic analysis. All three are MIT-licensed, available on GitHub Marketplace at no cost, and require no Helixar account to run core functionality.

ReleaseGuard: Artifact Policy Engine

Supply chain security tooling has historically focused on source code, dependencies, and container images. The SolarWinds compromise drew attention to build pipelines; the XZ Utils backdoor drew attention to the maintainer layer. The final distributable — the exact artifact that reaches users — has received comparatively little scrutiny.

ReleaseGuard scans dist/ and release/ outputs for common post-build leakage: embedded API keys and tokens, accidentally shipped source maps, debug symbols in release binaries, .env files baked into builds, and unsigned executables. It then applies hardening transforms, generates a full SBOM in CycloneDX or SPDX format, and produces a signed, attested artifact with an evidence bundle.

A single command — releaseguard check ./dist — produces a policy result with no configuration and no external network calls. SBOM generation covers all major ecosystems (Node.js, Python, Go, Rust, Java, .NET, Ruby, PHP, container, and system packages). Signing is available via keyless Sigstore for CI environments with OIDC tokens, or via local key material. Provenance attestations follow the SLSA framework to level 2 by default, with level 3 available in the cloud tier.

“Source scanning tells you what went into the build. Artifact scanning tells you what your users are actually receiving. Those are not always the same thing.”

The ReleaseGuard GitHub Action wraps the full pipeline — check, fix, SBOM, sign, attest — into a single workflow step. Policy is configurable via YAML, with support for Open Policy Agent Rego rules and OCI registry bundle loading. Reports export in CLI, JSON, SARIF, Markdown, and HTML. Source is MIT-licensed at github.com/Helixar-AI/ReleaseGuard.

ReleaseGuard on ClawHub

ReleaseGuard is also published as a skill on ClawHub, the marketplace for OpenClaw agents. Once installed, OpenClaw agents can invoke ReleaseGuard through natural language — scanning artifacts, generating SBOMs, or running the full hardening pipeline — without manual CLI configuration.

Each command in the skill documentation specifies whether external network calls are made, which service is contacted, and whether credentials are required. The default path — check, fix, sbom — is fully offline. Signing and cloud features are opt-in and explicitly disclosed.

Sentinel and the MCP Security Checklist

The Model Context Protocol (MCP), introduced by Anthropic in November 2024, has become the standard integration layer between AI agents and external tools, APIs, and data sources. Adoption has been rapid, but security practices have not kept pace. The protocol specification defines transport and schema; it does not define authentication, input validation, or output sanitisation requirements. Those are left to individual implementers.

Helixar Labs has published two tools in response. The MCP Security Checklist covers pre-deployment hardening: authentication, input validation, tool schema constraints, output filtering, transport security, and audit logging. Each item maps to a concrete attack scenario and is designed to serve as a deployment gate, not a reference document.

Sentinel covers runtime risk. Available free on GitHub Marketplace, it scans live MCP traffic, detects anomalous tool invocation patterns, flags prompt injection attempts embedded in tool outputs, and surfaces unexpected permission escalation chains. Together, the checklist and Sentinel cover both the configuration and runtime layers.

Why Open Source

Security tooling that cannot be audited asks users to trust vendor claims. In supply chain security specifically — where the problem is trusting the provenance of what you run — a closed-source scanner is structurally inconsistent with the trust model it is meant to enforce. Open source does not guarantee trustworthiness, but it enables independent verification: public code review, reproducible builds, and community scrutiny at a scale no internal review process can match.

There is also a practical consideration. The gaps these tools address — artifact-level leakage, MCP misconfiguration, agent runtime anomalies — are not gaps a single team can fully characterise from its own deployment data. Open-source projects accumulate real operational experience through issue reports and contributions that accelerate coverage beyond what any proprietary product can achieve independently.

Standards Context: SLSA, SBOM, and Sigstore

ReleaseGuard is built around three standards with growing compliance relevance:

• SLSA — a four-level provenance assurance framework from Google and the OpenSSF. ReleaseGuard produces SLSA level 2 attestations by default; level 3 is available in the cloud tier.
• SBOM — mandated by US Executive Order 14028 for federal software procurement and increasingly required in enterprise contracts. ReleaseGuard generates SBOMs in CycloneDX and SPDX with optional CVE enrichment via OSV.dev.
• Sigstore — Linux Foundation keyless signing infrastructure using Fulcio CA and the Rekor transparency log. Sigstore eliminates long-lived key material from the signing workflow. ReleaseGuard's default signing mode uses Sigstore directly.

Availability

All three tools are available now at no cost:

• ReleaseGuard — installable via Homebrew, available as a GitHub Action, and published as an OpenClaw skill on ClawHub
• Sentinel — available as a GitHub Action on GitHub Marketplace
• MCP Security Checklist — publicly maintained on GitHub

None require an account, cloud token, or commercial relationship to run core functionality. The US Executive Order on Cybersecurity, the EU Cyber Resilience Act, and NTIA minimum SBOM standards are creating compliance requirements across the software supply chain. Teams that adopt these practices proactively will be better positioned when procurement or incident response demands them.