Last week a worm checked whether Claude Code was running before deciding what credentials to steal. The malware had a better model of your developer environment than most security teams do.
That is not a supply chain story. That is an identity story.
Non-human identities (NHIs) are machine actors that authenticate and take actions in your environment without a human in the loop: CI tokens, package publisher accounts, OAuth grants, API keys, and agent sessions. They now outnumber human identities in most engineering organizations, and almost none of them are governed.
AppSec was built around human actors. Developers write code, users submit input, attackers probe endpoints. The threat model starts with a person making a decision. We wrote policies, built scanners, reviewed pull requests, and trained developers. All of it assumed that if you secured what humans do, you secured the system.
That assumption is now wrong in a specific and practical way.
This week, Mini Shai-Hulud spread across npm, PyPI, Packagist, RubyGems, and Go modules. The technique was the same in every ecosystem: compromise a package publisher account, push a malicious update, harvest credentials at install time. No human was in the loop when the GitHub token left the machine. The package ran, the credentials moved, the pipeline kept going. Developer security policy did not cover this because the developer was not the actor. The package was.
Cisco acquired Astrix the same week. Astrix’s entire product is built around one uncomfortable observation: organizations cannot see or govern the non-human identities (NHIs) they have accumulated. Service accounts, OAuth grants, API tokens, CI identities, SaaS app connections, package publish rights, agent sessions. Not users. Not services in the traditional sense. Machine actors that a developer created once, probably in a hurry, and then forgot about.
OSV-Scanner’s CI output injection bug is the same story in miniature. The scanner is not a person. Its output feeds the next machine in the pipeline. When that output is injectable, you have not been attacked by a clever human. You have been attacked by the assumption that text from a trusted tool is safe text.
I keep coming back to the same pattern: the interesting failure is no longer between a human attacker and a human-operated system. It is between an automated process and another automated process, with human-issued credentials as the prize.
When you audit “developer security,” the scope should now include every non-human actor that developer implicitly created. The npm token scoped to publish everything. The CI service account with write access to production. The GitHub App installed on a Saturday and never reviewed. The agent session that persists across your entire working day. None of these appear in your identity governance tool. All of them are in scope for the attacks running right now.
Start with the question your IAM system cannot answer: what can make a change in your environment without a human approving it? That list is your real attack surface.
The boundary moved. Most AppSec programs have not.
Reply if I missed something. I fix the database.