zmuxuny opened a new issue, #6027: URL: https://github.com/apache/rocketmq-dashboard/issues/6027
### Before Creating the Enhancement Request - [x] I have confirmed this is an enhancement rather than a bug or a new feature. - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and believe this is not a duplicate. ### Summary ## Tracking continuation (2026-10-10) This replaces #5385, which was automatically closed by github-actions[bot] for inactivity on 2026-10-10. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. The hosted-run human-approval versus explicit autonomous-delegation contract remains unanswered. No product-policy approval or broader approval-workflow implementation is claimed. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5385. Should every hosted-agent mutation require a server-recorded human approval, or may an administrator explicitly delegate an autonomous run? Agree the desired product contract before implementing a broader approval workflow. ### Motivation Operators need a clear guarantee about which actions a hosted agent can perform after a run starts, how they approve a proposed change, and how they cancel or revoke that approval. Read-only assistance, per-operation approval and explicitly delegated automation have different user expectations and should be visibly distinguishable. ### Describe the Solution You'd Like Please choose the intended hosted-run model: A. Hosted runs produce read-only results and previews; the human applies mutations in the UI. This has the smallest approval surface. B. Hosted runs create pending operations bound to the authenticated owner, conversation/run, exact tool/instance/input and expiry. A human-only approval endpoint executes the operation or releases an atomically consumed capability. C. Administrators may explicitly delegate autonomous runs. Show the selected mode and its scope clearly before starting, with documented stop/revocation behavior. For mandatory approval, acceptance criteria should cover cancellation, expiry, owner checks, concurrent/repeated approvals, exact operation binding, restart/high-availability policy, and trusted classification of hosted requests. External trusted rmqctl workflows should remain compatible unless an intentional protocol change is agreed. Reuse the single-use work in #4665 instead of duplicating it. The choice of product-level human approval guarantee is a separate decision. ### Describe Alternatives You've Considered A generic delay or recognizing a word such as “yes” is not an adequate approval contract. Requiring interactive confirmation from every external automation client would change supported rmqctl use, so hosted and external workflows need explicit boundaries. If explicit autonomous delegation is the desired model, document that guarantee rather than presenting every run as individually human-approved. ### Additional Context Searched open/closed issues and PRs for hosted/human approval. #4665 covers confirmation-token single-use; #4979 covers when an interactive rmqctl terminal displays its preview and is a different UI path. This is a product/design enhancement request, not a claim of a demonstrated vulnerability or unauthorized access. ### Are You Willing to Submit a Pull Request? - [ ] Yes, I am willing to submit a pull request. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
