Proposal
Would you be open to an official managed CPEX plugin that integrates HOL Guard at tool_pre_invoke so ContextForge can apply Guard policy before a downstream tool is executed?
CPEX already exposes the right pre-invocation boundary, and this repository has a documented path for proposing new managed plugins before implementation. The contribution would include HOL Guard itself as the security dependency/runtime, rather than adding a provider-neutral hook that merely could be used by Guard later.
Small initial scope
- Add a managed
hol_guard / hol_guard_policy plugin following the repository's existing package, manifest, entry-point, README, and test conventions.
- Install/configure HOL Guard explicitly and delegate each supported
tool_pre_invoke event to Guard before CPEX permits the downstream invocation.
- Pass the available tool name plus arguments/context into the Guard evaluation boundary.
- Map an allow decision to normal continuation.
- Map deny to a CPEX rejection with no downstream invocation.
- Treat review / approval required as non-executable at this boundary until approval is resolved, so the original tool is not called prematurely.
- Document the behavior if Guard is unavailable or returns an invalid/error result rather than silently bypassing policy.
- Add tests proving allow continues and deny/review/error paths do not invoke the protected tool.
I would keep this isolated to the plugin repository and avoid CPEX core changes unless the existing plugin contract turns out to require one.
Why this landing surface
HOL Guard is a local-first runtime security layer for AI agents and tools. Putting the integration in the official managed CPEX plugin collection would make it an installable, maintained CPEX security option instead of a one-off external example.
If this direction fits the project, I can follow up with the smallest DCO-signed PR using the maintainers' preferred package name and Guard invocation boundary.
Proposal
Would you be open to an official managed CPEX plugin that integrates HOL Guard at
tool_pre_invokeso ContextForge can apply Guard policy before a downstream tool is executed?CPEX already exposes the right pre-invocation boundary, and this repository has a documented path for proposing new managed plugins before implementation. The contribution would include HOL Guard itself as the security dependency/runtime, rather than adding a provider-neutral hook that merely could be used by Guard later.
Small initial scope
hol_guard/hol_guard_policyplugin following the repository's existing package, manifest, entry-point, README, and test conventions.tool_pre_invokeevent to Guard before CPEX permits the downstream invocation.I would keep this isolated to the plugin repository and avoid CPEX core changes unless the existing plugin contract turns out to require one.
Why this landing surface
HOL Guard is a local-first runtime security layer for AI agents and tools. Putting the integration in the official managed CPEX plugin collection would make it an installable, maintained CPEX security option instead of a one-off external example.
If this direction fits the project, I can follow up with the smallest DCO-signed PR using the maintainers' preferred package name and Guard invocation boundary.