Expose workflow control to hosted MCP clients - #25
Conversation
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (3)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b73c312b30
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Grant both as the API's default third-party user permissions so dynamically | ||
| registered and other self-registering clients receive both scopes. |
There was a problem hiding this comment.
Keep workflow control out of default DCR permissions
Granting qyl:control as a default permission gives every dynamically registered client mutation authority after authorization. The server only checks that this scope is present before forwarding a steer, interrupt, or resume command; the advertised destructive/approval annotation is client-side metadata that an arbitrary self-registering client can ignore. This removes the explicit client-grant boundary and allows such a client to interrupt any discoverable active run, so retain a deliberate grant for qyl:control or add a server-enforced approval boundary.
Useful? React with 👍 / 👎.
| Grant both as the API's default third-party user permissions so dynamically | ||
| registered and other self-registering clients receive both scopes. |
There was a problem hiding this comment.
Restore the warning about public telemetry registration
This instruction still makes qyl:read a default permission while the preceding setup enables Auth0 Dynamic Client Registration, but the commit deletes the only warning that Auth0 DCR is open and therefore lets anyone self-register and read the deployment's telemetry after authorization. Operators following this deployment guide can now expose traces, logs, sessions, and CI evidence without being told to make that decision deliberately or restrict DCR with the tenant ACL, so retain that disclosure and mitigation guidance.
Useful? React with 👍 / 👎.
Summary
qyl:readandqyl:controlscopesThe baseline resource-server requirement remains
qyl:read;control_workflow_runseparately enforcesqyl:controlat the tool boundary. This PR does not change the Auth0 tenant.Validation
git diff --check