1Password’s CRN security 100 recognition and AI access scope

At a glance

What this is: 1Password’s CRN Security 100 recognition is a signal that access governance is moving beyond human identities to include machines and AI agents.

Why it matters: This matters because IAM programmes now have to govern human, NHI, and autonomous access together or risk leaving agentic and machine access outside their control model.

By the numbers:

• 100 list is now in its 11th year

👉 Read 1Password’s note on CRN Security 100 and AI access governance

Context

The key identity security question here is not whether a vendor earns a channel list spot, but what that recognition says about the market’s assumptions around access governance. As SaaS, automation, and AI-driven tools expand, access is no longer limited to employees, and that creates a governance gap across human, non-human, and autonomous identities.

For IAM teams, the practical shift is that the control plane must cover more than user sign-in and password management. Machine access, API use, and AI agent behaviour are now part of the same policy problem, and the organisation that treats them as separate programmes will miss the full blast radius of access risk.

Key questions

Q: How should security teams govern access across human, machine, and AI agent identities?

A: Treat access governance as actor-aware, not user-only. Define separate policies for human users, service identities, and AI agents, then apply consistent controls for entitlement scope, device trust, and revocation. The objective is one governance model with different rules by actor type, not three disconnected programmes.

Q: Why do AI agents complicate traditional IAM controls?

A: AI agents can initiate actions, select tools, and continue operating without a human approval loop, so static IAM assumptions break down. Traditional controls focus on who logged in, while agentic access requires knowing what the actor can do at runtime and whether that scope is still appropriate.

Q: What breaks when machine identities are governed separately from human IAM?

A: Separate governance creates blind spots in entitlement review, revocation, and monitoring. A machine identity can retain broad access long after the business need changes, and teams may never see it inside the human access review cycle. That leaves runtime access outside normal oversight.

Q: Should organisations treat AI agent access as a privileged access problem?

A: Yes, when agents can reach sensitive SaaS apps, APIs, or internal tools. AI agent access should be governed with the same care as privileged access because the risk is not only authentication, but what the agent can execute after authentication. That means tighter scope, clearer ownership, and stronger revocation paths.

Technical breakdown

Why access governance now spans human, machine, and AI agent identities

Identity security was built around a human user model: a person authenticates, receives access, and uses it within a predictable work pattern. That assumption weakens when machines and AI agents can initiate actions, call tools, or consume SaaS access without a human sitting in the loop. The result is not just more identities, but different identity behaviour, where entitlement, device trust, and runtime action all need to be evaluated together. Traditional IAM boundaries break when the subject of access is not a person but a workload or agent.

Practical implication: teams need one governance model that classifies access by actor type, not separate control islands for people and non-people.

What a trust layer means for NHI and agentic AI access

A trust layer in this context is the policy and enforcement point that decides whether an identity can reach a SaaS app, tool, or data source under current conditions. For non-human identities, the core challenge is that trust cannot rely on user prompts or interactive verification alone. It must incorporate credential status, device context, entitlement scope, and the identity’s role in the workflow. If those signals are not evaluated together, AI agents and machine identities can inherit broad access that was never intended for autonomous execution.

Practical implication: define access decisions at runtime for non-human actors, with context-aware controls tied to workload and agent identity.

Why partner-led deployment changes identity security governance

Channel-led delivery matters because identity security is now being operationalised through implementation partners, not only direct product teams. That shifts the governance problem from tooling selection to control consistency across customers, environments, and service models. When partners help deploy identity security for SaaS, automation, and AI agents, the real question is whether the operating model can enforce the same policy intent across all three. If not, organisations end up with strong messaging and uneven enforcement.

Practical implication: require implementation standards that preserve policy consistency across human, NHI, and agentic access paths.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent access changes identity governance because the subject of access is no longer stable. Human IAM assumes a person, a session, and a reviewable trail. Once access extends to machines and agents, the governance model has to account for identities that may act without fixed working hours, predictable intent, or a human approval loop. The implication is that access governance can no longer be built around employee-centric assumptions alone.

Extended Access Management is really a control response to identity sprawl across actor types. The market is moving toward programmes that unify SaaS access, device trust, and non-human identity oversight under one policy layer. That matters because access fragmentation is now a governance failure, not just an operational inconvenience. Practitioners should treat disconnected control planes as a sign that identity scope has outgrown the programme.

Agentic AI is forcing the industry to name a new boundary: right access is now about runtime behaviour, not just provisioned entitlement. A machine identity with broad standing access can be administratively valid and still operationally unsafe once its behaviour changes at runtime. This is where conventional IAM recertification logic becomes incomplete, because it checks who has access, not what the actor may do with that access. Practitioners need to rethink entitlement models around action scope as well as identity scope.

NHI governance and human IAM are converging around the same control question: who or what is authorised to act, under what conditions, and with what revocation path. The article reflects a broader market signal that identity programmes are being forced to govern SaaS sprawl, automation, and AI agents through one decision framework. That convergence is useful only if organisations stop treating machine identity as an edge case. The practical conclusion is that identity governance must be actor-aware, or it will remain partial.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 52 NHI Breaches Analysis shows how exposed service credentials turn governance gaps into real incidents, not just theoretical risk.

What this signals

Trust layer drift: as SaaS, automation, and AI agents converge, the practical boundary of IAM shifts from login control to runtime authorisation across multiple actor types. Teams that keep human access governance and NHI governance in separate workstreams will struggle to explain who is accountable when an agent acts with inherited access.

The policy question is moving toward whether identity programmes can express trust consistently across humans, workloads, and agentic systems. That is why NHI visibility and offboarding discipline matter even in conversations that appear to be about AI adoption.

If your programme still measures access control mainly through user-centric reviews, the coverage gap will widen as more workflows are executed by systems rather than employees. The next phase of identity governance is not more authentication steps, but clearer actor classification and tighter revocation paths.

For practitioners

• Classify access by actor type Separate human, NHI, and AI agent identities in your access model so policy, review, and revocation paths are explicit for each actor type.
• Map SaaS access to runtime trust signals Tie authorisation decisions to device context, entitlement scope, and current identity state so access is not granted on static assumptions alone.
• Review non-human access as a governance domain Bring service accounts, API keys, and AI agents into the same governance workflow instead of leaving them in separate operational queues. See the Ultimate Guide to NHIs for lifecycle and visibility patterns.
• Standardise partner deployment controls Require implementation partners to follow a consistent control baseline for identity security deployments across SaaS, automation, and AI-enabled workflows.

Key takeaways

• The article signals a market shift from employee-centric identity controls to governance that must also cover machines and AI agents.
• Identity security is becoming a runtime trust problem, because entitlement alone does not explain what an AI agent or workload can do after access is granted.
• Practitioners should unify human IAM and NHI governance into one actor-aware model before SaaS sprawl and automation create unreviewed access paths.

Key terms

• Actor type: Actor type is the identity category that determines how access should be governed, such as human, non-human, or autonomous. In practice, it shapes how teams review entitlement, define revocation, and evaluate risk because the same control behaves differently across different identity subjects.
• Extended access management: Extended access management is a control model that covers access beyond traditional employee login, including SaaS, service identities, and AI agents. It tries to unify trust, entitlement, and device context so organisations can govern access wherever work actually happens.
• Runtime authorisation: Runtime authorisation is the decision to allow or deny access based on current conditions, not just what was provisioned earlier. For non-human and agentic identities, it matters because static entitlement alone does not explain what the actor can do in the moment.

Deepen your knowledge

Access governance across human, machine, and AI agent identities is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is now dealing with SaaS sprawl and agentic access, this is a practical place to build that baseline.

This post draws on content published by 1Password: 1Password earns place on CRN’s 2026 Security 100 list. Read the original.