SailPoint’s October 30, 2026 release notes list the availability of its Connectivity – GitLab connector. The same entry says it is read-only and does not support provisioning. For a team planning an identity review, this boundary matters: discovering an account or token is a different step from changing its access.
SailPoint’s October 30 release notes: Connectivity – GitLab
What the announced visibility covers
The release entry describes aggregation of users, groups and projects, plus discovery of personal, group and project access tokens and associated bot users. It also names group and project service accounts and security policy bots. This is the connector described in that entry; it should not be confused with GitLab’s own Orbit product or every other SailPoint integration.
Read the explicit limitation before planning a workflow
The linked connector guide, revised October 28, supports GitLab.com and self-managed instances, including Dedicated deployments on customer domains. Its introduction contains general wording about provisioning changes, but the explicit note says provisioning is unsupported. That note states the connector aggregates and reports without creating, updating, disabling or deleting GitLab objects or managing entitlement assignments.
Connector guide and explicit read-only limitation
Plan the review around that stated limitation. A discovered item is evidence for a decision; it is not evidence that the decision has already been carried out. Do not mark access as removed solely because it appears in an identity inventory or review worksheet.
Use two separate completion checks
Imagine a fictional training review containing a service account called Build Helper. The reviewer records a finding and decides that an access change needs investigation. Mark the discovery task complete when the expected record has been inspected. Keep the follow-up task open until the responsible administrator has assessed and, where authorized, completed the appropriate action.
Give the follow-up its own owner, evidence and completion criterion. In this fictional worksheet, those fields might be: platform administrator; a dated record of the authorized change; and a check of the relevant current state. These are suggested review fields, not claims about built-in connector features or a tested remediation process.
Reconcile the review with the current source
For an approved evaluation, choose a small set of known training records and write down what you expect to discover. Record the source instance and review time. If an expected item is absent, document the observation and ask the platform owner to investigate rather than guessing why it is missing.
Keep inventory findings and completed actions distinguishable when reporting progress. A team can finish collecting evidence while still having follow-ups to resolve. No SailPoint tenant, GitLab instance, aggregation run or access-change operation was tested for this article; the proposed worksheet does not establish discovery coverage or remediation success in any deployment.
Separate discovery from action
