Proposal
Add a maintained Strands Agents sample showing HOL Guard itself at the existing InterventionHandler.before_tool_call boundary for a command-bearing tool such as shell.
The sample would install HOL Guard separately, invoke hol-guard command test <command> --json before tool execution, and only return Proceed when the command is explicitly classified benign with minimum_action == "allow". Review/risky/unknown results, malformed output, timeout, or an unavailable Guard executable should return Deny; the intervention should also use fail-closed error handling (onError = "deny" / Python equivalent).
The important test property is the execution boundary:
- explicitly benign / allow -> the wrapped tool executes exactly once;
- review or risky -> the wrapped tool executes zero times;
- malformed Guard output, timeout, or missing Guard executable -> the wrapped tool executes zero times.
This would be a sample-only contribution using the intervention API Strands already ships. It would not request a new SDK primitive.
Scope / security boundary
hol-guard command test is a side-effect-free command inspection surface. The sample should describe it that way rather than implying full HOL Guard runtime policy, Cloud approvals, receipts, or native Strands harness protection.
That keeps the example small and makes the integration behavior easy to verify directly at the pre-execution boundary.
HOL Guard project: https://github.com/hashgraph-online/hol-guard
If this sample placement is useful, I can follow the repository's new-sample structure and open the focused implementation PR.
Proposal
Add a maintained Strands Agents sample showing HOL Guard itself at the existing
InterventionHandler.before_tool_callboundary for a command-bearing tool such asshell.The sample would install HOL Guard separately, invoke
hol-guard command test <command> --jsonbefore tool execution, and only returnProceedwhen the command is explicitly classified benign withminimum_action == "allow". Review/risky/unknown results, malformed output, timeout, or an unavailable Guard executable should returnDeny; the intervention should also use fail-closed error handling (onError = "deny"/ Python equivalent).The important test property is the execution boundary:
This would be a sample-only contribution using the intervention API Strands already ships. It would not request a new SDK primitive.
Scope / security boundary
hol-guard command testis a side-effect-free command inspection surface. The sample should describe it that way rather than implying full HOL Guard runtime policy, Cloud approvals, receipts, or native Strands harness protection.That keeps the example small and makes the integration behavior easy to verify directly at the pre-execution boundary.
HOL Guard project: https://github.com/hashgraph-online/hol-guard
If this sample placement is useful, I can follow the repository's new-sample structure and open the focused implementation PR.