AutoModeMiddleware Can Be Bypassed When An Inner Middleware Replaces The Tool Call Before Execution

Middleware composition applies the first middleware as the outermost wrapper. AutoModeMiddleware.wrap_tool_call() classifies the incoming request before forwarding to the inner handler. If an inner wrapper replaces the ToolCallRequest (e.g., HITL edit), the replacement is never re-evaluated by AutoModeMiddleware. There is no ordering validation or capability metadata to ensure policy middleware inspects the final request.

Run the provided reproduction script with `middleware=[AutoModeMiddleware(tools=[delete_file]), HumanInTheLoopMiddleware(interrupt_on={'draft_file': ...})]`. Observe that after HITL edit changes 'draft_file' to 'delete_file', the classifier call count is 0 and `/tmp/demo.txt` is deleted, showing that AutoModeMiddleware never saw the final delete_file call.

This validation will break existing code that places AutoModeMiddleware before other middleware; users must reorder their middleware list (e.g., `middleware=[hitl, auto_mode]`). It only checks for AutoModeMiddleware specifically; future custom middleware that replaces ToolCallRequest and is placed after AutoModeMiddleware could still bypass the policy. A long-term solution should introduce middleware capability metadata and automatic ordering validation in create_agent. Rollback: remove this wrapper and use the original create_agent, but the vulnerable ordering remains. Also be aware that moving AutoModeMiddleware to the end may affect interrupt timing if other middleware expect to run after classification.