TL;DR: Delinea reports that 87% of organisations say their identity security posture is prepared for AI, yet 46% admit their AI identity governance is deficient and 53% regularly encounter unauthorized AI tools or agents accessing company systems. The gap is not visibility alone, but the mismatch between autonomous NHI behaviour and legacy IAM controls that still assume human-paced access review.

NHIMG editorial — based on content published by Delinea: The hidden risk of non-human identities in AI adoption

By the numbers:

• 87% of organizations say their identity security posture is prepared.
• 46% of those surveyed admitting that their AI identity governance is deficient.
• 53% of surveyed organizations regularly encounter unauthorized AI tools and agents accessing company systems.

Questions worth separating out

Q: How should security teams implement least privilege for AI agents and NHIs?

A: Start by treating AI agents as a separate identity class with explicit ownership, purpose, and lifecycle records.

Q: Why do NHIs complicate zero trust architecture in practice?

A: NHIs complicate zero trust architecture because they authenticate and act at machine speed, often without the human checkpoints that zero trust programs assume.

Q: What breaks when organisations cannot see their non-human identities?

A: When NHIs are invisible, least privilege, credential rotation, and access review all become incomplete.

Practitioner guidance

• Implement continuous discovery for machine identities Inventory service accounts, API keys, tokens, certificates, AI agents, and shadow AI tools across cloud and hybrid environments.
• Reduce standing privilege for autonomous identities Classify every persistent entitlement held by NHIs and AI agents, then replace it with just-in-time access where operationally possible.
• Enforce access certification for NHIs Run regular access reviews on machine identities with the same rigor used for human access.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the control model is already out of balance?

👉 Read Delinea's analysis of hidden NHI risk in AI adoption →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: The EU AI Act applies to organisations that place AI systems or general-purpose AI models on the EU market, put them into service, or use them in the EU, and it sets staggered obligations from February 2025 through August 2027, according to Delinea. Policy alone is not enough; identity visibility, access control, and auditability now determine whether AI can be governed in motion.

NHIMG editorial — based on content published by Delinea: EU and AI, what you need to know about AI regulations

By the numbers:

• 56% of organizations reported that shadow AI incidents are occurring on a monthly basis.
• The EU AI Act entered into force on August 1, 2024, with most of the broader regime applying from August 2, 2026.
• The Regulation sets thresholds up to €35 million or 7% of worldwide annual turnover for certain infringements.

Questions worth separating out

Q: How should security teams govern AI systems that can act on sensitive data?

A: Security teams should treat AI systems as non-human identities with scoped access, named ownership, and full logging.

Q: Why do AI systems complicate IAM and NHI governance?

A: AI systems complicate IAM and NHI governance because they blur the line between user, workload, and automated actor.

Q: What breaks when AI agents are not inventoried or classified?

A: When AI agents are not inventoried or classified, organisations lose the ability to assign risk, apply the right obligations, and prove control to auditors.

Practitioner guidance

• Inventory every AI touchpoint Map internal assistants, embedded SaaS features, developer tools, and third-party models to business owner, data scope, and regulatory role.
• Bind each AI workflow to a named identity Use scoped non-human identities, temporary tokens, and identity-context logging so every AI action can be traced back to an owner and purpose.
• Classify use cases before you classify tools Start with the business function, the sensitivity of the data, and the consequence of failure, then decide whether the AI activity falls into transparency, deployer, or high-risk obligations.

Teams should prepare for AI identities to be reviewed like privileged workloads, not like policy exceptions?

👉 Read Delinea's analysis of the EU AI Act and AI governance controls →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Only 17% of organisations govern AI identities the same way they govern human identities, leaving agents free to accumulate privileges, expand scope, and act at machine speed, according to Saviynt. That gap makes lifecycle governance, not just runtime policy, the central control problem for agentic AI security.

NHIMG editorial — based on content published by Saviynt: From Code to Decommissioning: How Saviynt and LangChain Are Securing the AI Agent Lifecycle

By the numbers:

• Only 17% govern their AI identities in the same fashion as their human counterparts.

Questions worth separating out

Q: How should security teams govern AI agents across their full lifecycle?

A: Treat AI agents as non-human identities with an owner, a defined purpose, least-privilege access, runtime policy checks, and a retirement process.

Q: When does runtime enforcement matter more than static permissions for AI agents?

A: Runtime enforcement matters whenever an agent can make contextual tool calls or change behavior after provisioning.

Q: What is the difference between AI agent governance and traditional IAM?

A: Traditional IAM usually focuses on humans and stable accounts with periodic review cycles.

Practitioner guidance

• Assign an owner to every AI agent Make ownership mandatory at creation time so every agent has a named business or technical accountable party, a review cadence, and a clear decommission path.
• Enforce least privilege at agent creation Require explicit scope boundaries, tool entitlements, and approval for any access beyond the initial task, using the same review discipline you would apply to sensitive service accounts.
• Add policy checks before every tool call Place a runtime decision point in the action path so policy can block drift, unexpected context, or stale authorization before the agent reaches an external system.

Security teams should prepare for agent governance to show up as an identity inventory problem as much as a runtime enforcement problem?

👉 Read Saviynt's analysis of AI agent governance from code to decommissioning →

Explore further

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

TL;DR: AI agent sprawl, including shadow agents in browsers, endpoints, and SaaS applications, leaves enterprises unable to inventory or govern all non-human identities, according to SailPoint. Visibility is now the prerequisite for NHI governance because you cannot control access paths you cannot map.

NHIMG editorial — based on content published by SailPoint: From blind spots to full-spectrum visibility with SailPoint

Questions worth separating out

Q: How should security teams govern AI agents that operate like non-human identities?

A: Security teams should govern AI agents as non-human identities with owners, lifecycles, privileges, and auditability.

Q: Why do AI agents create a governance gap for IAM teams?

A: AI agents move faster than traditional IAM processes because they can appear in many tools, inherit machine credentials, and change behaviour without a human login.

Q: What is the difference between visibility and governance for non-human identities?

A: Visibility tells you what identities exist and where they operate.

Practitioner guidance

• Build continuous discovery into NHI governance Inventory AI agents across browsers, endpoints, SaaS applications, and AI platforms on an ongoing basis.
• Link every agent to an accountable owner Require a human owner, lifecycle status, and business purpose for each agent before approval.
• Map privilege chains, not just identities Track which machine identities, tokens, and entitlements each agent can use, then identify where access is inherited across systems.

For planning context, the 2024 ESG Report: Managing Non-Human Identities shows how widely compromised NHI problems already reach in enterprises?

👉 Read SailPoint's analysis of AI agent visibility and NHI blind spots →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Anthropic’s decision to withhold Claude Mythos after it demonstrated autonomous exploit chaining, alongside the late-2025 AI-orchestrated espionage campaign and the Trivy supply-chain compromise, shows that agentic AI and compromised NHIs are now part of the same risk surface, according to Entro Security. The decisive control is no longer patch speed alone but identity visibility, blast-radius reduction, and zero-time remediation.

NHIMG editorial — based on content published by Entro Security: Anthropic’s Claude Mythos and the AI cybersecurity reckoning

By the numbers:

• 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.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: How should security teams govern AI agents that have access to production systems?

A: Treat each AI agent as a privileged non-human identity with an owner, a scope, and a revocation path.

Q: When does AI agent access become a higher risk than it reduces?

A: Risk rises when an agent has standing access, broad tool reach, or no clear accountability for its actions.

Q: What is the difference between least privilege and zero standing privilege for NHI governance?

A: Least privilege limits what an identity can do, while zero standing privilege removes persistent access altogether and grants it only when needed.

Practitioner guidance

• Inventory every AI agent and machine identity Build a complete register of agents, service accounts, API keys, tokens, and certificates with named ownership, business purpose, and environment scope.
• Convert standing access into task-scoped access Replace persistent permissions with short-lived credentials, explicit workflows, and least-privilege role assignments.
• Automate compromise response for machine identities Pre-stage token revocation, secret rotation, agent quarantine, and downstream access blocking so response can occur immediately when anomalous behaviour appears.

Teams should expect workload identity review, secrets lifecycle management, and AI approval workflows to converge into one operating model?

👉 Read Entro Security’s analysis of Claude Mythos, AI agents, and NHI risk →

Explore further

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

TL;DR: WebMCP lets websites hand structured tools to browser agents inside live sessions, which shifts trust from static SaaS permissions toward runtime agent activity, according to Valence Security. That makes identity, browser visibility, and delegated access governance central to AI agent security rather than optional controls.

NHIMG editorial — based on content published by Valence Security: WebMCP Security and browser session power for AI agents

Questions worth separating out

Q: How should security teams govern browser-based AI agents in SaaS environments?

A: Security teams should govern browser-based AI agents as runtime actors, not as ordinary users or static integrations.

Q: Why do AI agents complicate zero trust architecture in SaaS?

A: AI agents complicate Zero Trust Architecture because they can inherit trust from a live session and then act at machine speed across multiple SaaS resources.

Q: What is the difference between user session security and NHI governance for AI agents?

A: User session security focuses on protecting the authenticated browser or application session.

Practitioner guidance

• Map browser-mediated agent workflows Inventory where AI agents act inside live SaaS sessions, then document which identities, tokens, and integrations they inherit.
• Separate human and agent identities Create distinct identities for autonomous agents, with unique lifecycle ownership, access reviews, and revocation paths.
• Correlate browser, identity, and SaaS telemetry Feed browser events, SaaS audit logs, and identity-provider signals into the same detection pipeline so agent-driven actions can be distinguished from normal user behavior.

With 91.6% of secrets still valid five days after notification, per Ultimate Guide to NHIs, delayed remediation compounds the risk of agent misuse?

👉 Read Valence Security's analysis of WebMCP and browser-based AI agent risk →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Sonrai Security’s research shows that global S3 access in sandboxed Amazon Bedrock AgentCore code interpreters can be repurposed as a bidirectional command-and-control channel, even though DNS-based exfiltration was already mitigated. The finding matters because network isolation assumptions break when approved cloud services become communication paths.

NHIMG editorial — based on content published by Sonrai Security: Global S3: Another C2 Channel for AgentCore Code Interpreters

Questions worth separating out

Q: How should security teams govern S3 access for sandboxed AI code interpreters?

A: Security teams should treat S3 as part of the interpreter’s attack surface, not just as storage.

Q: What is the difference between sandbox mode and true network isolation for AI workloads?

A: Sandbox mode limits some external traffic, but true network isolation requires control over every allowed outbound path.

Q: When does cloud service access become a command-and-control risk?

A: Cloud service access becomes C2 risk when an attacker can use legitimate reads and writes to pass instructions, receive output, or maintain session state.

Practitioner guidance

• Scope interpreter S3 access to specific buckets Use bucket-level and object-level restrictions so the workload cannot read or write outside the minimum required S3 paths.
• Prefer VPC mode for interpreter workloads Place code interpreters in VPC mode when they need cloud service access, then control outbound traffic with gateway endpoints and explicit policy checks.
• Review pre-signed URL usage as NHI exposure Limit pre-signed URL lifetime, constrain object keys, and treat every URL as a temporary non-human credential that can be abused inside the sandbox.

With 67% of organisations still relying heavily on static credentials, according to the 2026 Infrastructure Identity Survey, teams should expect broad service access to remain the default unless they redesign it?

👉 Read Sonrai Security's analysis of global S3 access as an AgentCore C2 channel →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI agents run as cloud identities through service accounts, IAM roles, and API keys, and Sonrai Security says 92% of cloud identities are already overprivileged, making autonomous access a bigger blast-radius problem than a new identity type. Least privilege and JIT controls now define whether agent behaviour stays contained or becomes breach material.

NHIMG editorial — based on content published by Sonrai Security: Why AI Agents Need Least Privilege Too, and How to Enforce It Automatically

By the numbers:

• Sonrai computed 92% of cloud identities are overprivileged, and the proliferation of agents only further exacerbates that.
• Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, with 17% incident rates for least-privileged AI access versus 76% for over-privileged systems.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

Questions worth separating out

Q: How should security teams enforce least privilege for AI agent identities?

A: Start by treating every agent as an NHI with a dedicated identity, a tight permission boundary, and a named owner.

Q: Why do AI agents create more risk than other non-human identities?

A: AI agents create more risk because they act continuously, can make many decisions quickly, and often receive broader access than static automation scripts.

Q: What is the difference between JIT access and standing privilege for AI agents?

A: JIT access exists only for a specific task and is revoked when the task ends, while standing privilege stays available all the time.

Practitioner guidance

• Map every AI agent to a distinct cloud identity Inventory service accounts, IAM roles, and API keys used by agents, then tie each one to a business owner and workload.
• Enforce least privilege at the policy layer Remove unused permissions, define an Accepted State for each agent, and block privileges outside that boundary rather than only flagging them.
• Use JIT elevation for rare agent tasks Grant elevated permissions only for specific jobs and revoke them automatically when the task ends.

Practitioners should align agent access reviews with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10?

👉 Read Sonrai Security's analysis of least privilege for AI agent identities →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI agents inherit IAM roles when they go live, and reused templates often leave them over-privileged, with non-human identities now outnumbering human identities by more than 80 to 1 and over 90% of cloud identity permissions going unused, according to Sonrai Security. The practical issue is not visibility alone, but enforcing least privilege before agent deployment velocity turns drift into persistent blast-radius risk.

NHIMG editorial — based on content published by Sonrai Security: How AI Agents Accumulate Permissions Over Time and the Associated Security Risks

By the numbers:

• Non-human identities now outnumber human identities by more than 80 to 1 in enterprise environments.
• 90% of permissions assigned to cloud identities go, es go unused.
• 40% of enterprise applications will include integrated task-specific AI agents by the end of 2026.

Questions worth separating out

Q: How should teams govern AI agent permissions in cloud environments?

A: Start by treating each AI agent as a non-human identity with its own lifecycle, access review, and blast radius.

Q: When does AI agent over-privilege become a real security problem?

A: It becomes a real problem as soon as the agent can reach more systems, data, or actions than the workflow requires.

Q: What is the difference between JIT access and standing privilege for AI agents?

A: Standing privilege gives the agent persistent elevated access, while JIT access limits privilege to a specific task and then revokes it automatically.

Practitioner guidance

• Scope one IAM role per agent and workload Avoid shared roles across multiple agents.
• Replace standing privilege with JIT exceptions Keep baseline access minimal and use time-bound approvals for any elevated task.
• Enforce least privilege at the org level Use native cloud controls to block unused permissions centrally instead of relying on per-identity cleanup queues.

The governance question is shifting from whether agents are allowed to act to how far any one agent can reach before controls intervene?

👉 Read Sonrai Security's analysis of AI agent permission sprawl in cloud IAM →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Aqua argues that vulnerability management alone cannot keep up as attack timelines compress to minutes, so runtime security must detect, quantify, and contain risk inside live workloads using agentic workflows and MCP-based tooling. That shift matters because NHI and IAM controls now have to operate at execution time, not only at build or scan time.

NHIMG editorial — based on content published by Aqua Security: Autonomous Runtime Security: Turning Runtime Intelligence into Agentic Response

Questions worth separating out

Q: How should security teams govern AI and workload identities at runtime?

A: Security teams should govern runtime identities by combining least privilege, continuous telemetry, and approval-gated containment.

Q: When does runtime security matter more than vulnerability management?

A: Runtime security matters most when exploitation can happen faster than patching or remediation.

Q: What is the difference between preventive controls and runtime containment?

A: Preventive controls try to stop risky software or configuration from reaching production.

Practitioner guidance

• Map runtime controls to identity enforcement points Identify where service accounts, workload roles, and AI agent permissions can be observed and constrained during execution, not only at provisioning time.
• Define approval boundaries for agentic containment Document which runtime policies an automated system may propose, which actions require human approval, and which incidents can be pre-authorized under standing playbooks.
• Prioritize blast-radius reduction over alert volume Rank workloads and identities by the damage they can do if compromised, then tune containment policies to isolate the highest-risk paths first.

The practical shift is toward runtime visibility, containment, and revocation paths that can work at machine speed?

👉 Read Aqua Security's analysis of autonomous runtime security and agentic response →

Explore further

View Full Forum →  |  NHI Foundation Course →