[NEW] hol-guard — local agent runtime and supply-chain security

## Preliminary Checks - [x] I have read the Code of Conduct. - [x] I have read `docs/authoring.md` and the marketplace contribution workflow. - [x] I reviewed `docs/plugins.md` and searched existing issues/PRs for HOL Guard / `hol-guard` / `plugin-scanner`. - [x] This proposal is for legitimate, constructive use cases only. - [x] I maintain the proposed open-source security project and its agent integrations. ## Component type New plugin (external/source-referenced if maintainers prefer, following the existing `git-subdir` precedent) ## Proposed name `hol-guard` ## Domain & expertise Local security controls for autonomous coding agents: pre-tool/runtime policy, prompt-injection and exfiltration detection, unsafe command/package checks, and pre-install scanning of Agent Skills, plugins, MCP servers, and agent-tooling repositories. Source/runtime: https://github.com/hashgraph-online/hol-guard Portable plugin/skills source: https://github.com/hashgraph-online/hol-guard-plugin HOL Guard is Apache-2.0 and the security decision can run locally; Guard Cloud is not required. I am a maintainer of the project. ## Unique value proposition The marketplace already has strong components such as `security-scanning`, `block-no-verify`, and `protect-mcp`. This proposal is deliberately narrower in distribution shape and broader at the agent execution boundary: - `security-scanning` focuses on SAST/vulnerability work in the codebase; - `block-no-verify` blocks a specific class of hook-bypass commands; - `protect-mcp` governs MCP tool calls with Cedar/receipts; - HOL Guard provides a local pre-execution boundary across agent tool calls plus pre-install/supply-chain scanning for skills, plugins, MCP servers, packages, prompt-injection/exfiltration patterns, and unsafe commands. The goal is not to duplicate those components. It is to expose an existing open-source runtime and its portable `SKILL.md` security workflows through this marketplace, ideally as an externally maintained/source-referenced plugin so implementation stays upstream. ## Primary use cases 1. **Before installing a skill/plugin/MCP server:** run the existing `plugin-scanner` skill locally against the repository and surface structured findings before trust/install. 2. **While an autonomous coding agent is running:** install/initialize HOL Guard and enforce local policy before risky tool/command/package actions. 3. **Agent supply-chain triage:** inspect prompt-injection, secret/exfiltration, unsafe-command, package, and provenance signals without requiring a cloud account. 4. **Cross-harness safety setup:** give Claude Code, Codex, Cursor, OpenCode, Gemini CLI, and Copilot users one marketplace discovery point for the same local Guard runtime rather than separate duplicated implementations. ## Cross-harness portability notes The distribution repo already uses portable Agent Skills (`skills/hol-guard` and `skills/plugin-scanner`) and keeps enforcement in the external `hol-guard` runtime. The skills depend mainly on shell/package installation plus local CLI execution, so they do not require Claude-only orchestration semantics. If the marketplace prefers an external plugin shape, the existing `git-subdir` pattern used for externally maintained plugins looks like the smallest integration: catalog/source metadata here, implementation and maintenance in `hashgraph-online/hol-guard-plugin`. ## Example interactions **Example 1** User: “I’m about to install this Agent Skill repo. Check it first.” Behavior: the `plugin-scanner` workflow scans the repository locally, reports concrete findings/severity, and gives the user evidence to decide whether to trust/install it. **Example 2** User: “Set up local protection before I let this coding agent execute tools.” Behavior: the HOL Guard workflow installs/initializes the local runtime, verifies the supported harness integration, and confirms that pre-execution controls are active. **Example 3** User: “Why was this command/package action blocked?” Behavior: the workflow surfaces the local Guard decision/finding rather than replacing it with a model-only safety judgment. ## Your expertise I maintain HOL Guard and its agent integration/distribution repository. The current integrations already cover multiple coding-agent harnesses and the portable `plugin-scanner` skill is maintained as an Agent Skill rather than marketplace-specific runtime code. ## Additional context - Runtime: https://github.com/hashgraph-online/hol-guard - Portable plugin/skills: https://github.com/hashgraph-online/hol-guard-plugin - Existing portable scanner: https://github.com/hashgraph-online/hol-guard-plugin/tree/main/skills/plugin-scanner I’m intentionally opening the required issue before a PR. If maintainers consider this non-duplicative, I can follow the exact preferred shape: either a minimal external/source-referenced plugin entry, or a small marketplace-native wrapper that keeps all security/runtime logic in the upstream HOL repositories. The marketplace contribution itself would not advertise paid services or require Guard Cloud.