You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: Semaprax policy-plugin example for before_tool_callback #7378
Is your feature request related to a specific problem?
ADK has a global BasePlugin.before_tool_callback that can skip a tool by returning a result dictionary. Users integrating an external deterministic policy need a concrete pattern for binding that decision to the current tool name, arguments, and trusted ToolContext, then returning an understandable denial without invoking the tool.
Describe the Solution You'd Like
Add an opt-in sample plugin using Semaprax as the policy evaluator. It should show one allowed and one denied function-tool call, use None only for the allow path, and return a structured denial for the blocked path. The example should explain how to obtain a trusted caller identity from the ADK application rather than reading one from model-supplied arguments. It should state the coverage of ordinary and live runs; #4704 tracks a separate live plugin-callback gap.
Impact on your work
A developer could express argument-sensitive permission rules in checked code while ADK continues to own agent/tool execution. No deadline or production deployment is claimed.
Willingness to contribute
I can provide a detailed adapter specification and test cases; I am not claiming an implementation exists yet.
Alternatives considered
An agent-level prompt or after-tool callback cannot prevent the tool effect. The existing before-tool plugin API is the intended integration point.
Hi @wsdt, I’m interested in working on this issue.
I’ll first investigate the existing plugin sample structure and before_tool_callback flow, along with the Semaprax integration surface, and then prepare a focused implementation covering the allowed/denied tool-call examples and corresponding tests.
I’ll keep the scope limited to the requested opt-in example and avoid changes related to the separate live plugin-callback gap tracked in #4704.
Hi @wsdt, thanks for the detailed feature request and for offering a spec and test cases. We've noted the request for a policy-plugin example using before_tool_callback, and the team is reviewing it.
Thanks for your patience in the meantime.
hi @wsdt, thanks for the proposal. we'd rather not carry a sample tied to a specific policy engine in this repo, since contributing/samples/hitl/classifier_tool_gate (in v2.13.0) already covers allowing or denying tool calls from before_tool_callback, and #4704 was fixed in v1.27.0 so plugin tool callbacks work in live mode as well. for a trusted caller identity, you'll want to read tool_context.user_id, which your app passes to the runner, instead of trusting the model's arguments. a semaprax adapter would make the most sense in semaprax's own repo, and you can propose it for https://adk.dev/integrations/ with a pull request to google/adk-docs. @vinitsonawane45, thanks for offering to pitch in; that repo would be the place for it.
Activity
vinitsonawane45 commentedon Oct 2, 2026
Hi @wsdt, I’m interested in working on this issue.
I’ll first investigate the existing plugin sample structure and
before_tool_callbackflow, along with the Semaprax integration surface, and then prepare a focused implementation covering the allowed/denied tool-call examples and corresponding tests.I’ll keep the scope limited to the requested opt-in example and avoid changes related to the separate live plugin-callback gap tracked in #4704.
sanketpatil06 commentedon Oct 5, 2026
Hi @wsdt, thanks for the detailed feature request and for offering a spec and test cases. We've noted the request for a policy-plugin example using
before_tool_callback, and the team is reviewing it.Thanks for your patience in the meantime.
GWeale commentedon Oct 26, 2026
hi @wsdt, thanks for the proposal. we'd rather not carry a sample tied to a specific policy engine in this repo, since contributing/samples/hitl/classifier_tool_gate (in v2.13.0) already covers allowing or denying tool calls from before_tool_callback, and #4704 was fixed in v1.27.0 so plugin tool callbacks work in live mode as well. for a trusted caller identity, you'll want to read tool_context.user_id, which your app passes to the runner, instead of trusting the model's arguments. a semaprax adapter would make the most sense in semaprax's own repo, and you can propose it for https://adk.dev/integrations/ with a pull request to google/adk-docs. @vinitsonawane45, thanks for offering to pitch in; that repo would be the place for it.