TL;DR: Red Hat confirmed a breach of a consulting GitLab instance where attackers claimed nearly 28,000 private repositories and about 800 Customer Engagement Reports, showing how consulting artefacts can mix environment details with tokens, database URIs, and other reusable credentials, according to Aembit. Static secrets and shared deliverables remain the governance failure.
At a glance
What this is: This analysis of the Red Hat consulting GitLab breach shows how consulting repositories and Customer Engagement Reports can become credential-rich attack paths when static secrets and environment details are stored together.
Why it matters: It matters because IAM, PAM, and NHI programmes must treat third-party deliverables as part of the credential estate, not as harmless documentation.
By the numbers:
- The attackers claim to have taken roughly 800 Customer Engagement Reports.
Context
Consulting repositories are not neutral storage. In practice, they often hold reference material, deployment scripts, tokens, and environment details in the same place, which turns a collaboration workspace into a credential and topology archive for attackers to mine.
The Red Hat case matters to identity governance because third-party deliverables can carry non-human identity artefacts beyond their intended scope. When static secrets and connection details sit alongside project files, the boundary between documentation and access control collapses.
This is a NHI and lifecycle problem as much as a supply-chain problem. Consulting work often outlives the engagement that created it, so offboarding, revocation, and secret hygiene have to cover the repository, the report, and the downstream environments they describe.
Key questions
Q: What breaks when consulting repositories contain live credentials?
A: When consulting repositories contain live credentials, they stop being documentation and become access infrastructure. That creates a hidden path from delivery artefacts into customer systems, because an exposed token or key can be reused without defeating authentication again. The practical failure is not just disclosure, but uncontrolled reuse across organisations and environments.
Q: Why do third-party consulting artefacts increase identity risk?
A: They extend trust beyond the vendor boundary while often carrying operational detail that was never meant for broad reuse. That combination creates a larger blast radius if the artefact is exposed, because the file may contain enough context for an attacker to move from reading the document to reaching the target environment.
Q: How do security teams know a consulting engagement is carrying too much access?
A: The clearest signal is when scripts, tokens, database strings, and environment diagrams sit together in the same workspace or report. At that point, the engagement has stopped being documentation only and has become a source of reusable access. Teams should treat that mix as a governance defect, not a convenience.
Q: What should organisations do when a repository used for delivery is exposed?
A: Assume every embedded credential may be compromised, rotate or revoke those credentials, and then inspect downstream systems for any reuse of the same access path. The immediate priority is containment of the credential, not just review of the repository. After that, remove live secrets from similar delivery workflows.
Technical breakdown
Why consulting deliverables become credential stores
Consulting artefacts often combine operational context with the credentials needed to execute a proof of concept or troubleshoot an environment. That combination is efficient for delivery, but it creates a high-value repository pattern: network diagrams, database URIs, tokens, and scripts converge in one place. Once the repository is exposed, the material is no longer just documentation. It becomes a map of the environment and a set of reusable access paths, which is why secret scanning and content segregation matter before sharing begins.
Practical implication: separate deliverables from live credentials and treat every consulting repository as a candidate secrets store.
How static tokens turn reports into lateral-movement paths
Static secrets are valuable because they remain valid after the original context has changed. A token embedded in a report or script can survive the engagement, the handoff, and the vendor relationship itself. That persistence is what makes over-shared consulting material dangerous: if the credential is still live, the document is no longer passive evidence, it is an access mechanism. In NHI terms, the problem is not the existence of machine identities but their long-lived, portable form factor and lack of lifecycle containment.
Practical implication: rotate or revoke any credential that appears in consulting artefacts as soon as it is identified.
Why agentic workloads raise the stakes
Agentic workflows amplify the risk because they inherit whatever access material is present in their environment. If a repository or report contains a reusable token, an agent can pull, reuse, and propagate that access across tools and sessions without recognising the governance boundary a human would assume. This is where the control assumption breaks: least privilege defined at provisioning time does not hold when credentials are copied into artefacts that multiple systems can consume.
Practical implication: govern agent access as a consumption problem and prevent live credentials from being available to tools, pipelines, or assistants.
Threat narrative
Attacker objective: The objective is to convert consulting documentation into practical access paths into downstream enterprise environments.
- Entry occurred through a breached consulting GitLab instance that stored private repositories and Customer Engagement Reports together.
- Credential harvesting followed because the reports could expose tokens, database URIs, and other reusable access material.
- Impact would come from using those artefacts to move into customer or partner environments that the reports described.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
- Red Hat Consulting GitLab breach 2025: Extortionists copied a Red Hat Consulting GitLab instance, exposing customer tokens, keys and database connection strings held in engagement reports.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Consulting repositories have become an identity boundary failure, not just a data-loss problem. The Red Hat case shows that third-party engagement material can carry both context and access, which means the repository itself becomes part of the credential estate. That breaks the old assumption that documentation lives outside identity governance. Practitioners need to govern consulting artefacts as controlled access surfaces, not passive project files.
Static secrets in deliverables create credential portability that outlives the engagement. A token or database URI copied into a CER does not respect the project boundary that created it. Once the document is shared, the credential can move independently of accountability, which is exactly why lifecycle governance has to include offboarding, revocation, and repository content controls. The practitioner lesson is to remove live credentials from any deliverable that crosses organisational lines.
Secret sprawl is the named failure mode exposed here. The useful concept is not simply “repository exposure” but secret sprawl across consulting output, scripts, and reports. That sprawl turns a support artefact into a reusable access path and erodes the difference between a vendor environment and a customer environment. The practical conclusion is that governance must track where credentials are copied, not just where they are generated.
Workload identity is the structural alternative to shared consulting secrets. The article’s central implication is that identity should be issued to the runtime that needs it, not embedded in a document that multiple parties can read. That is the point where NHI governance and supply-chain hygiene converge. Practitioners should treat any shared credential as a design failure rather than an operational convenience.
Agentic systems inherit the same weak assumptions and make them harder to defend. When tools, pipelines, or AI agents can consume whatever access material appears in a repository, the security model can no longer assume a human operator will notice or contain misuse. The implication is not merely more scanning, but a redesign of how credentials are issued, shared, and expired across human, NHI, and autonomous workflows.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl now sits at the centre of consulting risk. When delivery teams place live credentials beside environment details, the security model shifts from document control to credential lifecycle control. That is why consulting governance has to align with secret sprawl, not just repository permissions.
Private does not mean protected. The strongest lesson for practitioners is that access scope, not repository visibility, determines exposure. Internal repositories can still accumulate sensitive material, so the review process has to look for what the file contains, not whether the project was meant to stay private. According to the State of Secrets Sprawl 2026, internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%).
For practitioners
- Audit consulting repositories for embedded live secrets Scan CERs, scripts, configs, and proof-of-concept files for tokens, database URIs, and connection strings before and after every engagement handoff.
- Revoke credentials embedded in third-party deliverables Treat any token or key found in a consulting report as exposed until rotated, and verify downstream integrations no longer trust the old credential.
- Replace shared credentials with workload identity Use short-lived, identity-based access for consulting workflows so reports and repositories do not need reusable secrets to function.
- Separate documentation from access material Keep environment diagrams, findings, and scripts in distinct locations from any secret material that was needed during delivery, and remove live credentials before export.
- Extend offboarding to consulting artefacts When a contract ends or scope changes, revoke repository access, review deliverables for residual access paths, and validate that shared material no longer opens customer environments.
Key takeaways
- The breach shows how consulting repositories can become identity infrastructure when deliverables include tokens, connection strings, and environment details.
- The core weakness is secret sprawl across third-party artefacts, not simply the exposure of one GitLab instance.
- Teams reduce the risk by separating documentation from live credentials, rotating anything embedded in reports, and moving delivery workflows to short-lived workload identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CERs and repositories in this breach may expose tokens, keys, and connection strings. |
| NHI-07 — Long-Lived Secrets | The breach pattern depends on static credentials surviving beyond the engagement. | |
| NHI-03 — Vulnerable Third-Party NHI | Third-party consulting material created the exposure path into downstream environments. | |
| Recommendation — Scan consulting deliverables for embedded secrets and remove exposed material before sharing. Replace long-lived credentials in delivery workflows with short-lived access tied to runtime need. Review third-party delivery channels for credentials that can be reused outside the intended scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Rotating exposed tokens and keys is directly governed by authenticator lifecycle control. |
| Recommendation — Apply authenticator management controls to revoke and rotate any credential found in shared artefacts. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incident pattern centers on harvesting credentials and using them to move into target environments. |
| Recommendation — Map exposed consulting artefacts to credential access and lateral movement detection patterns. | ||
Key terms
- Consulting Artefact: A consulting artefact is any deliverable used to document, demonstrate, or support an engagement, including reports, scripts, diagrams, and configuration notes. In identity terms, these files can become part of the credential estate if they carry tokens, connection strings, or environment details that outlive the project.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org