Look for unused GitHub workflows, lingering test apps, persistent API tokens, and accounts or service principals that outlive the project that created them. If the event ends but the access remains, the programme has turned a temporary build workflow into a long-lived identity estate.
How to recognise access sprawl in a self-serve build model
access sprawl shows up when temporary delivery access starts behaving like production entitlements. The clearest sign is that the build artefacts, tokens, and principals outlive the work they were created for, so the programme keeps accumulating long-lived secrets and accounts that no one can confidently explain or own.
Watch for a widening gap between project activity and identity reality. If repositories, pipelines, or test environments still depend on credentials from finished work, the programme has shifted from enabling fast delivery to creating an unmanaged identity estate.
What the operational warning signs usually look like
The practical indicators are easy to spot once you look for residue rather than active usage. Unused GitHub workflows, lingering test apps, persistent API tokens, and service principals that no longer map to an active project are all signs that access was granted for speed but never closed down. In practice, the presence of secrets sprawl often travels with this pattern, because teams treat the token as part of the build, not as an identity-bearing asset with a lifecycle.
Another warning sign is ownership drift. If the original team has moved on, the toolchain has changed, or the project code has been archived but the access still works, the environment is telling you that cleanup is not part of the delivery path. That is how self-serve access turns from temporary enablement into a standing entitlement problem.
A further clue is inconsistency across environments. A test app may be dead in one workspace but still able to authenticate in another, or a workflow may no longer run but its token remains valid. Those mismatches show that inventory and revocation are not keeping pace with provisioning.
Why the sprawl becomes a security problem, not just an admin problem
Access sprawl increases the number of credentials, principals, and automation paths that can be abused if one project or developer account is compromised. It also expands the blast radius of simple mistakes, because stale access often has broader reach than the work it was meant to support. NHIMG’s Top 10 NHI Issues is useful here because it frames excessive permissions, stale accounts, and credential hygiene as lifecycle problems, not just access-control settings.
The risk is highest when temporary build identities can still reach production data, privileged APIs, or deployment systems after the project ends. At that point, the issue is not only forgotten cleanup, but dormant access that can be reactivated, copied, or discovered later. Even when no attacker is present, the organisation is carrying unnecessary trust edges that should have been removed.
For teams using GitHub Actions, cloud service principals, or API tokens at scale, the real issue is accumulation. Every forgotten principal adds one more place where rotation, revocation, logging, and ownership can fail, which makes the environment harder to reason about during incident response or audit.
Risk and Threat Considerations
Self-serve delivery models create risk when fast provisioning is easier than reliable offboarding. The longer temporary access survives after a project ends, the more likely it is to become hidden attack surface, especially if the credential still authenticates to build, deployment, or cloud administration systems.
Failure mechanism: A workflow, token, or service principal is created for a short-lived build task, then never disabled when the task finishes. Over time it becomes orphaned, forgotten, or reused, which leaves a valid access path in place long after the business need has gone.
Impact: An attacker, or simply the wrong internal user, can exploit stale access for unauthorized deployment, secret exposure, privilege escalation, or persistence. Even without active misuse, the organisation inherits a growing stock of unowned access that weakens governance and increases recovery effort.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale workflows and principals are classic offboarding failures. |
| NHI-02 — Secret Leakage | Persistent API tokens and workflows increase exposed secret surface. | |
| NHI-05 — Overprivileged NHI | Lingering build access often retains more privilege than needed. | |
| Recommendation — Retire build identities and tokens as soon as the work ends. Scan, rotate, and remove exposed build secrets quickly. Reduce lingering build principals to the minimum access required. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access sprawl is fundamentally a lifecycle and account governance problem. |
| IA-5 — Authenticator Management | Persistent tokens and keys require lifecycle control and revocation. | |
| Recommendation — Inventory, review, and disable accounts and service principals when no longer needed. Track, rotate, and revoke authenticators on a defined schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | Self-serve build programmes need disciplined account and token lifecycle control. |
| Recommendation — Automate review and removal of unused accounts, tokens, and workflows. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity inventory and ownership are central to spotting sprawl. |
| Recommendation — Maintain an accurate identity inventory with clear ownership and purpose. | ||
Practitioner Guidance
What to verify: Tie every self-serve workflow, token, and service principal to a named owner, an expiry or review date, and a clearly stated purpose. If any of those three is missing, treat the access as provisional rather than acceptable to leave in place.
Common mistake: Teams often measure how quickly access can be granted, but not how reliably it can be removed. That imbalance is what turns a productive build programme into access sprawl, because convenience becomes the only control that scales.
What good looks like: Temporary build access is discoverable, time-bounded, and routinely retired when the associated work stops. The healthy signal is not zero automation, but a system where leftover access is rare, explainable, and quickly revoked.
Practitioner takeaway: If you cannot answer who owns a principal, why it still exists, and when it should die, you do not have a self-serve build workflow, you have a long-lived identity estate.
Related resources from NHI Mgmt Group
- How should security teams implement self-service API portals without creating access sprawl?
- What are the signs that access request handling is creating operational sprawl?
- How should security teams use self-service access without creating provisioning sprawl?
- How should security teams run access reviews for non-human identities?