TL;DR: AI agents are turning single-purpose non-human identities into multi-identity access chains that expand permissions, blur ownership, and raise the risk of living-off-the-land abuse, according to Astrix Security's analysis. The governance problem is no longer just credential hygiene, but proving which actor owns which access path when AI behavior becomes nondeterministic.

NHIMG editorial — based on content published by Astrix Security: AI agent identity risk and the rise of multi-NHI access

By the numbers:

• 1:100., ption could drastically increase this ratio, potentially reaching 1:100.
• Organizations currently exhibit a 1:40 human-to-NHI ratio.

Questions worth separating out

Q: How should security teams govern AI agents that rely on multiple non-human identities?

A: Treat the agent and its linked identities as one access graph.

Q: Why do AI agents increase non-human identity risk in enterprises?

A: AI agents increase risk because they often need broader cross-system access than a single workload or script, and they can accumulate several identities to do that work.

Q: What breaks when AI-associated NHIs are treated like ordinary automation?

A: Visibility and accountability break first.

Practitioner guidance

• Inventory every identity attached to each AI agent Map each agent to its OAuth apps, API keys, service accounts, session tokens, and webhooks so the full access chain is visible in one record.
• Separate administrative access from routine agent access Classify any agent that can write, administer, or cross systems as high-risk and subject it to stronger approvals, logging, and review than ordinary automation.
• Tie agent creation to explicit ownership and offboarding Require a named owner, expected usage timeframe, and decommission trigger for every AI-related NHI so the identity can be revoked when the task ends.

What's in the full article

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

• Category-by-category breakdown of AI systems and the specific NHIs they use across chatbots, RAG, cloud models, and browser agents
• Operational examples of provisioning, visibility, and posture controls for AI-linked NHIs in enterprise environments
• The article's discussion of living-off-the-land attack paths and why they are difficult to distinguish from normal agent behaviour
• Practical recommendations for baselining, monitoring, and automated response around AI-associated identities

👉 Read Astrix Security's analysis of AI agent identity risk and NHI sprawl →

AI agent credentials and NHI sprawl: what IAM teams need now?

Explore further

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

TL;DR: AI agents now make decisions, execute tasks, and adapt in runtime, which means identity controls must track delegation, auditability, and scope as first-class requirements, according to Strata Identity. The old assumption that access can be reviewed after the fact breaks when agents act and re-act within a session, leaving accountability gaps that human-centric IAM cannot close.

NHIMG editorial — based on content published by Strata Identity: AI agent identity and accountability in the enterprise identity model

By the numbers:

• With 80x more agents than human users in coming years, identity for agents is not optional.
• 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.

Questions worth separating out

Q: How should security teams govern AI agents that act on behalf of users?

A: Security teams should govern AI agents as delegated identities, not as ordinary service accounts.

Q: Why do AI agents create accountability problems for IAM programmes?

A: AI agents create accountability problems because they can make runtime decisions, chain actions, and adapt scope without a human pause point.

Q: What breaks when organisations treat AI agents like normal service accounts?

A: What breaks is the governance model.

Practitioner guidance

• Classify agent identities by delegated authority Inventory every AI agent, copilot, and automated workflow by who or what it acts for, what tools it can call, and whether it can change scope mid-session.
• Require end-to-end delegation traceability Log originator, agent identity, downstream API calls, and scope changes in a single chain that survives incident review.
• Define JIT registration and expiry for agents Register agents only when the task or workflow begins, bind them to a named owner, and expire them when the task ends.

What's in the full article

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

• A practical breakdown of the Six A's and how each one maps to agent authentication, authorisation, and audit logging.
• Examples of agentic identity flows such as OAuth OBO, PKCE, SPIFFE/SVID, and DPoP in runtime workflows.
• The sandbox and hands-on lab material for testing delegated policies and traceability across agent actions.

👉 Read Strata Identity's analysis of AI agent identity and accountability →

AI agent identity and accountability: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: The repeat inclusion in Redpoint’s InfraRed 100 sits alongside the claim that hundreds of organisations use the platform to manage external identities across end users, partners, APIs, and AI agents, highlighting how external IAM is expanding beyond customer login flows, according to Descope. The real governance issue is that identity boundaries are now spanning humans, machines, and agentic workflows at the same time.

NHIMG editorial — based on content published by Descope: Descope named to Redpoint’s InfraRed 100

Questions worth separating out

Q: How should security teams govern external identities across customers, partners, APIs, and AI agents?

A: Security teams should classify external identities by actor type, then assign separate authentication, authorisation, and revocation rules for each class.

Q: Why do APIs and AI agents create more external IAM risk than human users?

A: APIs and AI agents often run continuously, use credentials programmatically, and operate at machine speed, which makes scope creep harder to notice.

Q: What breaks when external identity lifecycles are not defined clearly?

A: When external lifecycles are unclear, access can outlive the business relationship that justified it.

Practitioner guidance

• Inventory external identity classes Classify every external actor your programme touches, including customers, partners, APIs, service identities, and AI agents.
• Separate human and non-human policy paths Do not rely on one shared policy model for all external access.
• Build lifecycle offboarding into external access design Make revocation a first-class requirement for partner apps, APIs, and agent identities.

What's in the full analysis

Descope's full article covers the company-specific context and recognition details this post intentionally leaves aside:

• The InfraRed 100 recognition context and why Redpoint included the company again
• Descope's own explanation of its external IAM positioning across end users, partners, APIs, and AI agents
• The company examples it cites, including how customers use the platform in practice
• The broader business background around funding, growth, and market visibility

👉 Read Descope's InfraRed 100 recognition note and external IAM context →

External IAM for APIs and AI agents: what this recognition signals?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Professional knowledge workers get better AI results by building one deep context thread and reusing it across code, tests, docs, and communications, rather than restarting from scratch each time, according to WorkOS. The governance lesson is that output quality now depends on context stewardship, not just model access.

NHIMG editorial — based on content published by WorkOS: AI isn't magic. Context chaining is

Questions worth separating out

Q: How should security teams govern AI assistants that reuse context across tasks?

A: Security teams should treat reusable context as a governed access path, not a harmless productivity feature.

Q: Why do context-rich AI workflows create new access risks?

A: Context-rich workflows create risk because the model can accumulate and reuse sensitive facts across deliverables without a human re-authorising each reuse.

Q: What breaks when teams use separate AI prompts for each deliverable?

A: When teams split work into isolated prompts, they lose continuity and force the model to relearn the project from scratch.

Practitioner guidance

• Define context boundaries for AI assistants Map which repositories, chats, docs, and workspaces an AI assistant can read, reuse, and retain across tasks.
• Review high-value prompts as governance artefacts Treat the first prompt thread as a durable project record when it contains architecture, code, or policy decisions.
• Limit context reuse across sensitive workstreams Separate product, engineering, support, and customer data threads where the same assistant is used.

What's in the full article

WorkOS's full article covers the workflow detail this post intentionally leaves at the governance level:

• A step-by-step account of how one conversation thread was reused across code, testing, internal documentation, and external messaging.
• The specific prompt patterns the author used to preserve technical context while generating different deliverables.
• Operational examples of how the WorkOS MCP docs server was spun up and verified inside the same workflow.
• The practical workflow details behind keeping context alive across multiple AI tools and workspaces.

👉 Read WorkOS's article on context chaining in AI workflows →

Context chaining for AI tools: what changes for knowledge teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Non-human identity risk is now urgent for 93% of respondents in ConductorOne’s 2025 Future of Identity Security Report, while 42% say NHI security outranks human user security and 78% claim high or full visibility despite persistent privilege and rotation issues. The governance gap is no longer visibility alone, but control of access scope and lifecycle at machine scale.

NHIMG editorial — based on content published by ConductorOne: Managing Non-Human Identity Risk in 2025

By the numbers:

• A staggering 93% of respondents in the report said the risks associated with NHIs are urgent, with 24% calling them extremely urgent and in need of immediate action.
• 42% of respondents say NHI security is now a higher priority than securing human users.
• 78% of respondents said they have high or full visibility into NHIs across their environment, and 30% say they already have total visibility.

Questions worth separating out

Q: How should security teams govern non-human identities at scale?

A: Security teams should govern non-human identities by assigning ownership, limiting scope, and enforcing lifecycle controls for every service account, token, and API key.

Q: Why do NHIs create more governance risk than many human accounts?

A: NHIs create more governance risk because they are easier to over-provision, harder to review, and less likely to trigger lifecycle events that remove access.

Q: How do security teams know if NHI visibility is actually working?

A: Visibility is working only when discovery leads to ownership, review, and action.

Practitioner guidance

• Build an authoritative NHI inventory Map every service account, token, API key, certificate, and AI agent to an owner, purpose, and expiry so discovery turns into accountable governance.
• Tighten default privilege at creation time Start each machine identity with the minimum access needed for the workload, then expand entitlements only after documented justification and review.
• Operationalise credential rotation and revocation Treat rotation as a planned lifecycle control for embedded secrets, third-party integrations, and long-lived service accounts, not as an emergency-only task.

What's in the full article

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

• Survey framing and respondent mix behind the 2025 Future of Identity Security Report
• Breakdowns of where teams struggle most with over-provisioning, rotation, and third-party NHI risk
• The article's narrative examples for why agentic AI changes the machine identity picture
• ConductorOne's explanation of the controls it recommends for machine identity governance

👉 Read ConductorOne's analysis of managing non-human identity risk in 2025 →

NHI risk in 2025: what changes when agents join the mix?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Agent fabric is an identity control plane for AI agents that dynamically discovers them, maps scopes and risk, and ties runtime behavior back to verifiable identities across clouds and runtimes, according to Strata Identity. The core governance assumption breaks when agents are ephemeral, distributed, and capable of acting on behalf of users without a stable review window.

NHIMG editorial — based on content published by Strata Identity: agent fabric and AI agent identity governance

By the numbers:

• Enterprises will see 80x more agents than human users within two years.

Questions worth separating out

Q: How should security teams govern AI agents across multiple clouds and runtimes?

A: Security teams should govern AI agents through a central identity registry that binds each agent to scopes, purpose, owner, TTL, and revocation state, then enforce policy consistently across every runtime.

Q: What breaks when AI agents are deployed without a registry?

A: Without a registry, teams lose the ability to tie runtime behavior to a verifiable identity, which means scopes, audit trails, and revocation become fragmented or invisible.

Q: How do you know if AI agent access governance is actually working?

A: It is working when every agent has an owner, a verifiable identity binding, a limited scope, a clear TTL, and a revocation path that is enforced across environments.

Practitioner guidance

• Build an agent registry before scaling deployments Record each AI agent's identity binding, declared function, scopes, TTL, revocation state, and owner before allowing production access.
• Audit OAuth scopes against declared agent purpose Compare each agent's granted scopes with its intended function and business unit, then remove permissions that are broader than the runtime task requires.
• Federate policy across runtimes and IDPs Map how agent identity is asserted and verified across Entra, Okta, AWS, on-premises workloads, and CI/CD pipelines so policy, logging, and revocation remain consistent at every boundary.

What's in the full article

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

• A deeper explanation of the registry fields that matter for agent governance, including bindings, risk levels, and revocation data
• Examples of how the agent fabric fits alongside identity fabric and app fabric in a real architecture
• Discussion of private versus public registry patterns for regulated and distributed environments

👉 Read Strata Identity's analysis of agent fabric for AI agent identity governance →

Agent fabric and AI agent identity governance: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI adoption is pushing data security and governance closer together, and blind spots around sensitive data now carry identity and access consequences as well as data risk, according to Cyera, which says it raised $540 million in Series E funding, lifted total funding above $1.3 billion, and reached a $6 billion valuation in six months, while also reporting 353% year-over-year growth among F500 customers and operations in 10 countries.

NHIMG editorial — based on content published by Cyera: Cyera doubles customer base in six months, reaching a $6 billion valuation

By the numbers:

• Cyera says it raised $540 million in Series E funding, bringing total funding to over $1.3 billion and valuation to $6 billion.
• Cyera reports 353% year-over-year growth among F500 customers over the past 18 months.
• Cyera says it expanded operations to 10 countries and has nearly 800 employees worldwide.

Questions worth separating out

Q: How should security teams govern sensitive data used by AI systems?

A: Security teams should connect data classification, identity visibility, and entitlement review before data enters AI workflows.

Q: Why do AI projects increase the importance of NHI governance?

A: AI projects often rely on service accounts, API keys, and delegated application access to move data into tools and models.

Q: What breaks when data classification does not follow the workflow?

A: When classification stops at the repository, security teams lose track of how sensitive data is transformed, copied, and reused in SaaS or AI systems.

Practitioner guidance

• Map AI data paths to identity paths Inventory which human users, service accounts, API keys, and application tokens can reach sensitive datasets before they enter AI workflows.
• Prioritise identity-aware DLP policy Configure data loss prevention controls to evaluate requester context, application context, and data sensitivity together.
• Reconcile classification with access certification Use classification results to drive access reviews for workloads and humans, especially where AI systems consume or redistribute regulated information.

What's in the full analysis

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

• The funding and valuation context behind Cyera’s growth, including investor participation and timing
• Cyera’s product scope across discovery, classification, DLP, and AI-adjacent data protection
• The company’s own explanation of why enterprises need AI-native data security at scale
• The expansion and hiring details that explain how the platform is being positioned operationally

👉 Read Cyera's funding announcement and AI-native data security outlook →

AI-native data security funding: what it means for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: As AI adoption grows, data integrity becomes the critical control point and DSPM becomes the mechanism for classifying, discovering, and enforcing policy across cloud and on-prem data estates, according to Cyera. The governance break is that security teams can no longer rely on perimeter-era controls to keep pace with AI-generated and AI-consumed data.

NHIMG editorial — based on content published by Cyera: Are You Ready for Web 3.0? How DSPM helps you move at the speed of AI

By the numbers:

• This year the world is producing over 180 zettabytes of data, one byte for every star in the known universe.
• DSPM can classify even unstructured data with 95 percent precision or better, an essential capability when so much of the data used to train AI models consists of documents in various file formats.

Questions worth separating out

Q: How should security teams govern AI access to sensitive data?

A: Security teams should govern AI access by combining data discovery, semantic classification, and entitlement review.

Q: Why do traditional DLP tools struggle with AI data governance?

A: Traditional DLP tools struggle because they depend heavily on pattern matching and edge inspection.

Q: When should organisations prioritise DSPM over perimeter upgrades?

A: Organisations should prioritise DSPM when sensitive data is already distributed across cloud services, collaboration tools, and AI workflows.

Practitioner guidance

• Inventory sensitive data across all storage layers Catalogue data in SaaS, IaaS, PaaS, DBaaS, and on-prem systems so classification does not stop at the perimeter.
• Replace regex-only detection with semantic classification Use classification that recognises meaning and context in unstructured documents, logs, and mixed file types.
• Link DSPM findings to identity governance workflows Feed exposed-data findings into access review, stale-account cleanup, and privilege reduction so the control loop does not stop at discovery.

What's in the full article

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

• The article’s full explanation of how DSPM classifies data with large language models and natural language processing
• The specific control mapping Cyera uses to connect DSPM to Gartner TRiSM capabilities
• The source’s discussion of AI-native data protection use cases across cloud and on-prem environments
• The vendor’s own framing of how DSPM supports policy enforcement and monitoring at scale

👉 Read Cyera's analysis of DSPM and AI data integrity in the Web 3.0 era →

AI data integrity and DSPM: is your governance model keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: GDPR compliance is shifting from manual legal and IT workflows to identity-based controls for consent, access, erasure, logging, and lifecycle management, according to Okta. The core issue is not policy intent but operational scale: compliance fails when identity data, downstream app permissions, and audit evidence remain fragmented across systems.

NHIMG editorial — based on content published by Okta: Starting Your General Data Protection Regulation (GDPR) Journey with Okta

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

Questions worth separating out

Q: How should organisations operationalize GDPR access and erasure requests through identity systems?

A: Treat them as lifecycle workflows, not manual tickets.

Q: Why do manual GDPR processes break down as organisations scale?

A: Manual processes break down because the number of requests, apps, and data stores grows faster than the team’s ability to reconcile them.

Q: How do you know if consent management is actually working?

A: Consent management is working when the current purpose, scope, and timestamp are available in one authoritative record and downstream applications honor those attributes consistently.

Practitioner guidance

• Model GDPR rights as lifecycle workflows Map access, rectification, portability, and erasure to governed provisioning and deprovisioning steps, with ownership and approval paths defined before requests arrive.
• Store consent with the authoritative identity record Keep consent purpose, scope, and timestamp as identity attributes that downstream apps can read consistently.
• Centralize access evidence and login history Aggregate system logs, access reports, and suspicious activity signals into one evidentiary trail that supports breach notification and subject access requests.

What's in the full article

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

• The specific mapping between GDPR articles and Okta identity functions for consent, access, and erasure workflows.
• Examples of how Universal Directory is used to store consent and profile attributes for downstream enforcement.
• The logging and reporting approach used to support breach investigation and supervisory authority notification.
• The staged compliance model showing how organisations move from manual handling to platform-based governance.

👉 Read Okta's analysis of GDPR compliance through customer identity →

GDPR and customer identity: where compliance breaks down?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Phishing remains the most likely attack for 49% of respondents, while 64% cite fear of change as the main reason they keep passwords and non-phishing-resistant MFA, according to Axiad’s 2023 State of Authentication Survey. Removing the human step is only part of the answer; authentication strategy still has to align with real IAM, rollout, and lifecycle constraints.

NHIMG editorial — based on content published by Axiad: How to Adopt Phishing-Resistant MFA

By the numbers:

• 49% of respondents said phishing is the most likely attack to happen.
• 64% of respondents said fear of change is the top reason for holding onto passwords and non-phishing-resistant MFA.
• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

Q: How should security teams roll out phishing-resistant MFA without disrupting users?

A: Start with high-risk user groups, define assurance levels by role, and support the rollout with clear onboarding and recovery processes.

Q: Why do passwords and conventional MFA still create phishing risk?

A: Passwords can be stolen, and many MFA methods still rely on users approving prompts or entering codes that can be captured in real time.

Q: What do organisations get wrong when they treat phishing resistance as a technology project?

A: They focus on the authentication method and ignore the rollout model, support process, and fallback paths.

Practitioner guidance

• Prioritise high-risk user groups first Start with administrators, finance users, executives, and anyone who can approve money movement or sensitive access.
• Map assurance levels to user categories Define which employee groups need certificate-based authentication, which can use passkeys, and where exceptions are allowed.
• Plan for existing IAM interoperability Document where the new authentication layer will overlay current directories, SSO flows, and legacy applications.

What's in the full article

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

• Practical comparison of certificate-based authentication and FIDO passkeys for real-world rollout decisions
• Guidance on mapping authentication levels to user categories without forcing a rip-and-replace IAM project
• Implementation considerations for organisations that already have PKI and want to extend it for stronger authentication
• Employee preparation and onboarding steps that reduce support friction during phishing-resistant MFA adoption

👉 Read Axiad's guide to adopting phishing-resistant MFA →

Phishing-resistant MFA and the governance gap teams still face?

Explore further

View Full Forum →  |  NHI Foundation Course →