NHIMG Forum - Recent Posts

RE: Silk Typhoon arrest and exposed credentials: what do teams need to watch?

Mr NHI — Tue, 14 Jul 2026 18:13:43 +0000

Exposed credentials are not just an entry problem, they are a force multiplier for espionage. The article shows a group that combines scanning, spraying, and credential hunting because each method increases the chance of finding a reusable access path. That is an identity problem as much as a vulnerability problem, because one leaked secret can bypass layers of perimeter thinking. Practitioners should treat exposed credentials as the start of a broader access graph, not a single incident.

A few things that frame the scale:

The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
Only 44% of developers are reported to follow security best practices for secrets management, which explains why exposed credentials remain a recurring identity exposure.

A question worth separating out:

Q: Who should be accountable when third-party access is abused?

A: Accountability should sit with the teams that own the access path, the detection logic, and the response workflow. Third-party access is not a special exception to identity governance; it is a high-risk access category that needs explicit ownership, monitoring, and containment rules. Without that clarity, the organisation can see the event but fail to respond decisively.

👉 Read our full editorial: Silk Typhoon arrest highlights the operational risk of exposed credentials

RE: xAI API key leaks: what does this mean for AI access governance?

Mr NHI — Tue, 14 Jul 2026 18:13:26 +0000

API keys for AI models are non-human identities, not just development artefacts. Once an AI key can authenticate a model service, it carries the same governance burden as any other machine credential. The article shows that model access can be exposed in ordinary code workflows and remain live after discovery, which makes secrets governance a first-class identity control rather than a hygiene task. Practitioners should classify model API keys as governed NHIs with explicit ownership and lifecycle.

A few things that frame the scale:

64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

A question worth separating out:

Q: Who is accountable when a vulnerable AI workflow exposes API keys?

A: Accountability sits with the teams that approved the trust boundary, not just the developers who used the framework. Security, platform, and application owners all have a role when model output can reach secrets or execution logic. The correct control view is shared governance over AI runtime paths, because the failure spans code, identity, and secrets management.

👉 Read our full editorial: Second xAI API key leak shows AI model access remains fragile

RE: Yocto Project 5.0.11: what the CVE-heavy release means for teams

Mr NHI — Tue, 14 Jul 2026 18:13:23 +0000

Patch cadence is a security control only when downstream teams can absorb it. Embedded Linux releases often look like routine maintenance, but the operational reality is that each CVE fix must pass through image rebuilds, regression checks, and device validation. That means remediation speed is bounded by governance maturity as much as by upstream patch availability. Practitioners should treat release intake as a control process, not a package management task.

A few things that frame the scale:

96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

A question worth separating out:

Q: Which controls matter most when embedded systems rely on automated release tooling?

A: Ownership, least privilege, and provenance verification matter most. Teams need to know which automated identities can fetch, build, sign, and publish artifacts, then prove that each release came from approved inputs. Without that chain of trust, patching does not guarantee release integrity.

👉 Read our full editorial: Yocto Project 5.0.11 shows patch cadence matters for embedded Linux

RE: Social Security data on cloud servers: what controls are missing?

Mr NHI — Tue, 14 Jul 2026 18:13:17 +0000

Identity data cloned into cloud environments creates a governance gap, not just a hosting change. Once a live dataset is copied for testing, the organisation must prove that access, logging and oversight still match the sensitivity of the source. Without that proof, the cloud environment becomes a parallel trust domain with weaker accountability. Practitioners should treat cloned identity repositories as governed assets, not disposable test material.

A few things that frame the scale:

72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.

A question worth separating out:

Q: Who is accountable when a high-risk identity dataset is moved into a cloud environment?

A: Accountability should sit with the data owner, the approving security function and the operational team that controls the environment. When the dataset is personal identity information, privacy and compliance obligations may also apply. Informal approvals are not enough for population-scale records.

👉 Read our full editorial: Social Security data on a cloud server exposes a governance gap

RE: SIM farms and mobile network disruption: what practitioners need to know

Mr NHI — Tue, 14 Jul 2026 18:13:11 +0000

SIM farm abuse is an identity lifecycle problem disguised as telecom fraud. The core governance failure is not just the presence of many SIM cards, but the absence of strong issuance, attribution, and offboarding controls across large pools of disposable identities. When device identities can be cycled faster than defenders can correlate them, the abuse surface behaves like unmanaged non-human identity sprawl. Practitioners should treat telecom abuse as lifecycle governance, not only network monitoring.

A few things that frame the scale:

The NYC SIM farm used 300 SIM boxes running about 100,000 SIM cards, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
Our research shows that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

A question worth separating out:

Q: Who is accountable when telecom saturation threatens emergency communications?

A: Accountability should sit with the owners of the infrastructure, the operators who can activate it, and the resilience function that tests the failure scenario. If third parties can provision the assets, contractual offboarding and emergency disablement rights also need clear responsibility.

👉 Read our full editorial: SIM farms expose a low-cost path to mobile network disruption

RE: Accidental spreadsheet leaks: what it means for identity governance

Mr NHI — Tue, 14 Jul 2026 18:13:09 +0000

Human identity leaks become security incidents when the data can be weaponised. This case is not about a conventional system intrusion, it is about the operational consequences of exposing identifiable people to hostile actors. The core failure was a data handling breakdown that turned a spreadsheet into a protection problem. For identity governance teams, that means the boundary between privacy, verification, and safeguarding is much narrower than most programmes assume.

A few things that frame the scale:

92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.

A question worth separating out:

Q: Who is accountable when a third-party identity causes data exposure?

A: Accountability sits with the organisation that trusted the identity without sufficient boundaries, not just with the vendor that used it. If a third-party account was over-scoped, persistently trusted, or insufficiently monitored, the governance failure is internal. Frameworks such as NIST CSF and zero trust both expect explicit control over external access.

👉 Read our full editorial: Accidental spreadsheet leaks can trigger large-scale identity risk

RE: Browser prompt injection attacks: are your LLM controls keeping up?

Mr NHI — Tue, 14 Jul 2026 18:13:06 +0000

Browser prompt injection is now an identity and access problem, not just an LLM safety problem. The attack path depends on existing browser permissions, extension trust, and the LLM’s delegated access to connected services. That places it squarely in the governance space that IAM and PAM teams already manage, even though the abuse surface looks like application behaviour. Practitioners should treat browser-mediated LLM access as part of the access control plane.

A few things that frame the scale:

80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

A question worth separating out:

Q: Who is accountable when a browser extension exposes LLM-connected data?

A: Accountability usually spans endpoint security, IAM, and the team operating the GenAI tool. Endpoint owners govern the extension, identity teams govern the connector and access scope, and platform owners govern logging and detection. Frameworks like the NIST Cybersecurity Framework and NIST AI RMF both point to shared ownership rather than a single control team.

👉 Read our full editorial: Browser prompt injection exposes a new LLM data theft path

RE: Claude AI in cyber attacks: what it means for ransomware and IAM

Mr NHI — Tue, 14 Jul 2026 18:12:59 +0000

AI-assisted extortion is becoming a workflow problem, not just a malware problem. The article shows attackers using Claude to rank vulnerabilities, extract credentials and draft ransom notes, which means the model is contributing to the operational chain rather than acting as a standalone weapon. That changes defensive planning from blocking one malicious prompt to disrupting a broader attack workflow. Practitioners should judge AI risk by the attack task it accelerates, not by the novelty of the model output.

A few things that frame the scale:

80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.

A question worth separating out:

Q: Who is accountable when AI systems are used in a cyber attack chain?

A: Accountability stays with the organisation operating the identity, secrets, and access paths that made the AI usable in the first place. If the model can act through delegated credentials, then governance must cover ownership, logging, approval boundaries, and offboarding for every connected identity and tool.

👉 Read our full editorial: Claude AI misuse shows how agentic attacks lower the bar for extortion

RE: Ribbon breach: what a year-long undetected intrusion means for telecoms

Mr NHI — Tue, 14 Jul 2026 18:12:59 +0000

Long-dwell access is the real control failure in telecom supplier breaches. When attackers remain inside for months, the problem is not just initial compromise but the absence of reliable detection around persistence, lateral movement, and support access. That changes the governance question from "was data taken" to "what access pathways stayed open long enough to matter". Practitioners should treat dwell time as a primary security metric, not a post-incident curiosity.

A question worth separating out:

Q: Who is accountable when a telecom supplier breach affects client data or systems?

A: Accountability is shared across the supplier, its customers, and any third parties that depended on the compromised trust path. The supplier owns the incident response and disclosure process, but customers must also assess their own exposure, access dependencies, and contractual notification obligations.

👉 Read our full editorial: Ribbon breach highlights telecom blind spots in long-dwell intrusion

RE: ForcedLeak and Agentforce: what this means for AI agent governance

Mr NHI — Tue, 14 Jul 2026 18:12:54 +0000

Indirect prompt injection is becoming an identity problem, not just a content safety problem. The attacker did not need a password, token, or session takeover to influence execution. They only needed a trusted ingestion path and an agent that accepted external text as actionable context. That means AI governance now has to treat prompt provenance and execution authority as part of the identity model, not as a separate model-safety issue.

A few things that frame the scale:

The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.

A question worth separating out:

Q: Who is accountable when an AI-assisted workflow leaks sensitive data?

A: Accountability sits with the organisation that allowed the workflow to operate outside governed controls. Security, IAM, and business owners all share responsibility for ensuring approval, logging, and lifecycle management exist before data moves through the path. If no one can block or revoke it, no one is governing it.

👉 Read our full editorial: ForcedLeak exposes how indirect prompt injection breaks agent trust