<!--This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ## Summary The first iteration of tool approvals introduced a session-based approval system using exact `(tool_name, tool_args)` hashing to minimize unnecessary re-approvals while maintaining a strong security default. This iteration extends that model with a **wildcard approval tier**, allowing users to approve all uses of a given tool for a session. Effectively reducing approval fatigue in common multi-step workflows without compromising the existing security floor. --- ## Motivation The v1 approval model defaults to the safest possible behavior: a tool call is auto-approved only when its exact name _and_ arguments have been previously approved. While this is correct for dangerous tools, it creates friction in common workflows where users are comfortable trusting a tool broadly. For example, a user running a series of `npm` commands should not need to approve each one individually. --- ## Proposed Change Introduce a third approval option alongside the existing `Approve` and `Approve tool for Session`: > **"Approve all uses of this tool for Session"** This stores a wildcard entry in the session approval store: `{ tool_name, * }` rather than `{ tool_name, tool_args }`. ### Approval Tiers | User Action | Stored Entry | Match Behavior | |-------------|--------------|----------------| | Approve | _(not stored)_ | One-time approval | | Approve tool for Session | `{ hash(tool_name, tool_args) }` | Exact match only | | Approve all uses for Session | `{ tool_name, * }` | Any args for this tool | --- :white_check_mark: - Done :construction: - In Progress :white_circle: - Not Started ### :sparkles: Pre-existing work All pre-existing work surrounding tool approvals and enabling more autonomous modes in Duo Agentic Platform can be found in the parent epic: https://gitlab.com/groups/gitlab-org/-/work_items/20519+. ### :sparkles: Core Foundational Elements <table> <tr> <th></th> <th>Description</th> <th>Sub Epic / Issues</th> <th>Status</th> <th>Technical Lead</th> </tr> <tr> <td>Allow for Pattern/Wild Card Tool Approval per Session - GitLab</td> <td> * The monolith needs to provide support and add a data field for pattern approvals. This issue outlines that implementation. </td> <td> https://gitlab.com/gitlab-org/gitlab/-/work_items/598446+ </td> <td> :white_check_mark: </td> <td> @dbernardi </td> </tr> <tr> <td>AI Gateway: Allows for Pattern Approval</td> <td> * AI Gateway needs to send capabilities and handle approval creation logic for downstream handlers </td> <td> https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2219+ </td> <td> :white_check_mark: </td> <td> @dbernardi </td> </tr> <tr> <td> \[LSP\] Enable Pattern Tool Approvals </td> <td> * LSP needs to gate pattern tool approvals from capabilities received on the backend. * LSP also needs to surface and send data correctly provided as options for pattern approvals. </td> <td> https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/work_items/2349+ </td> <td> :white_check_mark: </td> <td> @dbernardi </td> </tr> <tr> <td> \[Duo UI\] Ensure patterns can be sent alongside tool approval modals </td> <td> * The pattern approach pitched by the backend requires an updated field in Duo UI </td> <td> https://gitlab.com/gitlab-org/duo-ui/-/work_items/117+ </td> <td> :white_check_mark: </td> <td> @dbernardi </td> </tr> <tr> <td> \[LSP\]\[CLI\] Ensure Pattern Tool Approval is CLI accessible </td> <td> * The CLI interface needs to surface pattern approval options in the TUI </td> <td> https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/work_items/2476+ </td> <td> :white_check_mark: </td> <td> @dbernardi </td> </tr> </table> ### :sparkles: Followup <table> <tr> <th></th> <th>Description</th> <th>Sub Epic / Issues</th> <th>Status</th> <th>Technical Lead</th> </tr> <tr> <td>AI Gateway: Improve matching logic for multiple command patterns</td> <td> * There is room to improve the logic in which we decide which patterns to approve when new patterns are submitted. * Read the issue for more details. </td> <td> https://gitlab.com/gitlab-org/gitlab/-/work_items/602124+ </td> <td> :white_check_mark: (2/2) </td> <td> @dbernardi </td> </tr> <tr> <td>Rails: Replace denylist with per-subcommand allowlist</td> <td> * The GitValidator architecture should use an allowlist that exists per known subcommand. * The current state is safe, but requires lots of maintenance </td> <td> https://gitlab.com/gitlab-org/gitlab/-/work_items/602494+ </td> <td> :construction: (0/2) </td> <td> @dbernardi </td> </tr> <tr> <td>AI Gateway: Remove unused check on RunCommand</td> <td> * Remove the `_DISALLOWED_OPERATORS` and `_DISALLOWED_COMMANDS` blocklists from `RunCommand`. These checks are dead code and `RunCommand` sends structured args that are never shell-interpreted. * Validation lives in Rails via GraphQL. </td> <td> https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2399+ </td> <td> :construction: </td> <td> @dbernardi </td> </tr> </table> ### :sparkles: Documentation! <table> <tr> <th></th> <th>Description</th> <th>Sub Epic / Issues</th> <th>Status</th> <th>Technical Lead</th> </tr> <tr> <td>Release Post</td> <td> * This will include the newest feature settings as part of the large GitLab release post </td> <td> https://gitlab.com/gitlab-org/gitlab/-/merge_requests/240475+ </td> <td> :white_check_mark: </td> <td> @james.casey </td> </tr> <tr> <td>Documentation for Pattern Approve for Session</td> <td> * Include updates for users and any legal disclaimers surrounding wild card/pattern approvals </td> <td> https://gitlab.com/gitlab-org/gitlab/-/work_items/598462+ </td> <td> :white_check_mark: </td> <td> @uchandran / @dbernardi </td> </tr> </table>