TL;DR: A critical LangChain deserialization flaw, CVE-2025-68664, can expose environment secrets and trigger unintended internal actions when attacker-controlled LLM output reaches vulnerable serialization paths, according to Orca Security. The issue shows that prompt injection can become a data theft and code execution problem when AI workflow outputs are treated as trusted objects.

NHIMG editorial — based on content published by Orca Security: LangChain deserialization flaw exposing secrets through prompt injection

By the numbers:

• CVE-2025-68664 carries a CVSS score of 9.3.

Questions worth separating out

Q: What breaks when AI output is allowed to drive object deserialization?

A: The trust boundary breaks.

Q: Why does prompt injection become more serious when serialization is involved?

A: Prompt injection is more serious when serialization is involved because the attack payload can stop being content and start becoming structure.

Q: How can security teams reduce secret exposure in LLM-driven workflows?

A: Security teams should remove secret access from any code path that accepts model output, enforce strict schema validation, and keep environment variables out of deserialization pathways.

Practitioner guidance

• Eliminate direct deserialization of model output Keep LLM responses as inert strings or strictly validated schemas.
• Separate secret-bearing runtime paths from AI outputs Review where environment variables, API keys, and tokens are accessible to workflows that consume model output.
• Patch vulnerable LangChain components immediately Upgrade LangChain to 1.2.5 and LangChain Core to 0.3.81, then verify that all applications and dependent services stop using the vulnerable serialization logic in internet-facing or data-critical deployments.

What's in the full article

Orca Security's full article covers the operational detail this post intentionally leaves for the source:

• Version-specific patch guidance for LangChain Core and LangChain deployments affected by CVE-2025-68664
• The exact deserialization path and reserved-key handling that enables the `lc` object confusion issue
• Examples of impacted applications that accept LLM output metadata and feed it into structured parsing logic
• Exposure prioritization based on runtime reachability, internet accessibility, and asset criticality

👉 Read Orca Security's analysis of the LangChain deserialization vulnerability →

LangChain CVE-2025-68664: what does it mean for AI workflows?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Agentic AI systems that rely on planning, tool use, and memory often degrade outside controlled environments, and the source article highlights why unreliable tools, weak long-term planning, and poor generalization can undermine real-world performance according to ZioSec citing Arxiv. The governance gap is structural: current controls assume deterministic behaviour, but agentic systems adapt mid-session and can drift beyond the conditions IAM teams planned for.

NHIMG editorial — based on content published by ZioSec: Enhancing Adaptability in Agentic AI: Challenges and Solutions

Questions worth separating out

Q: How should security teams govern agentic AI systems that can change tool use at runtime?

A: Security teams should govern agentic AI as a runtime identity problem, not just a model deployment problem.

Q: Why do agentic AI systems create more risk than ordinary automation?

A: Agentic systems create more risk because they can choose actions, tools, and timing during execution rather than following a fixed script.

Q: What breaks when AI memory is reused across multiple tasks?

A: When memory is reused across tasks, stale context, sensitive data, and prior assumptions can carry into new decisions.

Practitioner guidance

• Map every agent tool boundary Document which tools the agent can call, what data each tool can see, and which calls produce side effects.
• Bound memory by task and retention class Separate transient task context from reusable long-term memory, and define what can persist after task completion.
• Test for plan drift under changing inputs Use adversarial and scenario-based testing to see whether the agent changes tool choice or sequence when the environment shifts.

What's in the full article

ZioSec's full article covers the operational detail this post intentionally leaves for the source:

• The study’s four adaptation paradigms and how each one changes agent training.
• The distinction between tool-adaptation and agent-adaptation in practical deployments.
• The role of memory, retrieval, and reinforcement signals in improving agent performance.
• The article’s framing of cybersecurity risks when agents depend on external tools.

👉 Read ZioSec's analysis of adaptability challenges in agentic AI →

Agentic AI adaptability: what it means for IAM and security teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Eight in 10 employees are using unapproved AI tools, while 44% of U.S. workers use AI without authorization and 45% do so without telling their manager, according to JumpCloud. The governance gap is now about visibility, policy clarity, and data-flow control, not whether employees will experiment with AI.

NHIMG editorial — based on content published by JumpCloud: shadow AI governance and the gap between employee adoption and organisational oversight

By the numbers:

• 8 out of 10 employees are using unapproved AI tools.
• 44% of U.S. workers use AI tools without authorization.
• 45% of employees have used AI on the job without informing their manager.

Questions worth separating out

Q: How should security teams govern shadow AI in the enterprise?

A: Start by discovering where AI is already being used, including personal accounts, browser extensions, and informal team adoption.

Q: Why does shadow AI create more risk than ordinary shadow IT?

A: Shadow AI does more than introduce an unapproved application.

Q: What do organisations get wrong about AI governance?

A: Many teams assume that a policy document or approved-tool list is enough.

Practitioner guidance

• Discover unsanctioned AI usage across the estate Inventory personal accounts, browser extensions, and department-level experimentation so AI use is visible before it becomes embedded in daily work.
• Define data classes that cannot enter AI tools Publish explicit rules for confidential, regulated, and customer data, and make those rules readable at the point of use rather than buried in policy documents.
• Align approval workflows with how employees actually work Reduce the gap between sanctioned and unsanctioned tools by making approved options faster to access, easier to find, and simpler to use in real workflows.

What's in the full article

JumpCloud's full article covers the operational detail this post intentionally leaves for the source:

• How its shadow AI discovery approach identifies GenAI applications in use across the organisation
• How departmental usage patterns and pre-discovery actions support approval or restriction decisions
• How to centralise approved resources so employees can find sanctioned tools without bypassing governance
• How the vendor frames AI and SaaS management for organisations trying to reduce hidden usage

👉 Read JumpCloud's analysis of shadow AI governance and employee tool use →

Shadow AI governance: what IAM teams need to control now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: 2025 exposed three pressures on MSPs: supply-chain attacks on managed service providers, SaaS cost squeeze, and rising compliance demands, while 2026 is expected to bring agentic AI that changes how work gets done, according to JumpCloud. The real shift is that identity, governance, and delegated access now sit at the center of MSP resilience, not the edge.

NHIMG editorial — based on content published by JumpCloud: an MSP year-end reflection on 2025 security, compliance, and 2026 agentic AI trends

Questions worth separating out

Q: How should MSPs govern technician access across multiple client environments?

A: MSPs should separate identities by customer, task, and privilege tier so one account cannot reach every tenant.

Q: Why do MSPs need stronger identity controls when tool sprawl increases?

A: Every extra platform adds credentials, delegated roles, secrets, and logging obligations.

Q: What do security teams get wrong about agentic AI in managed services?

A: They often treat AI agents as workflow shortcuts rather than governed identities.

Practitioner guidance

• Segment technician access by customer and function Separate admin identities by client, support tier, and task type so one compromised credential cannot traverse the entire MSP estate.
• Reduce duplicate tools that duplicate privileged access paths Inventory every platform that creates its own login, API token, service account, or delegated admin role.
• Treat AI agents as governed non-human identities Before deploying agentic workflows, define which tools the agent may call, what actions it may trigger, and what evidence is retained for audit.

What's in the full article

JumpCloud's full post covers the operational detail this post intentionally leaves for the source:

• The specific MSP business pressures behind the 2025 recap, including the ticket volume, margin squeeze, and compliance shift described by the vendor.
• The discussion of Qilin's supply-chain campaign and why managed service credentials became a central target in downstream attacks.
• The vendor's own view of how SaaS pricing changes and tool consolidation affected MSP operating models in 2025.
• The 2026 agentic AI outlook and the vendor's framing of how MSPs might use automation to prevent tickets before they appear.

👉 Read JumpCloud's 2025 MSP security recap and 2026 outlook →

MSP identity security in 2025: what changed for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Business process automation is moving toward systems that can reason, adapt, and act with greater autonomy across disconnected applications as teams push for efficiency and visibility in 2026, according to Opnova. The real governance change is that application identity and access controls now have to assume more dynamic machine behaviour than traditional workflow automation was built for.

NHIMG editorial — based on content published by Opnova: Closing the Year With Gratitude and Looking Ahead

Questions worth separating out

Q: How should security teams govern agentic AI in disconnected applications?

A: Security teams should govern agentic AI by separating deterministic automation from systems that can choose actions at runtime, then tying entitlement review to the applications they actually touch.

Q: Why do disconnected applications create more risk when automation becomes agentic?

A: Disconnected applications create more risk because identity state is already fragmented, which makes provisioning and revocation harder to keep consistent.

Q: When does least privilege stop being reliable for autonomous systems?

A: Least privilege becomes less reliable when the system can adapt its execution path at runtime.

Practitioner guidance

• Inventory automation that is becoming agentic Separate rule-based workflows from systems that can choose actions at runtime, then document where human approval still exists and where it does not.
• Trace identity governance across disconnected applications Map where provisioning, recertification, and revocation depend on manual reconciliation between applications.
• Reassess least-privilege assumptions for adaptive systems Review whether current entitlements still make sense once a system can alter its own execution path, call additional tools, or chain tasks differently from the original design intent.

What's in the full article

Opnova's full blog covers the operational detail this post intentionally leaves for the source:

• The vendor’s specific view of how agentic AI is changing business process automation in 2026.
• Implementation framing for teams trying to automate disconnected applications faster.
• The company’s examples of cross-team collaboration and process transformation.
• The closing message about how Opnova positions its work with customer teams.

👉 Read Opnova's year-end blog on agentic AI and application governance →

Agentic AI and application governance: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Security teams are being pushed to inventory AI systems, but model lists and vendor registers reveal little about actual blast radius. Pillar Security argues that the risk sits in tools, system prompts, data access, and runtime behaviour, not in the BOM itself.

NHIMG editorial — based on content published by Pillar Security: Not All AI BOMs Are Created Equal

Questions worth separating out

Q: What breaks when AI teams rely on an AI BOM for security?

A: An AI BOM breaks down when teams treat it as a security control instead of a record of what exists.

Q: Why do agentic AI systems create a larger access risk than simple chatbots?

A: Agentic AI systems create a larger access risk because they can act through tools, not just generate text.

Q: How should security teams reduce AI application blast radius?

A: Security teams should reduce blast radius by separating low-risk conversation workflows from high-impact actions such as code execution, database writes, and external communication.

Practitioner guidance

• Inventory effective privilege, not just model names Document every tool, data source, system prompt, and external connection tied to each AI workload.
• Classify AI tools by blast radius Treat database write, code execution, email sending, and external API access as separate control tiers.
• Scan repositories for hidden AI control inputs Inspect prompts, configuration files, MCP settings, model artifacts, and dependency packages for malicious instructions, unsafe defaults, and serialization risks before approving deployment or upgrades.

What's in the full article

Pillar Security's full blog covers the operational detail this post intentionally leaves for the source:

• Examples of repository artefacts that reveal unsafe AI behaviour, including prompts, MCP configurations, and serialized model files
• The specific vulnerability patterns behind pickle-based model risk and configuration backdoors in coding assistants
• How runtime guardrails are applied to block destructive tool use, data exfiltration, and unsafe external communications
• The article's full argument for moving from inventory-led compliance to application-level AI security control

👉 Read Pillar Security's analysis of why AI BOMs miss the real risk in agentic AI applications →

AI BOMs and agentic risk: what IAM teams are missing?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Shadow IT is not the core problem in 1Password’s analysis of SaaS Manager; the real issue is unmanaged SaaS adoption leaving 34% of applications outside SSO and creating compliance, data governance, and lifecycle blind spots. The practical lesson is that business-led IT only works when discovery, access review, and offboarding are treated as governance controls, not optional cleanup.

NHIMG editorial — based on content published by 1Password: business-led IT and shadow SaaS governance

By the numbers:

• According to IT professionals, 34% of applications sit outside of the company’s SSO.

Questions worth separating out

Q: How should security teams govern shadow SaaS without blocking business productivity?

A: Security teams should treat shadow SaaS as a discovery and lifecycle problem, not a prohibition problem.

Q: Why do unmanaged SaaS apps create identity governance risk?

A: Unmanaged SaaS apps create risk because they sit outside central visibility, which means IT cannot consistently enforce SSO, review entitlements, or offboard access.

Q: What do IAM teams get wrong about business-led IT?

A: The common mistake is assuming business-led IT means losing control.

Practitioner guidance

• Create a continuous SaaS discovery process Inventory applications across business units, then reconcile them against SSO coverage, approved app lists, and procurement records.
• Assign lifecycle owners for every business-led app Require each application to have an accountable owner for onboarding, access review, renewal, and retirement.
• Use SSO coverage to prioritise remediation Target applications outside SSO first, because they are the likeliest to have fragmented authentication, inconsistent offboarding, and weak auditability.

What's in the full article

1Password's full article covers the operational detail this post intentionally leaves for the source:

• How 1Password SaaS Manager maps unmanaged apps into inventory and lifecycle workflows
• The specific app discovery and access review steps used to move a tool from shadow status into governed status
• Examples of how IT and business teams can standardise overlapping tools without stopping local productivity
• The product framing around SaaS Manager's visibility and automated discovery features

👉 Read 1Password's analysis of business-led IT and shadow SaaS governance →

Shadow SaaS governance: what should IAM teams do now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: California’s new AI laws take effect on January 1, 2026 and require companion and healthcare-focused systems to prevent self-harm content, avoid misleading medical authority claims, and intervene in live conversations, according to Lakera. The shift is from policy intent to runtime control, where governance must hold up under user interaction, not just documentation.

NHIMG editorial — based on content published by Lakera: California’s AI Laws Are About to Meet Reality

Questions worth separating out

Q: How should security teams govern user-facing AI that can change tone in live conversations?

A: They should treat the conversation itself as a governed control surface.

Q: Why do companion chatbots create compliance risk even when they do not claim to be human?

A: Because users respond to tone, persistence, and conversational memory, not just explicit identity claims.

Q: What do security teams get wrong about AI systems that sound like clinicians?

A: They focus on whether the system explicitly says it is a doctor, but that is only part of the problem.

Practitioner guidance

• Define runtime response controls Map every user-facing AI flow to a response policy that can block, rewrite, or route outputs before they are delivered.
• Log intervention events Record when a guardrail fires, what condition triggered it, and what response the system took.
• Review implied-authority language Audit prompts, templates, and user interface copy for phrases, titles, or visual cues that could make AI outputs feel clinician-guided or human-authored.

What's in the full article

Lakera's full article covers the operational detail this post intentionally leaves for the source:

• The specific behaviour rules Lakera describes for self-harm prevention and companion chatbot disclosure.
• The practical enforcement model for stopping misleading medical-style outputs at runtime.
• The legal and operational implications of California’s January 1, 2026 timeline for teams serving California users.
• The executive-order context and why it does not change the immediate state-law implementation window.

👉 Read Lakera’s analysis of California’s AI laws and runtime guardrails →

California AI laws and runtime guardrails for user-facing systems?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: State AI laws in Texas, Illinois, California, and Colorado begin taking effect in 2026 with documentation, transparency, bias, and risk-management duties that touch enterprise AI systems, including agents and MCP-connected workflows, according to AppSOC. The compliance question is no longer whether AI needs governance, but whether identity, access, and monitoring controls can prove it.

NHIMG editorial — based on content published by AppSOC: Multiple US AI Laws Effective in 2026

Questions worth separating out

Q: How should security teams prepare for state AI laws that require governance evidence?

A: Security teams should treat AI laws as an evidence problem, not just a policy problem.

Q: Why do MCP-connected AI workflows create new governance risk?

A: MCP-connected workflows expand the identity perimeter because a model can act through tools and data sources rather than only through a human user session.

Q: What do organisations get wrong about AI transparency obligations?

A: They often focus on model descriptions and miss the operational evidence underneath them.

Practitioner guidance

• Build a regulated AI asset inventory Catalogue models, agents, datasets, pipelines, MCP servers, inference endpoints, and the identities attached to each system so compliance teams can prove scope and ownership.
• Tie access evidence to AI governance records Link approval trails, service account ownership, tool permissions, and change records to the documentation required for disclosures, risk assessments, and audits.
• Review runtime permissions for connected AI systems Map which data sources, APIs, and execution paths each model or agent can reach, then verify that the access matches the declared risk category and use case.

What's in the full article

AppSOC's full article covers the operational detail this post intentionally leaves for the source:

• The specific bill-by-bill breakdown of Texas, Illinois, California, and Colorado requirements.
• The law-level distinctions between disclosure, risk-management, and transparency obligations.
• The implementation context for AI security posture management and runtime guardrails across AI systems.
• The article's own summary of how its platform maps to documentation and monitoring needs.

👉 Read AppSOC's analysis of 2026 U.S. state AI laws and compliance impact →

State AI laws in 2026: what changes for governance teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: OTP authentication remains more secure than static passwords, but it is increasingly bypassed through SIM swapping, SS7 interception, and real-time phishing, according to iProov. For high-assurance access, the control problem is no longer code generation; it is whether the verification method can survive modern interception and relay attacks.

NHIMG editorial — based on content published by iProov: OTP authentication security risks and biometric alternatives

Questions worth separating out

Q: When should organisations stop using OTP for authentication?

A: Organisations should stop using OTP when the access decision is high consequence, the user journey is likely to be targeted by phishing, or the recovery flow is especially sensitive.

Q: Why do SIM swap attacks matter for IAM teams?

A: SIM swap attacks matter because they defeat SMS-based possession checks without breaking the authentication algorithm.

Q: What do security teams get wrong about app-based TOTP?

A: Teams often assume app-based TOTP is inherently phishing resistant because it is not sent over a mobile network.

Practitioner guidance

• Reclassify OTP by risk tier Use SMS or email OTP only for low-risk access paths where the business impact of account takeover is limited.
• Remove OTP from recovery paths Do not let an OTP channel become the way a user regains access after compromise.
• Assume the channel can be compromised Model SIM swap, mailbox takeover, and relay phishing as expected attack paths rather than edge cases.

What's in the full article

iProov's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of HOTP, TOTP, SMS OTP, email OTP, and hardware token differences for implementation teams
• Attack walkthroughs for SIM swap, SS7 interception, and real-time adversary-in-the-middle phishing against OTP
• Detailed comparison of OTP versus biometric face verification for onboarding, recovery, and high-risk re-authentication
• Accessibility and user experience considerations tied to OTP and biometric verification choices

👉 Read iProov's analysis of OTP security risks and biometric alternatives →

OTP authentication: are your controls still strong enough?

Explore further

View Full Forum →  |  NHI Foundation Course →