Stopping a malicious code change does not disable cloud keys an attacker has already stolen. Unit 42 describes a human-directed, AI-assisted intrusion that used more than 50 ATT&CK techniques in under ten hours. The sequence reached repositories, administrative secrets and cloud AI access; hard branch protection stopped an attempted Terraform backdoor. The publisher corrected its account on September 3 to describe an intrusion, rather than a ransomware attack. [1]
For a small team running code repositories, build pipelines and cloud services, the immediate question is which identities can still act. A rejected change is useful evidence of a working control, but it is only one part of the response.
Follow the permission boundary
The workflow places a human operator above the agents. It should not be read as proof that an AI system independently chose a victim or that every subsequent attack will finish within the same time. Treat the reported speed as an incident observation.
| Evidence you find | Question that changes the response |
|---|---|
| A secret appeared in a repository | Is the credential still valid at its issuing service, and what could it access? |
| An unexpected build ran | Which identity triggered it, what secrets were available, and which artifacts or logs could expose them? |
| A suspicious infrastructure change was rejected | What other identities and access paths existed before that rejection? |
| Cloud or model usage changed unexpectedly | Which key, account and source initiated the activity, and can the owner explain it? |
Put the answers on one incident timeline. If different people own the repository, build system and cloud account, assign a response lead who can connect their evidence. Otherwise, one owner may close a ticket while another access path remains active.
Removing a secret from code is not revoking it
GitHub’s documentation explains that secret scanning covers Git history across branches and recommends immediately rotating an exposed credential. Editing the latest file does not perform that action at the service that accepts the credential. Feature availability depends on repository type and configuration. [2]
For a credential you control, identify its issuer, permissions and legitimate consumers. Coordinate revocation and replacement so the response does not silently break a critical service or leave the old value accepted. Record when the old credential stopped working, where the replacement was deployed and who checked the result.
Search findings are leads for that work. A clean current branch, a closed scanning alert or a deleted local file is not a substitute for checking the credential’s actual status. Preserve relevant evidence before cleanup changes obscure the sequence.
Check build authority as well as code review
In the reported incident, unauthorized workflows extracted cloud access keys; the attempted Terraform modification was blocked later by branch protection. [1] These are separate outcomes. Code review can prevent a particular repository change while an overprivileged build identity still exposes something valuable.
Review who can start sensitive workflows, approve their execution and access their outputs. Compare a suspicious run with the expected trigger, actor, environment and secret access. Where an incident is active, let the response team decide which builds to pause and which identities to contain together.
Do not weaken a branch rule to reproduce the attack in production. A controlled review of permissions and retained build evidence can answer the operational question without opening the same path again.
Do not turn ordinary development files into standalone alarms
Markdown notes and Python-generated files occur in normal engineering work. Their presence alone cannot establish who created them or whether an intrusion happened. Look for unauthorized execution, unexpected identities and access to resources outside the approved task.
Likewise, a document that calls itself a security audit does not establish permission to access your systems. Verify any claimed engagement against the actual contract and designated contacts. Keep the document as evidence without treating its instructions as an authorized recovery plan.
Close the incident across services
A useful handoff states which credentials were revoked, which workflows and cloud identities were reviewed, what unauthorized changes were removed and which logs remain under investigation. Include unresolved access paths explicitly. That is more actionable than declaring success because one control blocked one change.
For routine prevention, keep an owner and recovery procedure for each production credential. The same inventory that helps a team rotate keys safely also makes an urgent response less dependent on finding the one person who remembers how a deployment works.
References
- Unit 42. AI-assisted intrusion investigation and correction notice. Updated September 3–4, 2026.
- GitHub Docs. Secret scanning and exposed-credential remediation. Accessed September 7, 2026.
