Target: open-multi-agent/open-multi-agent
Issue: open-multi-agent/open-multi-agent#96
Pull request: open-multi-agent/open-multi-agent#377
Field test status: merged upstream.
The requested capability
Open Multi Agent already supported tool access controls through presets, allowlists, and denylists.
Those controls could decide whether an agent was allowed to use a tool such as bash or a filesystem tool.
The missing layer was more precise.
Even when a tool is allowed, a specific invocation may still need to be approved or denied based on its validated arguments, the current agent, or the surrounding application context.
The issue therefore was not simply:
“Can this agent use this tool?”
It was:
“Should this particular call be allowed to execute?”
The boundary
The correct decision point was inside the existing tool execution path:
after input validation and before the tool implementation runs
That placement matters.
Before validation, the framework does not yet have a reliable call to evaluate.
After execution begins, the decision is already too late.
The contribution added a narrow governance hook at the point where tool access becomes a concrete side effect.
What changed
The PR added a public per-call tool gate API, including:
ToolCallContext
ToolCallDecision
ToolCallGate
ToolCallGateMetadata
Applications can now provide an optional onToolCall handler through the agent and orchestrator configuration.
The gate runs inside ToolExecutor after Zod input validation and before tool.execute().
If a call is denied, the tool implementation is not invoked. The framework returns a normal error ToolResult instead.
The PR also added trace metadata showing whether the gate was evaluated, what action was taken, and the reason when one was provided.
Why this was not a broad security rewrite
The contribution did not add a complete policy engine.
It did not add the optional shell-risk classifier discussed in the issue.
It did not redesign sandboxing or process isolation.
It also did not replace the existing allowlist and denylist model.
Disallowed tools are still blocked before the new gate is reached.
The patch added one missing boundary: a final application-defined decision point for a validated tool invocation.
Why this matters
Tool-level permissions are necessary, but they are not always enough.
The same shell tool can run a harmless command or a destructive one.
The same filesystem tool can read a project file or remove an entire directory.
The risk often depends on the actual arguments and context, not only the tool name.
A per-call gate gives application developers a way to make that decision at runtime without forcing the framework to define one universal policy for every use case.
That makes the feature useful for approval flows, contextual restrictions, workspace rules, custom risk checks, and other forms of application-level governance.
The Scarab reading
This was a governance-boundary feature.
The existing access controls governed whether a tool was available.
Input validation governed whether the call was structurally valid.
The new gate governs whether that validated call should cross into execution.
That separation keeps the framework’s responsibilities clear.
The Scarab boundary is:
A tool call should not become an executed side effect merely because the tool is available and its arguments are valid. Applications should have a final decision point before execution.
Validation
The contribution passed the repository’s required lint and test checks.
Additional build, coverage, scaffold, and package checks also passed.
The pull request was subsequently accepted and merged upstream.
Field result
Result:
Merged upstream agent-governance feature.
The contribution added:
- a typed per-call tool gate
- integration through agent and orchestrator configuration
- evaluation after validation and before execution
- normal result handling for denied calls
- trace metadata for gate decisions
- preservation of the existing tool access model
This does not claim to solve agent security as a whole.
It adds the missing framework boundary where application-defined governance can decide whether a specific validated tool call should run.
Public claim
Scarab/SDS helped frame a bounded feature contribution for open-multi-agent/open-multi-agent#96.
The merged PR adds a public per-call tool gate that runs after input validation and before tool execution. It allows applications to approve or deny individual invocations while preserving the framework’s existing presets, allowlists, and denylists.
The result is a narrow but important governance boundary between validated agent intent and actual tool side effects.
Disclosure: This field report was prepared with AI-assisted editing from public issue and pull-request records, validation notes, and the merged contribution record. The technical claims and final wording were human reviewed.
Top comments (0)