Skip to content

New integration proposal: HOL Guard for Agent before_tool policy enforcement #3843

Description

@kantorcodes

Integration proposal

Add a focused hol-guard-haystack integration for using HOL Guard at Haystack Agent's existing before_tool hook.

Haystack's current Agent hooks run before_tool after tool calls are selected but before any tool executes. After the hooks run, the Agent re-reads the pending message; if the hook removes a blocked tool call, that tool does not run. That provides a supported pre-execution boundary without adding a new Haystack core API.

Proposed scope

  • new integration under this repository following the existing PREFIX-haystack packaging conventions;
  • optional dependency on hol-guard; Guard Cloud is not required for the local path;
  • expose a small reusable hook/class that evaluates each pending tool name + structured arguments with HOL Guard before execution;
  • explicit allow leaves the pending call intact so it executes once;
  • deny removes/rejects the pending call before execution;
  • review-required remains non-executable until explicitly resolved rather than silently becoming allow;
  • Guard timeout, unavailable runtime, malformed output, or unknown decision fails closed for the protected call;
  • bounded diagnostics that do not echo secrets/tool arguments on failure.

Verification

The integration should include deterministic tests proving:

  1. allow -> the protected Haystack tool executes exactly once;
  2. deny -> the protected tool executes zero times;
  3. review/error/timeout/malformed result -> zero executions by default;
  4. no integration configured -> normal Haystack behavior is unchanged.

The README would document installation, an Agent(..., hooks={"before_tool": [...]}) example, supported Haystack/HOL Guard versions, local test commands, and the exact data passed to Guard.

I maintain HOL Guard and am disclosing that affiliation. I searched this repository's current issues and PRs for HOL Guard / hol-guard and found no existing integration proposal. If maintainers agree this belongs in Core Integrations, I can follow the repository's fork-first workflow and keep the implementation limited to the integration package, tests, and docs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions