Internal users

GitLab uses internal users (sometimes referred to as “bots”) to perform actions or functions that cannot be attributed to a regular user.

Internal users:

• Are created programmatically and do not count towards a license limit.
• Are used when a traditional user account isn’t applicable. For example, when generating alerts or automatic review feedback.
• Have reduced access and a very specific purpose. They cannot be used for regular user actions, such as authentication or API requests.
• Have email addresses and names that can be attributed to any actions they perform.

Internal users are sometimes created as part of feature development. For example, the GitLab Migration Bot for migrating from GitLab Snippets to Versioned Snippets. GitLab Migration Bot was used as the author of snippets when a snippet’s original author wasn’t available. For example, when the user was disabled.

Other examples of internal users:

• GitLab Automation Bot
• GitLab Security Bot
• GitLab Security Policy Bot
• Alert Bot
• Ghost User
• Support Bot
• Placeholder User created during imports
• Visual Review Bot
• Resource access tokens, including project access tokens and group access tokens, which are project_{project_id}_bot_{random_string} and group_{group_id}_bot_{random_string} users with a PersonalAccessToken.

GitLab Admin Bot

GitLab Admin Bot is an internal user that cannot be accessed or modified by regular users and is responsible for many tasks including:

• Applying default compliance frameworks to projects.
• Automatically deactivating dormant users.
• Automatically deleting unconfirmed users.
• Deleting inactive projects.
• Locking users.

GitLab Security Bot

GitLab Security Bot is an internal user responsible for commenting on merge requests that violate a security policy.

GitLab Security Policy Bot

GitLab Security Policy Bot is an internal user responsible for triggering scheduled pipelines defined in security policies. This account is created in every project on which a security policy is enforced.