GitLab access lifecycle automation reveals the NHI governance gap

At a glance

What this is: This is a vendor walkthrough of automating GitLab user lifecycle tasks, with an emphasis on onboarding, offboarding, permissions updates, and license monitoring.

Why it matters: It matters because the same lifecycle gaps that create user access sprawl in GitLab also map to broader IAM and NHI governance problems when privileges are not reviewed, revoked, or right-sized.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's guide to GitLab access automation and lifecycle controls

Context

GitLab access lifecycle automation is about reducing the manual work of onboarding, offboarding, and permission changes, but the governance problem does not disappear when the workflow is automated. If access is not continuously reviewed and removed with the same discipline it was granted, GitLab becomes another place where entitlement drift accumulates.

For IAM teams, the useful question is not whether a workflow can be automated. It is whether the automation is enforcing lifecycle discipline for the right identity type, with auditable removal, privilege updates, and usage visibility before stale access becomes a control failure.

Key questions

Q: How should security teams govern GitLab access lifecycle automation?

A: Security teams should govern GitLab automation by tying every add, change, and remove action to a verified source of truth and a completion check. The goal is not just to trigger workflows, but to prove that effective access was removed across users, groups, projects, and feature flag scopes when business need ended.

Q: Why does GitLab offboarding still create identity risk after automation?

A: GitLab offboarding still creates risk because access can survive in multiple scopes even after the user is deactivated. If teams do not confirm revocation across groups, projects, and tokens, the account may be gone while the permissions remain live. That is the control failure practitioners need to eliminate.

Q: What do IAM teams get wrong about GitLab license optimisation?

A: IAM teams often treat license cleanup as separate from access governance, but inactive users can still hold meaningful permissions. Optimising spend without checking effective access can leave dormant but privileged accounts in place. The better approach is to reclaim licenses only after entitlement review confirms that access is no longer needed.

Q: Who is accountable when GitLab access is not fully revoked?

A: Accountability should sit with the team that owns lifecycle governance for the application and the identity source of record. If access is not fully revoked, the failure usually spans IAM operations, application owners, and security governance. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared responsibility model.

Technical breakdown

GitLab access automation and entitlement drift

Access automation in GitLab usually means programmatic add, update, and remove actions tied to onboarding, role change, and offboarding events. The technical risk is not the automation itself, but the gap between identity state in the source system and privilege state inside GitLab groups, projects, and feature flag lists. When those states diverge, users retain access longer than intended, or permissions are updated in one place but not another. That is entitlement drift, and it is a governance problem as much as an operational one.

Practical implication: map every automated access action to a single source of truth and verify that removal is complete across all GitLab scopes.

GitLab personal access tokens and machine-readable access

GitLab personal access tokens are effectively credentials that can be used like NHI secrets when automation or integrations depend on them. Even though this article frames them as a setup step, the real governance issue is token scope, expiry, and revocation. A token with read_user and read_api scopes still creates lasting access if its lifecycle is not managed with the same rigor as any other secret. In identity terms, the token is the control plane for access, not just a convenience artifact.

Practical implication: treat GitLab tokens as governed secrets with expiry, scope review, and documented revocation ownership.

Usage visibility as a license and access control signal

License usage data can help identify inactive users, but it is also a useful proxy for whether access is still justified. Low activity does not always mean no risk, because dormant accounts can still hold privileged access, project membership, or feature flag rights. The technical value lies in correlating activity, entitlement, and role. Without that correlation, teams end up optimizing license cost while leaving unused but still valid access in place.

Practical implication: combine usage telemetry with access review evidence before reclaiming licenses or retaining permissions.

Threat narrative

Attacker objective: The objective is to preserve valid access long enough to reach code, project, or administrative resources after the rightful need for that access has ended.

1. Entry occurs when a user, integration, or token is granted GitLab access and that access is then left active beyond its intended lifecycle.
2. Escalation occurs when group, project, admin, or feature flag permissions are not fully removed during offboarding or role change, leaving standing access behind.
3. Impact occurs when stale permissions or tokens are used to retain visibility, modify resources, or access sensitive project data after the business relationship has changed.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GitLab lifecycle automation is only as strong as the identity state it can actually prove. Automating add, update, and remove actions reduces manual effort, but it does not solve the underlying governance problem if access lives in multiple scopes and systems. The control issue is not whether a task can be triggered automatically, but whether identity and entitlement state stay synchronised across the whole lifecycle. Practitioners should treat automation as an execution layer, not as evidence of governance.

Offboarding failure is the real risk surface in this pattern. This article makes clear that access removal is a multi-step event, not a single click, because GitLab permissions can exist across users, groups, projects, admin roles, and feature flag lists. The specific failure mode is incomplete revocation, where the account is removed in one place while effective access survives elsewhere. IAM teams should read that as a governance boundary problem, not a workflow convenience issue.

GitLab access workflows expose entitlement drift between business need and technical permission state. When a user becomes inactive, changes role, or leaves the organisation, the access model should collapse quickly to the minimum required state. If it does not, the programme is no longer managing access by lifecycle, it is preserving historic permission patterns. That distinction matters for auditability, least privilege, and trust in every downstream access decision.

Standing access in development platforms is a broader identity problem, not just an admin problem. GitLab is a useful example because code platforms tend to accumulate permissions, tokens, and feature access faster than teams remove them. The broader lesson is that developer tooling often becomes the shadow system of identity governance, especially when access reviews focus on people but miss project-scoped entitlements and secrets-like tokens. Practitioners should widen recertification beyond named users to every access-bearing object.

Lifecycle governance must be measured by revocation completeness, not by workflow coverage. A process can look mature because onboarding and user updates are automated, yet still fail if offboarding leaves residual project or admin access behind. That is why lifecycle governance needs verification points, not just orchestration points. Security teams should judge the programme by how reliably it eliminates access after need ends.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• That pattern is why lifecycle discipline has to extend beyond people and into every access-bearing object, as outlined in the NHI Lifecycle Management Guide.

What this signals

GitLab lifecycle automation will keep converging with broader identity governance. As platforms absorb more onboarding, offboarding, and access update workflows, practitioners will need stronger checks on revocation completeness and entitlement drift. The operational question is no longer whether access can be changed quickly, but whether the change is complete across every scope that matters.

Entitlement visibility is becoming the control that separates tidy dashboards from real governance. Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs, and the same visibility problem shows up whenever teams cannot prove which GitLab permissions still exist. If you cannot see effective access, you cannot certify it with confidence.

Access review programmes need to widen from users to access objects. Tokens, project memberships, and admin elevations behave like durable identity assets even when the user looks inactive. That is why teams that manage GitLab at scale should align lifecycle controls with the NIST Cybersecurity Framework 2.0 and treat revocation proof as a measurable outcome.

For practitioners

• Map GitLab access to all entitlement scopes Inventory user, group, project, admin, and feature flag permissions so that every lifecycle event is evaluated across the full access surface, not just the account record.
• Verify offboarding removes residual access everywhere Require a post-offboarding check that confirms no permissions remain in groups, projects, or feature flag lists after the user is deactivated or removed.
• Govern personal access tokens as secrets Track token owner, scope, and expiry, and assign a revocation owner so the token lifecycle is reviewed with the same discipline as any other sensitive credential.
• Use activity data to drive access review decisions Compare GitLab usage patterns with assigned permissions to identify dormant users who still hold access that no longer matches their current role or business need.
• Build recertification around effective access, not user records Make periodic reviews include project membership, admin elevation, and token-based access so the review checks what can actually be done in GitLab.

Key takeaways

• GitLab automation reduces manual effort, but it does not eliminate entitlement drift when permissions exist across multiple scopes.
• The main control weakness is incomplete offboarding, where deactivation does not guarantee revocation of project, group, admin, or token-based access.
• Practitioners should measure governance by revocation completeness and effective access, not by how many workflow steps are automated.

Key terms

• Entitlement Drift: Entitlement drift is the gap between the access a person or system should have and the access it still has in the application. In GitLab and similar platforms, it appears when group, project, admin, or token permissions are not removed in sync with lifecycle changes.
• Effective Access: Effective access is the real set of actions an identity can perform after all roles, memberships, tokens, and elevated permissions are considered together. It matters more than the account record because a deactivated user may still retain access through other active entitlements.
• Lifecycle Governance: Lifecycle governance is the discipline of granting, updating, reviewing, and removing access as business need changes. It applies across people, service accounts, and machine credentials, and it only works when revocation is as complete and auditable as provisioning.
• Personal Access Token: A personal access token is a credential that allows API or application access on behalf of a user. In practice, it behaves like a sensitive secret, so its scope, expiry, and revocation need formal governance rather than informal cleanup.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Automation How Zluri Helps You Get More Out Of GitLab (Self Managed). Read the original.