Why do malicious AI repositories create both human and NHI identity risk?

Because the same infected host often stores both user sessions and workload credentials. Browser cookies, API tokens, SSH keys, and cloud secrets can all be harvested from one workstation and reused to impersonate people, services, or automated processes. That turns a software supply chain issue into a multi-identity compromise event.

Why This Matters for Security Teams

Malicious repositories are not just a code integrity problem. They are a credential collection problem that collapses human identity and NHI risk into the same incident. A poisoned package, workflow, or plugin can pull browser sessions, cloud tokens, SSH keys, and CI/CD secrets from one infected endpoint, then reuse them across SaaS, cloud, and automation planes. That is why identity compromise often spreads faster than the malware itself.

The practical consequence is that traditional appsec reviews miss the blast radius. Security teams may be looking for vulnerable dependencies while the attacker is harvesting reusable identity material from developer workstations and build systems. NHIMG research on the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities, which is a reminder that secrets, not just binaries, are often the real payload.

In practice, many security teams encounter the full impact only after a developer login, API token, or service account has already been reused elsewhere, rather than through intentional supply chain detection.

How It Works in Practice

Malicious repositories create dual identity risk because modern endpoints are identity dense. A single workstation may hold a human’s SSO session in the browser, an SSH agent socket, cloud CLI credentials, GitHub tokens, and service account keys used by local tooling. Once the repository executes code, even indirectly through install hooks or dependency scripts, it can enumerate those stores and exfiltrate whatever it finds. The same event can therefore impersonate a person, a workload, or both.

This is where the NHI angle becomes critical. Human identity controls such as MFA do not protect reused API keys or long-lived service credentials once they are copied. NIST’s Cybersecurity Framework 2.0 still applies, but the operational response has to extend into secret discovery, token revocation, workload authentication, and session invalidation. NHIMG’s Top 10 NHI Issues highlights how often secrets remain valid long after exposure, which is why containment must focus on rotation and revocation, not just host cleanup.

• Scan developer laptops, build runners, and container images for secrets before and after package execution.
• Separate human sessions from workload credentials so a stolen browser profile does not expose service access.
• Use short-lived tokens and automated revocation for CI/CD, cloud, and API access.
• Correlate repository activity with identity telemetry to detect cross-account misuse.

Best practice is to treat infected repositories as both malware events and identity incidents, because the compromise path often pivots from code execution into credential replay, lateral movement, and privilege escalation. These controls tend to break down in flat developer environments where long-lived secrets are stored in terminals, dotfiles, and shared automation paths.

Common Variations and Edge Cases

Tighter secret controls often increase developer friction, requiring organisations to balance faster local workflows against reduced identity exposure. That tradeoff is most visible in environments that depend on self-hosted runners, legacy shell scripts, or third-party plugins that expect durable credentials.

There is no universal standard for exactly where human identity risk ends and NHI risk begins, because many enterprise tools blur the boundary. A compromised browser can expose an SSO session, which then unlocks vault access, which then yields service tokens used by automation. In that sequence, a human compromise becomes an NHI compromise, and the reverse is also true when a stolen workload token is used to impersonate a trusted process.

Current guidance suggests prioritising the assets that can be replayed at scale: session cookies, cloud access tokens, SSH keys, CI secrets, and secret-manager credentials. The 52 NHI Breaches Analysis shows how often exposure of these credentials leads to repeated incidents, not one-time cleanup. Organisations should also assume that package trust alone is not enough; trusted repositories can still deliver malicious install-time behaviour, especially in languages and ecosystems that execute code during dependency resolution.

Where teams support shared workstations, ephemeral containers, or copied dotfiles, identity leakage tends to persist because the same secrets are propagated into multiple execution environments.

Related resources from NHI Mgmt Group

• Why do browser-based attacks create extra risk for NHI and human identity programmes?
• Why do web server vulnerabilities create identity and access risk for NHI programmes?
• Why do non-human identities create more risk than many human accounts?
• Why do AI agents create new risk in non-human identity management?