The vulnerability stemmed from two primary failures in access control. First, in authenticated non-owner DM sessions, the code path for handling tool invocations, specifically the handleInlineActions function, did not correctly apply policies to prevent non-owners from accessing owner-only tools like cron and gateway. The vulnerable code would select a tool from an unfiltered list, bypassing ownership checks.
Second, when a privileged tool was invoked by a non-owner, the underlying gateway calls made by that tool were not properly scoped. The callGatewayTool function, used by the gateway tool, would call the internal gateway API without specifying least-privilege scopes. This caused the callGateway function to fall back to a default set of highly privileged, admin-level scopes (operator.admin), allowing the non-owner to perform administrative actions.
The patches address this by first centralizing owner-only tool enforcement via the applyOwnerOnlyToolPolicy function, which is now called within handleInlineActions to filter and guard tools before execution. Secondly, the gateway was refactored to be data-driven, where every method is explicitly mapped to a least-privilege scope. The callGatewayTool function was updated to always resolve and use these minimal scopes, removing the reliance on the dangerous default. A runtime profile during exploitation would likely show handleInlineActions calling the execute method of a restricted tool (e.g., createGatewayTool), which in turn calls callGatewayTool with escalated privileges.