[skill] Add hol-guard - fail-closed AI runtime safety

.claude-plugin/marketplace.json

@@ -32,6 +32,7 @@
       "strict": false,
       "skills": [
         "./devsecops/secrets-gitleaks",
+        "./devsecops/hol-guard",
         "./devsecops/iac-checkov",
         "./devsecops/container-grype",
         "./devsecops/container-hadolint",

README.md

@@ -34,6 +34,7 @@ SecOpsAgentKit provides specialized Claude Code skills for security operations,
 
 - **[container-grype](skills/devsecops/container-grype/SKILL.md)** - Container vulnerability scanning and dependency risk assessment using [Grype](https://github.com/anchore/grype) with CVSS, EPSS, and CISA KEV prioritization
 - **[container-hadolint](skills/devsecops/container-hadolint/SKILL.md)** - Dockerfile security linting and best practice validation using [Hadolint](https://github.com/hadolint/hadolint)
+- **[hol-guard](skills/devsecops/hol-guard/SKILL.md)** - AI agent runtime protection using [HOL Guard](https://github.com/hashgraph-online/hol-guard) with fail-closed pre-tool enforcement
 - **[iac-checkov](skills/devsecops/iac-checkov/SKILL.md)** - Infrastructure as Code security scanning using [Checkov](https://www.checkov.io/) with 750+ built-in policies
 - **[sca-trivy](skills/devsecops/sca-trivy/SKILL.md)** - Software Composition Analysis and container vulnerability scanning using [Trivy](https://aquasecurity.github.io/trivy/) for CVE detection
 - **[secrets-gitleaks](skills/devsecops/secrets-gitleaks/SKILL.md)** - Hardcoded secret detection and prevention in git repositories using [Gitleaks](https://github.com/gitleaks/gitleaks)

skills/.claude-plugin/marketplace.json

@@ -20,6 +20,7 @@
       "skills": [
         "./devsecops/container-grype",
         "./devsecops/container-hadolint",
+        "./devsecops/hol-guard",
         "./devsecops/iac-checkov",
         "./devsecops/sca-trivy",
         "./devsecops/secrets-gitleaks",

skills/devsecops/hol-guard/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: hol-guard
+description: >
+  Runtime safety for supported local AI coding harnesses using HOL Guard before mutation-bearing tool work.
+  Use when: (1) protecting a local coding agent before commands or file changes, (2) requiring fail-closed
+  approval and denial behavior before tool execution, (3) collecting Guard status, doctor, receipt, and audit
+  evidence while preserving the harness native authorization, sandbox, and confirmation controls.
+version: 0.1.0
+maintainer: kantorcodes
+category: devsecops
+tags: [hol-guard, agent-security, runtime-security, ai-safety, devsecops, approvals, audit]
+frameworks: [OWASP, NIST, SOC2]
+dependencies:
+  tools: [hol-guard]
+references:
+  - https://github.com/hashgraph-online/hol-guard
+---
+
+# HOL Guard Runtime Safety
+
+Use HOL Guard as an additional pre-tool runtime-safety layer for supported local AI coding harnesses. Keep the harness own authentication, permissions, confirmations, sandboxing, and provider policy enabled.
+
+## Safety rules
+
+- Do not claim protection until HOL Guard itself reports healthy evidence for the detected harness.
+- Do not guess or hard-code a harness identifier. Use `hol-guard detect --json` and reuse the exact supported identifier it returns.
+- If Guard returns deny, review, unhealthy status, unexpected mutation, or an error, stop mutation-bearing work. Never fall back to launching the raw harness as a protection bypass.
+- Never approve a blocked action without reading the Guard risk reason and confirming the requested scope.
+- Keep HOL Guard Cloud optional. Do not connect or sync unless the user explicitly requests it.
+- Never weaken native harness controls because Guard is installed.
+- Do not read or copy `.env` files, credentials, or secret stores into prompts or external services.
+
+## Install and verify
+
+Probe the real CLI first:
+
+```bash
+hol-guard --version
+```
+
+If it is unavailable and the user asked to install Guard, prefer the isolated pinned stable install used by this contribution:
+
+```bash
+pipx install --force "hol-guard==3.0.12"
+hol-guard --version
+```
+
+Do not silently replace this pin with `latest`, a prerelease, or a branch URL. If `pipx` is unavailable, report that isolated CLI installation is recommended instead of silently modifying the active Python environment.
+
+## Protect the detected harness
+
+Run from the target workspace:
+
+```bash
+hol-guard status
+hol-guard detect --json
+```
+
+Use only the exact supported harness identifier returned by detection. Then run the Guard-owned setup and verification path:
+
+```bash
+hol-guard bootstrap
+hol-guard install <harness>
+hol-guard run <harness> --dry-run
+hol-guard doctor <harness> --json
+hol-guard run <harness>
+hol-guard status
+```
+
+The dry run and `doctor` must succeed before claiming protection. If detection finds no supported harness, or bootstrap/install/dry-run/doctor fails, stop and report the exact failure instead of starting an unprotected session.
+
+## Handle approval-gated work
+
+Inspect Guard-owned decisions before resolving them:
+
+```bash
+hol-guard approvals
+hol-guard approvals open <request-id>
+hol-guard receipts
+hol-guard diff <harness>
+```
+
+When Guard returns a request ID and the user has authorized the specific decision:
+
+```bash
+hol-guard approvals approve <request-id>
+hol-guard approvals deny <request-id>
+```
+
+A prior approval does not authorize a different request.
+
+## Audit evidence
+
+Use Guard evidence surfaces rather than inventing success:
+
+```bash
+hol-guard receipts
+hol-guard inventory
+hol-guard abom --format json
+hol-guard events
+```
+
+Report only evidence actually returned by Guard. Keep optional cloud synchronization disabled unless explicitly requested.
+
+## Output
+
+Return a concise report with the detected harness identifier, HOL Guard version, bootstrap/install/dry-run/doctor/run results, final status evidence, pending approvals or blocks, and the exact next safe command if work remains blocked.