AI agents and NHIs are colliding with trust assumptions across systems

At a glance

What this is: Anomali's Cyber Watch links hotel Wi-Fi compromise, AI testing incidents, and a self-spreading npm worm to a shared failure in trust assumptions across network, AI, and developer environments.

Why it matters: IAM, NHI, and AI governance teams need to treat trusted context as a control surface, because redirection, delegation, and credential theft can all outpace conventional review cycles.

Context

Trust breaks when systems assume the source of an action is as trustworthy as the action itself. In this article, that assumption fails across three different environments: guest Wi-Fi, AI evaluation systems, and software supply chains. The identity angle is real because the abuse paths all depend on stolen, delegated, or impersonated credentials rather than purely technical exploitation.

For IAM and NHI practitioners, the useful lens is governance of trust boundaries, not just access grants. When a network, model, or build pipeline can trigger credential capture or unauthorized actions before reviewers notice, the control problem moves from authentication at the edge to continuous assurance across runtime pathways.

Key questions

Q: What breaks when trusted networks are used for authentication on travel devices?

A: Trusted networks collapse the difference between infrastructure access and identity trust. If a captive portal, DNS redirect, or device code flow is allowed to act as an authentication broker, attackers can steer users into legitimate-looking sign-in paths and capture valid sessions before the user realises anything is wrong.

Q: Why do AI evaluation environments create security risk when they touch real systems?

A: They create risk because evaluation tools often inherit credentials, network paths, or permissions that were meant only for testing. Once an agent or model can contact live services, the boundary between experiment and operation disappears, and a misstep can become real access or data exposure.

Q: What do security teams get wrong about self-spreading supply chain worms?

A: They underestimate how quickly a worm can turn legitimate automation into propagation. When package hooks, tokens, and publishing rights sit in the same workflow, the malware does not need a separate compromise chain. It can steal identities and reuse them to spread through trusted developer channels.

Q: How should organisations govern stolen tokens, cookies, and keys after compromise?

A: Treat every harvested credential as a separate trust relationship, not a single incident artifact. Revoke from clean systems, rotate the affected identities in the correct order, and assume that browser sessions, GitHub tokens, cloud keys, and SSH credentials may all have been used by the same attacker.

Technical breakdown

How captive portals and device code phishing combine

Captive portal attacks are effective because the user has already chosen to trust the network before any malicious content appears. In the CaptiveCrunch campaign, DNS and HTTP manipulation on compromised hotel and conference Wi-Fi redirected victims to phishing pages or fake update prompts, while device code phishing abused a legitimate Microsoft Entra ID flow. That matters because the sign-in page itself can be genuine even when the session was initiated through attacker-controlled redirection. The network becomes the initial trust broker, and the identity system inherits that trust without a separate verification step.

Practical implication: restrict device code authentication where it is not operationally required and treat guest Wi-Fi as a separate trust zone.

Why AI testing environments can leak into real systems

AI evaluation environments fail when isolation is only assumed, not enforced. The article describes models reaching production systems, internet targets, or real users after misconfigurations, weak passwords, unauthenticated endpoints, or proxy flaws broke the boundary between test and live infrastructure. In governance terms, the model is not the only asset at risk. The environment around it, including credentials, network routes, and human-facing workflows, becomes part of the attack surface. That is why evaluation security must cover runtime permissions, outbound connectivity, and human review paths, not just model prompts or benchmark design.

Practical implication: separate evaluation credentials, routes, and approval paths from production systems before running any agent or model test.

How a self-spreading npm worm abuses NHI trust

A supply chain worm succeeds when package trust, token trust, and tool trust are all treated as static. ChainDrop used a preinstall hook in package.json, fetched execution through a legitimate runtime, stole npm, GitHub, cloud tokens, and SSH keys, then republished infected packages with stolen npm credentials. That is classic NHI abuse because the worm is not just malware. It is an identity-harvesting mechanism that weaponises developer credentials and persistence inside familiar tooling. The result is self-propagation through authorised automation channels rather than noisy external exploitation.

Practical implication: bind package publishing, CI access, and cloud credentials to short-lived, tightly scoped identities with separate revocation paths.

Threat narrative

Attacker objective: The attacker objective is to convert trusted infrastructure, agent workflows, or developer tooling into a credential-rich execution path that enables persistence, impersonation, and broader compromise.

1. Entry began with trust abuse rather than obvious intrusion: attackers manipulated hotel and conference Wi-Fi, used misconfigured AI evaluation environments, and planted a malicious npm preinstall hook inside normal developer workflows.
2. Credential harvest followed through phishing pages, token theft, browser credential capture, exposed credentials in test environments, and developer secrets stolen from package execution contexts.
3. Escalation and propagation occurred when stolen identities were reused to access production systems, republish infected packages, or impersonate legitimate sign-in flows, extending the attack beyond the original foothold.
4. Impact was unauthorized access, persistent footholds, and lateral spread across user accounts, AI testing systems, and software supply chains.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust assumptions are now a primary attack surface, not an implementation detail. This article shows three different systems failing in the same way: each trusted an upstream context that should have been continuously revalidated. For identity leaders, that means trust cannot be inferred from network location, model assignment, or package origin. Practitioners should reframe trust as something to be earned at each step of execution.

The named concept here is trust-broker collapse. When a Wi-Fi network, AI evaluation environment, or developer pipeline acts as the broker for trust and then becomes the compromise point, downstream controls inherit a false sense of legitimacy. That breaks the separation between authentication, authorisation, and runtime assurance. The practical conclusion is that brokers must be monitored as hostile until proven otherwise.

NHI governance is central because the most damaging paths are identity paths. The npm worm steals tokens, keys, and GitHub credentials; the Wi-Fi campaign abuses Entra ID sign-in flows; the AI incidents show how mis-scoped access and weak controls let models reach real systems. Those are not just malware stories. They are governance failures around who or what is allowed to act on behalf of the organisation.

Conventional review loops are too slow for these attack patterns. A worm can republish packages before humans notice, a phishing redirect can complete before a user challenges the network, and an AI evaluation can touch production before post-run review begins. That means control points have to move earlier in the lifecycle, with tighter issuance, stronger isolation, and more restrictive runtime authority.

Security programmes should stop treating AI, cloud, and software supply chain controls as separate lanes. The article shows that identities, tokens, and delegated authority move across all three. The practical conclusion is to govern them as one trust system, with shared inventory, revocation, and anomaly detection expectations.

What this signals

Trust-boundary collapse is becoming the common failure mode across identity-adjacent attacks. The reader should expect more incidents where networks, agent workflows, and developer automation are compromised through the assumptions that surround them rather than through a single obvious vulnerability. Security programmes need shared visibility into issuance, delegation, and revocation across those layers.

AI and NHI governance are converging on the same operational question: what is allowed to act with authority? That question now applies to browser sessions, package publishers, model evaluators, and support workflows alike. The programme implication is to define authority boundaries explicitly and then verify them continuously.

For practitioners

• Tighten trust on guest and captive networks Treat hotel, conference, and other guest Wi-Fi as untrusted by default. Block device code authentication on unmanaged or travel endpoints unless a business process explicitly requires it, and route travel access through controls that do not depend on captive portal trust.
• Separate AI evaluation access from production access Use isolated credentials, networks, and approval paths for model testing and agent evaluation. Do not let benchmark environments reach real systems, and require explicit human review for any workflow that can create accounts, contact people, or submit code.
• Harden package publishing and build identities Make npm publishing, CI runners, and cloud access depend on short-lived credentials with explicit revocation. Monitor for preinstall hooks, unexpected token use, and package republishing behaviour that indicates self-propagation through trusted tooling.
• Inventory every delegated credential path Map where GitHub tokens, cloud access tokens, SSH keys, browser cookies, and identity-provider sessions can be harvested or reused. Revoke and rotate from a clean machine when compromise is suspected, and separate human admin accounts from automation identities.

Key takeaways

• The core risk is not a single exploit family but the collapse of trust boundaries across network, AI, and software supply chain workflows.
• The article ties that collapse to credential theft, delegated access abuse, and self-propagating package compromise rather than to one isolated event.
• Practitioners should respond by tightening issuance, isolating testing and publishing identities, and reducing the number of places where trust is inherited implicitly.

Key terms

• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners turn delegated access and credential lifecycle risks into governed controls across their programmes.