💡 Still using the classic Drata experience? Refer to Manage and link connected version control accounts for the original UI.

What’s changed

Managing version control accounts is now handled through a dedicated page in the New Experience.
Instead of accessing account management from an individual connection card, you can now review and manage infrastructure accounts from the Connections page → Version Control page.

Overview

The Version Control page shows accounts discovered through your connected version control systems.

This page helps you:

View which version control accounts Drata is monitoring
Understand which accounts represent individual users versus service accounts
Link accounts to personnel
Review access indicators such as write access, merge permissions, and MFA status

Prerequisites

Before managing version control accounts in Drata:

A version control system (such as GitHub, GitLab, or Bitbucket) must be connected
An identity provider must be connected to sync personnel into Drata

Drata uses read-only access to collect version control account data and does not modify permissions or access levels in your version control system.

How version control accounts appear in Drata

After a version control system is connected, Drata automatically syncs detected user accounts.

In many cases, Drata attempts to automatically link accounts to personnel based on matching attributes such as name or email. If a match cannot be determined, the account remains unlinked.

Some version control providers may not share enough information for automatic matching. In these cases, accounts must be linked manually.

Link version control accounts to personnel

For a complete explanation of how account linking works across Drata, including how service accounts are handled, refer to Linking accounts to personnel in Drata.

Access changes and audit trail

When access to a version control account is removed in the provider, Drata detects and records the change.

Deleting an account in your version control system does not remove it from Drata. Instead, Drata records a timestamp indicating when access was revoked under the Access revoked column. This preserves an audit trail used to demonstrate timely access removal and track access control SLAs.

Changes made in the provider may take time to appear in Drata due to sync timing.

Access indicators: Write Access, Merge to default branch, and MFA

Drata looks at your version control system and reads certain access signals about each account. These signals help Drata understand how powerful an account is, but Drata cannot change them.

Write access → Can this account push code?
Merge to default branch → Can this account push directly to production?
MFA status → Is extra authentication required to log in?

Write Access and Merge to default branch

The Write access and Merge to default branch column has checkboxes which are used to confirm the level of access an account is expected to have.

Checking these boxes:

Does not change permissions in your version control system
Helps Drata understand which access is intentional
Is used to evaluate access-related compliance checks

You should select these options only when the account is meant to have that level of access in the source system. If the access shown in your version control tool doesn’t match what’s selected here, related tests may fail. To actually change permissions, update the account directly in your version control system.