TL;DR: Pathlock says modern ERP environments now require continuous, transaction-first assurance because AI agents, bots, and service accounts execute critical business actions at machine speed across SAP, Oracle, Workday, and 150+ applications. The governance shift is bigger than monitoring more logs, because identity, privilege, and transaction context now have to be evaluated together in real time.

NHIMG editorial — what this means for NHI practitioners

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

Questions worth separating out

Q: How should security teams govern AI agents and bots in ERP systems?

A: Treat AI agents and bots as governed non-human identities with explicit ownership, least privilege, and lifecycle controls.

Q: Why do static ERP access reviews miss so much risk?

A: Static reviews miss sequence-based risk because a permission that looks acceptable in isolation may become dangerous when combined with transaction order, business context, and automation.

Q: What breaks when transaction controls are only tested after the fact?

A: After-the-fact testing lets fraud, compliance violations, and privilege misuse execute before anyone can intervene.

Practitioner guidance

• Map transaction-critical identities Inventory the users, bots, service accounts, and AI agents that can create, approve, or release ERP transactions, then assign explicit owners for each identity and workflow.
• Replace sampling with continuous controls monitoring Instrument controls so they evaluate transactions in real time, then retain evidence for audit, investigation, and exception handling across SAP, Oracle, Workday, and related systems.
• Reduce toxic access combinations Use SoD analysis and role cleanup to remove combinations that let one identity both initiate and approve the same high-risk business process.

The control objective shifts from periodic approval to continuous containment?

👉 Read Pathlock's analysis of continuous ERP control governance with Pathlock Nexus →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: IAM Access Analyzer surfaces unused roles, keys, passwords, and permissions in AWS, but it does not remove them, leaving remediation to security teams and creating a gap between detection and actual least-privilege enforcement, according to Sonrai Security. The operational bottleneck is not visibility but safe, scalable action.

NHIMG editorial — based on content published by Sonrai Security: Why IAM Access Analyzer Tells You About Unused Permissions But Won't Remove Them

Questions worth separating out

Q: How should security teams reduce unused IAM permissions without breaking workloads?

A: Use a staged model: discover unused permissions, validate business dependency, block the highest-risk access centrally, and keep a fast restore path for exceptions.

Q: Why do unused permissions remain a risk even after teams find them?

A: Because a finding is not a fix.

Q: What do teams get wrong about access review findings in cloud IAM?

A: They often treat the dashboard as evidence of control.

Practitioner guidance

• Implement org-level blocking for privileged unused access Use native cloud policy controls to suppress unused privileged permissions centrally while leaving the identity intact and preserving downstream dependencies.
• Create a fast restore workflow for legitimate exceptions Route temporary access through a task-scoped approval process so quarterly jobs, recovery activities, and uncommon workflows can be re-enabled without redesigning the role.
• Separate discovery findings from remediation decisions Assign explicit owners to review each unused-access finding, validate business dependency, and document whether the permission should be blocked, retained, or time-bound.

For cloud and NHI teams, that means cleanup backlog, restore speed, and central policy enforcement should be tracked as first-class controls, not implementation details?

👉 Read Sonrai Security's analysis of why IAM Access Analyzer stops at unused access findings →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Astrix Security says shared OIDC issuers in GitHub Actions, GitLab CI, and Terraform Cloud can let attackers reclaim deleted namespaces and assume stale cloud roles, with 14% of discovered AWS namespaces and 24% of Azure namespaces already unregistered. The real problem is offboarding failure: identity trust outlives the repository name it depends on.

NHIMG editorial — based on content published by Astrix Security: Sub:jugation and phantom cloud identities in CI/CD OIDC trust

By the numbers:

• In AWS, 14% of discovered namespaces were not registered and available to be taken.
• In Azure, the percentage jumps to 24%.

Questions worth separating out

Q: What breaks when CI/CD OIDC trust still points to a deleted namespace?

A: The cloud role can remain assumable if the deleted namespace is later reclaimed and the subject claim still matches.

Q: Why do reusable repository namespaces create NHI risk in cloud IAM?

A: Reusable namespaces weaken the identity permanence that OIDC trust depends on.

Q: How do security teams know whether OIDC-based roles are actually safe?

A: They should verify that the upstream namespace is still active, still owned by the expected team, and still bound to the intended repository or workflow.

Practitioner guidance

• Review all OIDC trust policies for stale namespaces Inventory every cloud role that trusts token.actions.githubusercontent.com, gitlab.com, or app.terraform.io, then verify that the referenced namespace still exists and is still under your control.
• Offboard abandoned CI/CD-linked cloud roles Disable or remove any cloud role whose subject depends on a repository or namespace that no longer has an active owner.
• Search workflow code for exposed role identifiers Look for id-token: write, role-to-assume, client-id, workload_identity_provider, and similar fields in workflow files.

If a repository name can be reclaimed, the control boundary is no longer the token, it is the continuity of the namespace and the retirement of the cloud role behind it?

👉 Read Astrix Security's analysis of Sub:jugation in CI/CD OIDC trust →

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →

TL;DR: Linux environments have remained one of the largest holdouts for phishing-resistant authentication, leaving critical infrastructure users dependent on passwords until now, according to RSA Security. The governance shift is not just convenience, because Linux access often sits inside high-value operational paths where credential compromise can have outsized blast radius.

NHIMG editorial — what this means for NHI practitioners

By the numbers:

• RSA set a goal of deploying 100% passwordless authentication for its own global workforce using its own RSA ID Plus platform.

Questions worth separating out

Q: How should security teams implement passwordless authentication for Linux users?

A: Start with Linux populations that have the highest privilege or operational impact, then align enrollment, recovery, and fallback rules with the same policy used on other platforms.

Q: Why does Linux support matter in a passwordless IAM programme?

A: Linux matters because many enterprises run infrastructure, administrative tooling, and sensitive workloads on it, yet still leave those users on weaker authentication.

Q: What breaks when passwordless excludes Linux environments?

A: Authentication policy fragments, privileged access becomes harder to govern consistently, and audit evidence no longer reflects the real estate.

Practitioner guidance

• Map Linux identities into your passwordless rollout scope Inventory every Linux user group, host class, and administrative path that still depends on passwords, OTP, or shared credentials.
• Standardise phishing-resistant login across all operating systems Apply the same assurance policy to Linux that already governs Windows, macOS, iOS, and Android.
• Redesign break-glass access before enforcement begins Create a separate emergency path for Linux access that is time-bound, logged, and reviewed after use.

Teams should measure assurance by the hardest platform, not the easiest one?

👉 Read RSA Security's article on passwordless authentication for Linux →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Traditional identity governance models struggle when cloud ecosystems, AI-driven workflows, and non-human identities outpace periodic reviews, according to SafePaaS. The governance shift is toward continuous assurance, risk-aware access control, and audit-ready execution across human and machine identities.

NHIMG editorial — here’s why we think this discussion matters

Questions worth separating out

Q: How should security teams govern non-human identities alongside human access reviews?

A: Treat non-human identities as first-class governed assets, not exceptions to employee access processes.

Q: When does periodic identity governance become insufficient?

A: Periodic governance becomes insufficient when access changes faster than the review cycle and when decision-makers need current evidence to manage risk.

Q: What do teams get wrong about embedding access controls into business processes?

A: Teams often treat process embedding as a usability feature rather than a control design choice.

Practitioner guidance

• Move to continuous access assurance Replace quarterly-only certification with near real-time evidence collection for cloud, SaaS, and workflow identities so governance reflects current access state.
• Include non-human identities in governance scope Inventory service accounts, tokens, and automated workflow identities alongside employees, then assign owners and review cadences for each class.
• Embed controls into business workflows Add approval, evidence, and expiry logic directly into high-risk processes so access decisions occur where work is executed, not in a separate ticket queue.

With 70% of organisations granting AI systems more access than they would give a human employee doing the exact same job, per the 2026 Infrastructure Identity Survey, governance models must absorb machine-speed change rather than merely document it?

👉 Watch SafePaaS's webinar on modern identity governance and risk management →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI-driven attacks are compressing the time from vulnerability discovery to exploitation while AI agents expand privileged identity exposure, according to Delinea. Standing privilege, unmanaged secrets, and weak runtime authorisation now define the practical attack surface, making just-in-time access and tighter identity discipline urgent.

NHIMG editorial — here’s why we think this discussion matters

Questions worth separating out

Q: How should security teams reduce risk from standing privilege in AI and NHI environments?

A: Security teams should identify all identities with persistent access, then move the highest-risk ones to just-in-time, task-scoped privilege.

Q: Why do AI agents complicate privileged access management?

A: AI agents complicate privileged access management because they can authenticate, hold secrets, and act repeatedly without the interruptions that constrain human admins.

Q: What breaks when secrets and sessions are not governed together?

A: When secrets and sessions are governed separately, defenders can lose track of whether a credential is still usable after authentication.

Practitioner guidance

• Remove standing privilege from high-risk identities Inventory service accounts, API tokens, and AI agent credentials that retain persistent access after task completion.
• Bind secrets to runtime context Treat secrets as time-bound credentials that should be constrained by workload, tool, and session context rather than reused broadly across environments.
• Apply identity governance to AI agents Classify every AI agent that authenticates to enterprise systems as a governed identity with ownership, approval boundaries, and recertification triggers.

Practitioners should use the AI Agents: The New Attack Surface report to pressure-test where runtime governance is weaker than policy says?

👉 Watch Delinea's session on AI agent identity risk and standing privilege →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Microsoft Dynamics 365 Finance & Operations governance is moving from documented controls to continuous proof, as organisations face SoD conflicts, over-provisioned users, stale access, and licensing pressure across multi-entity environments, according to Delinea. The practical shift is toward telemetry-backed monitoring that can surface hidden risk before audit findings do.

NHIMG editorial — here’s why we think this discussion matters

Questions worth separating out

Q: How should teams reduce SoD risk in D365 F&O environments?

A: Start by defining the critical duty combinations that matter to finance and operations, then compare effective permissions against those combinations on a continuous basis.

Q: Why do stale privileged accounts create more risk than their role names suggest?

A: Because the risk is driven by what the account can still do, not by whether anyone remembers assigning it.

Q: How can organisations tell if D365 F&O access governance is actually working?

A: Look for evidence that controls change behaviour.

Practitioner guidance

• Establish continuous SoD monitoring Map critical D365 F&O duties, then monitor effective access against those combinations whenever roles, users, or entities change.
• Use telemetry to validate access decisions Review login activity, privilege use, and unusual cross-entity behaviour to confirm that access is being used as approved.
• Fold licence review into entitlement governance Compare assigned access to actual business need so that unnecessary privilege and licence overspend are resolved together.

The governance pattern is familiar across identity programmes: once business applications carry material risk, audit evidence has to come from operational telemetry, not policy language alone?

👉 Watch Delinea's webinar on D365 F&O access governance and audit readiness →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Anthropic's Claude Mythos autonomously found more than 10,000 high- and critical-severity vulnerabilities across 1,000 open-source projects, with a 72% exploit success rate, showing how AI accelerates entry but not attacker intent, according to Delinea. The practical shift is that identity control, not vulnerability discovery alone, becomes the limiting factor once compromise is possible.

NHIMG editorial — based on content published by Delinea: In the Mythos era, identity is the last line of defense

Questions worth separating out

Q: How should security teams govern AI agents that hold privileged access?

A: Treat them as high-risk non-human identities.

Q: Why do AI-assisted vulnerability discoveries increase identity risk?

A: Because faster discovery shortens the time between exposure and exploitation, but the breach still succeeds through credentials, privileges, and session misuse.

Q: What breaks when standing privilege exists for non-human identities?

A: A single compromised credential can be reused across systems, extended over time, and combined with lateral movement.

Practitioner guidance

• Implement continuous discovery for all privileged identities Build an inventory that includes human admins, service accounts, API keys, and AI agents.
• Broker and scope agent credentials Issue credentials at connection time, restrict them to task scope, and revoke them when the job completes.
• Move from door checks to runtime authorization Authorize each high-risk action against identity, resource, and live risk context rather than relying on login-time approval alone.

If a session can drift, branch, or escalate after authentication, security teams need policy enforcement that keeps pace with the action itself, not just the login event?

👉 Read Delinea's analysis of AI agents, Mythos, and identity security →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Pathlock’s June 17 webinar frames a familiar IGA problem set, orphaned accounts, privilege abuse, and broken workflows, through an AI-assisted review model that uses a local LLM and plain-English prompts to search identity data, surface SoD issues, and build provisioning workflows inside the environment. The practical question is whether conversational automation improves governance or simply accelerates weak processes.

NHIMG editorial — here’s why we think this discussion matters

By the numbers:

• You have 400 SAP accounts, three people to review them, and an audit in six weeks.

Questions worth separating out

Q: How should security teams use AI in identity governance without weakening controls?

A: Use AI as a triage and interface layer, not as a control replacement.

Q: Why do orphaned accounts create more risk in regulated environments?

A: Orphaned accounts often retain access after ownership has been lost, which makes review, attestation, and remediation unreliable.

Q: What breaks when provisioning workflows are generated from chat prompts?

A: What breaks first is usually policy precision.

Practitioner guidance

• Validate the control boundary for conversational IGA Confirm that searches, retrieval, and generated actions stay inside approved identity data domains, with logging enabled for prompts, outputs, and workflow changes.
• Review every AI-generated workflow before production use Apply normal change control to chat-created provisioning logic, including role mapping, SoD checks, exception paths, and approval escalation rules.
• Prioritise orphaned account remediation by actual activity Use activity and privilege context to separate dormant accounts from active but misowned accounts, then assign cleanup ownership before the next review cycle.

The operating model should be designed so that faster triage does not become weaker attestation, especially in regulated environments where access decisions must remain explainable?

👉 Register for Pathlock's webinar on orphaned accounts, privilege abuse, and broken workflows →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Cyera reports three LangChain and LangGraph vulnerabilities, including one critical flaw, that can expose filesystem files, environment secrets, and conversation history across widely deployed AI infrastructure with roughly 847 million combined PyPI downloads. The real governance issue is that AI frameworks behave like data pipelines, so existing IAM and data security controls must extend into the agent runtime, not stop at the app boundary.

NHIMG editorial — based on content published by Cyera: LangDrained, three paths to your data through LangChain, the world's most popular AI framework

By the numbers:

• The LangChain family has reached roughly 847 million total downloads across langchain, langchain-core, and langchain-community.
• The Trivy supply chain compromise spread across 5 ecosystems in March 2026.

Questions worth separating out

Q: How should security teams handle hidden AI framework dependencies in enterprise environments?

A: Treat AI frameworks as governed infrastructure, not incidental libraries.

Q: Why do AI frameworks create new NHI governance risks?

A: AI frameworks often sit between identities, tools, secrets, and persistent memory, so they can amplify a small coding flaw into broad data exposure.

Q: What breaks when prompt loading or deserialisation is not constrained?

A: Unconstrained prompt loading can turn a harmless configuration reference into local file disclosure, while permissive deserialisation can reinterpret attacker-controlled data as trusted framework objects.

Practitioner guidance

• Inventory AI framework dependencies Identify every service, pipeline, and internal tool that imports LangChain or LangGraph directly or transitively.
• Restrict prompt loading to trusted paths Block user-controlled file paths and enforce base-directory checks for any prompt or template loader.
• Harden secret handling in deserialisation flows Disable secret resolution for untrusted objects and audit every code path that serialises model output, tool responses, or metadata.

With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, the governance gap will widen unless teams can map AI middleware to data classes and responsible owners?

👉 Read Cyera's analysis of LangChain vulnerabilities and AI data exposure →

Explore further

View Full Forum →  |  NHI Foundation Course →