There is a setting in GitLab that disables new project members from being added: https://docs.gitlab.com/user/group/access_and_permissions/#prevent-members-from-being-added-to-projects-in-a-group Right now, this means that features which use composite identity will not work in projects that enable this setting See bug report [Slack thread](https://gitlab.slack.com/archives/C07035GQ0TB/p1760485865617749) > I tried several UI-based use cases including Issue-MR and the Jenkins-CI buttons and in each case, the Agent session gets opened, but never does anything at all, no logs, no nothing and eventually fails with no details. This fails because composite identity requires that the service account being used is added to the project. ## Proposed Solution Original reasoning in https://gitlab.com/gitlab-org/gitlab/-/issues/577607#note_3081699815: Adding composite identity Service Accounts should ignore the setting. This will allow flows and external agents to be added, even if the feature is turned on. ### Reasoning Original explanation in https://gitlab.com/gitlab-org/gitlab/-/issues/577607#note_3081699815 The set of human users who can act on the project doesn't change. The composite identity SA is just a constrained proxy for an already-authorized human, not a new actor. This is fundamentally different from a `project_bot` / `security_policy_bot` comparison, since those bots act autonomously whereas composite identity SAs literally cannot. There's also precedent for this, SAs were [already excluded from LDAP group sync enforcement](https://gitlab.com/gitlab-org/gitlab/-/work_items/425947) for the same practical reasons. The compliance concern there was identical (LDAP sync is the SSoT, don't let anything bypass it), and the resolution was the same: exempt SAs because requiring admins to disable the setting, add the SA, and re-enable it doesn't scale. We're hitting the exact same pattern here with "prevent member invitations".