Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

AI agents and NHIs are colliding with trust assumptions


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15509
Topic starter  

TL;DR: Three converging risks are highlighted in the August 11 Cyber Watch: hotel Wi-Fi redirection, AI evaluation failures, and a self-spreading npm worm that steals credentials, tokens, and keys before propagating through developer tooling, according to Anomali. The pattern is clear: identity and trust controls are being bypassed faster than conventional review and response loops can react.

NHIMG editorial — based on content published by Anomali: Anomali Cyber Watch on AI abuse, developer worms, and Wi-Fi espionage

By the numbers:

Questions worth separating out

Q: How should security teams handle trusted access on guest or conference Wi-Fi?

A: They should treat guest and conference Wi-Fi as an untrusted access tier, not as a normal corporate path.

Q: Why do non-human identities increase propagation risk after a compromise?

A: Because tokens, keys, and service credentials can let an attacker operate as a valid identity with enough privilege to publish code, access cloud resources, or move laterally.

Q: What do organisations get wrong about AI-enabled application testing?

A: They often treat AI features as a small add-on to normal AppSec testing, when the real issue is that outputs can influence access, workflows, and data handling in ways that are hard to see from the first exploit.

Practitioner guidance

  • Restrict high-risk authentication flows on untrusted networks Block or step up sensitive sign-ins, device code authentication, and session re-use when users are on guest Wi-Fi or other unmanaged networks.
  • Scope and rotate developer and automation credentials aggressively Treat npm tokens, GitHub tokens, cloud access tokens, and SSH keys as short-lived identities with explicit publish rights, revocation tracking, and owner accountability.
  • Segment AI evaluation environments from production systems Isolate model testing networks, package registries, and external browsing access so that misconfigurations cannot turn a test run into production exposure.

What's in the full analysis

Anomali’s full article covers the incident-level detail this post intentionally leaves for the source:

  • Story-by-story MITRE ATT&CK technique mapping for the hotel Wi-Fi campaign, AI testing incidents, and ChainDrop worm
  • Named indicators, malware family details, and infrastructure clues that help triage related activity
  • Analyst commentary on why each incident matters operationally for defenders tracking identity and supply chain abuse
  • The source article’s full attack-pattern breakdown across user execution, credential theft, and persistence

👉 Read Anomali’s Cyber Watch covering AI abuse, supply chain worms, and Wi-Fi espionage →

AI agents and NHIs are colliding with trust assumptions?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 15094
 

Trusted access paths are now the attack surface, not the control. The hotel Wi-Fi campaign, the AI testing incidents, and the npm worm all show attackers abusing paths that users and systems already trust. In practice, that means identity governance must extend beyond login events to include redirect infrastructure, delegated sessions, and automation credentials. The control question is no longer simply who authenticated, but what trust relationship was inherited at the moment access began.

A few things that frame the scale:

  • When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

A question worth separating out:

Q: Who is accountable when stolen developer credentials are reused to spread malware?

A: Accountability usually spans the platform owner, the identity owner, and the security team that failed to constrain the credential lifecycle. If publishing tokens, cloud access tokens, or CI credentials can be reused without fast revocation, the organisation has treated a non-human identity as a durable trust object instead of a controlled asset.

👉 Read our full editorial: AI agents and NHIs are colliding with trust assumptions across systems



   
ReplyQuote
Share: