First, revoke and rotate the exposed credential, then immediately enumerate every role, secret and automation path that identity could already reach. If the account has touched production services, assume the attacker may have established persistence through native AWS services and investigate those paths before restoring normal access.
Revoke the credential before you do anything else
The first response is containment: disable the exposed CI identity, revoke its tokens or keys, and rotate any secret material that could still authenticate as that identity. In CI systems, compromise often spreads through automation faster than through a human account, so the safest assumption is that the credential has already been copied and may be reused elsewhere.
Because CI identities often sit inside delivery pipelines, the immediate question is not just “can it still log in?” but “what systems can it still reach before the change propagates?” That is why revocation and rotation come before investigation of convenience issues such as pipeline failures or failed jobs.
Map the blast radius across roles, secrets and automation paths
Once the credential is no longer trusted, enumerate every role, secret, environment and automation path that identity could access. That includes cloud roles, deployment permissions, signing or publishing privileges, vault entries, build runners, and any delegated trust used by scripts, actions or orchestrators. CI/CD Pipeline Identity Security Guide is the most direct navigation point for the kinds of pipeline trust links that should be checked first.
This step matters because the exposed CI identity is usually a path to other identities, not just a single login. If the same credential can mint short-lived tokens, assume those downstream tokens, trust policies and publishing routes may also need review, even if the original secret has been changed.
For broader identity lifecycle context, NHI Lifecycle Management Guide helps teams think through discovery, rotation and offboarding as one operational chain rather than isolated tasks. The practical lesson is that rotation without inventory leaves hidden access paths untouched.
Assume persistence if production services were reached
If the CI identity touched production, treat the event as a possible foothold in native cloud services until proven otherwise. Attackers frequently use automation identities to create durable access through roles, service principals, access keys, scheduled jobs, webhook secrets or trust relationships that survive the original credential change. Ultimate Guide to NHIs, key challenges and risks is useful here because the main danger is overprivilege plus visibility gaps, not the single exposed secret alone.
That means investigators should look for persistence before normal access is restored: new trust relationships, unexpected role assumptions, altered deployment pipelines, changed runners, or secrets copied into places the CI account could reach. If those artefacts exist, restoring the credential without removing the persistence mechanism simply hands back the attacker’s entry point.
Risk and Threat Considerations
CI identities are high-value because they often combine broad reach, automation speed and privileged access to build, deploy and secret-management systems. If one is exposed, the main risk is not just account misuse, but chained compromise across production services, signing flows and downstream credentials that the pipeline can mint or retrieve.
Failure mechanism: The exposed identity is reused to assume roles, fetch secrets, trigger deployments or create durable trust objects before defenders complete revocation and inventory.
Impact: Attackers can persist inside delivery and cloud control planes, tamper with releases, expand access, exfiltrate secrets, or continue operating even after the original secret is rotated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Exposed CI credentials require revocation and rotation of authenticators. |
| AC-6 — Least Privilege | CI blast radius depends on whether the identity had excessive roles or permissions. | |
| AU-6 — Audit Review, Analysis, and Reporting | Investigating production touchpoints requires reviewing logs for misuse and persistence. | |
| Recommendation — Revoke the compromised CI authenticator and replace any dependent secrets or tokens. Review and reduce the CI identity’s permissions before restoring access. Correlate CI and cloud logs to find role use, secret access and persistence activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question is about disabling and rotating a compromised machine identity. |
| Recommendation — Disable the exposed CI account and verify every related access path is removed. | ||
| NIST Zero Trust (SP 800-207) | PA-4 — No direct control reference | Zero trust logic fits the need to re-verify every downstream access path after exposure. |
| Recommendation — Re-establish trust only after each resource access path is revalidated. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Exposed CI identities are commonly abused as valid accounts for lateral movement and persistence. |
| Recommendation — Hunt for misuse of the exposed identity as a valid account across cloud and build systems. | ||
Practitioner Guidance
What to prioritise: Start with containment, then move immediately to blast-radius analysis. If the CI identity can reach production or secret stores, prioritise those paths over lower-value environments because they determine whether the compromise is a nuisance or a systemic incident.
What to verify: Confirm that the old credential no longer authenticates, that any issued tokens are expired or revoked, and that no alternate path such as federated trust, cached credentials or runner persistence still grants access. The control is not trustworthy until the downstream paths are also closed.
Practitioner takeaway: Treat the exposed CI identity as an access graph problem, not a single-secret problem, and assume persistence until every role, secret and automation path it could reach has been reviewed and neutralised.
Related resources from NHI Mgmt Group
- How should teams respond when CI or developer secrets are exposed?
- How should security teams prevent exposed internet-facing systems from becoming the first step in an identity-based ransomware attack?
- What should security teams do first after a cloud identity breach reveals unknown tenants and abandoned accounts?
- What should security teams do first after finding credentials exposed in email or source code repositories?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org