AssistantAgent may ask for approval before executing a tool

[ekzhu]

autogen_agentchat.agents.AssistantAgent currently executes a given tool directly. If user approval for the tool is needed, the approval needs to be builtin to the tool itself.

It would be more convenient to have a built-in mechanism to for tool approval. This will simplify many tool use scenarios.

We can make it part of the autogen_core.tools.Tool and create a tool wrapper class that automatically create the approval boilerplate code around the tool itself.

the approval/confirmation for running query is not.

I believe for approval of running the tool, it should not depend on the agent, rather, it should be built into the tool itself, and have the tool returns a well-formed error message if the user rejects it. It is a general pattern that we may incorporate into the AssistantAgent itself. A PR contribution is welcome!

Originally posted by @ekzhu in #4886 (comment)

[vdineshk]

Tool approval is a critical safety mechanism, but the approval decision itself can be informed by behavioral data about the tool being called.

The pattern we see in production:
When an agent decides whether to approve a tool execution, the key question is: "Has this tool been behaving reliably?" Static approval (always-approve or always-deny lists) doesn't capture runtime degradation, anomalous behavior, or compliance violations.

Behavioral trust as an approval signal:
Dominion Observatory tracks 14,800+ MCP servers and provides real-time behavioral trust scores. An AutoGen tool approval wrapper could query this before granting execution:

from autogen_core.tools import Tool

class TrustGatedTool(Tool):
    """Wraps any tool with behavioral trust verification."""
    
    async def should_approve(self, tool_name: str) -> bool:
        # Query Observatory for behavioral trust score
        trust = await observatory.check_trust(server_url=tool_endpoint)
        anomaly = await observatory.check_anomaly(server_url=tool_endpoint)
        
        if trust.score < self.threshold or anomaly.is_anomalous:
            return False  # Block execution, tool is degraded
        return True

This complements the human-in-the-loop approval you're proposing — automated trust gating handles the 99% of cases where behavioral data is sufficient, and human approval is reserved for edge cases or novel tools with no behavioral history.

The Observatory MCP endpoint is live at https://dominion-observatory.sgdata.workers.dev/mcp with tools: check_trust, check_anomaly, get_baselines.

[arian-gogani]

tool approval decisions should be captured in signed receipts. when a human approves a tool execution, the approval itself needs to be tamper-evident.

the receipt carries: which tool was proposed, who approved it, the policy_version in effect, and the timestamp. if a tool execution is later questioned, the receipt proves the approval happened without trusting the runtime logs.

the nobulex receipt format has a verdict field (ALLOW/DENY) designed for exactly this pattern. a human-in-the-loop approval generates an ALLOW receipt. a rejection generates a DENY receipt. both are Ed25519 signed.

github.com/arian-gogani/nobulex

[rpelevin]

One contract I would preserve here is that approval should be a tool-invocation precondition, not a model instruction.

A Tool wrapper is the right shape if the wrapper owns the state transition before the underlying tool's run is called. The model can propose the call, but the executor should only be able to cross into the real tool after the wrapper has consumed a matching approval decision.

For a minimal acceptance test set, I would make the binding explicit:

1. assistant proposes a tool call that requires approval;
2. wrapper records a pending decision with tool_name, canonical args digest, and tool_call_id;
3. without an approved decision, the underlying tool is not called;
4. deny returns a structured tool result/error and leaves execution count at zero;
5. approve is one-shot and only valid for the same tool plus args digest;
6. changed args, expired approvals, or reused approval ids fail closed;
7. the same behavior holds whether the tool is invoked directly or through AssistantAgent.

The important bit is that rejection or expiry is not just natural-language feedback to the model. It is terminal state for that proposed call. Otherwise the model can simply retry the same tool call and turn approval into a prompt convention instead of an execution boundary.

[sunfishloop]

The Tool wrapper approach is the right shape. One thing that made this practical for us in production: tie the approval authority to the agent's wallet key rather than a runtime identity.

Each agent registers with an ETH/SOL/BTC keypair. When a tool execution needs approval, the wrapper generates a pending receipt with tool_name, arg_schema, and policy_version. The human (or automated guard) signs an ALLOW or DENY receipt using their own wallet key. The wrapper only calls tool.run(...) after it has a matching ALLOW receipt signed by an authorized key.

This sounds heavyweight but in practice it's a few lines of state management in the wrapper. The payoff: the signed receipt exists outside the runtime. Even if the entire agent state is lost, you can verify that tool X was approved by key Y at time Z. For multi-agent systems, this also means agents can prove to each other that an action was authorized — useful when agents from different frameworks (we run CrewAI, AutoGen, and LangGraph side by side) need to verify cross-framework tool calls.

We open-sourced this pattern — the receipt schema and the execution guard are both in the repo: https://github.com/sunfishloop/sunfishloop

Each agent exposes a /llms.txt with the receipt schema endpoint, so discovery doesn't require a shared runtime or central registry.

[rpelevin]

The signed-receipt pattern can fit this wrapper design, but I would keep one distinction explicit: a signature proves a decision record; it does not by itself decide whether the current invocation is authorized.

For the Tool wrapper, I would make the verification tuple explicit:

1. host-derived tool name;
2. canonical args digest for the exact proposed invocation;
3. policy version / approval rule version;
4. signer identity checked against allowed approvers for that action;
5. expiry and one-shot receipt id.

Then tool.run(...) only happens after the wrapper verifies an ALLOW receipt against that tuple. DENY, expiry, changed args, missing verifier, unknown signer, or reused receipt all stop before the underlying tool call.

That preserves the cross-framework benefit of signed receipts without making discovery, key possession, or a model-reported approval claim equivalent to authority. A receiving wrapper can accept a portable receipt, but it still has to re-derive the invocation and verify the receipt against the exact call it is about to execute.

[Keesan12]

Built-in approval support would help a lot, but I’d be careful not to make the approval itself the only source of truth.

In practice there are at least three states operators care about:

• approval requested / granted / denied
• execution attempted or not attempted
• proof of what actually happened afterward

If those get collapsed into one abstraction, review gets muddy fast, especially once tools have real side effects.

My bias would be to make approval a structured event in the execution record, not just a wrapper around the tool. That leaves room for later audit, retries, and clearer operator UX.

That separation has made a big difference for me using MartinLoop around governed runs, because approval without evidence still leaves a lot of unanswered questions later.