My org has been considering enabling Bugbot, but concerns over the reliability of Cursor’s ability to gate Bugbot have come to question.
When a user has broad access to a Gitlab tenant, how does Bugbot’s user/admin repository selection reliably gate Bugbot from working outside of the restricted scope? Could any Cursor representatives sum the mechanism up in a nutshell and provide any assurance that could be relayed to our team that the system is reliable?
Hello,
We have the same issue, especially since the bugbot users seem to be created as project users, so quite a lot of access tokens.
On the other hand, we managed to get the cloud agents to work on gitlab, but we are a bit confused about when they are using the user’s tokens/credentials (for example to retrieve dependencies) or when they are using this bugbot user credentials (it seem those are used to add comments, or to add commits). Our problem then is that the pipelines triggered may lack required authorizations.
Would be great to have some cleaner rules to set this up for the admin, as ultimately both members and admin in Cursor seem to be able to activate the gitlab integration, without the setting being shared at the organization level ?
Example :
only admins can add the gitlab integration.
need to manually provide credentials for a user dedicated to Bugbot (that can comment) and one dedicated to the agent, that would be able to commit and trigger pipelines.
Thus, we would be able to add the proper scopes for each token but have a lot more control
Many thanks for the answers, at least some clear explanation about how you guys plan to handle this
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.