WorkOS and Astrix show the split between human and machine identity

At a glance

What this is: WorkOS argues enterprise identity now separates into human authentication and machine identity governance, with Astrix focused on the non-human layer and MCP-era AI agent controls.

Why it matters: IAM teams need distinct governance for humans, NHI, and AI agents because the access patterns, lifecycle risks, and control points are no longer interchangeable.

By the numbers:

• For every human employee, there are roughly 100 non-human identities operating across cloud infrastructure, SaaS applications, and AI platforms.
• A 1,000-person company may have 100,000+ machine identities, many of which authenticate thousands of times per hour.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read WorkOS's analysis of NHI governance and MCP authorization

Context

Enterprise identity is no longer a single control plane. Human sign-in, machine credentials, and AI agent authorisation now create different risk surfaces, and the same IAM process does not govern them all well. The article frames that split clearly: humans authenticate through conventional enterprise access controls, while non-human identities need discovery, rotation, monitoring, and lifecycle governance.

That distinction matters because machine identities scale differently from human users and often outlive the business context that created them. As NHI populations grow, teams need to stop treating service accounts, tokens, and agent credentials as administrative leftovers and start treating them as governed identities. For a broader baseline on this control model, see the Ultimate Guide to NHIs.

Key questions

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

A: Security teams should govern human and non-human access with separate control paths, because the lifecycle, credential type, and review evidence are different. Human IAM should focus on sign-in assurance and role assignment. NHI governance should focus on discovery, scope, rotation, ownership, and offboarding so machine credentials do not persist beyond their business purpose.

Q: Why do service accounts and API keys create more risk than many human accounts?

A: Service accounts and API keys often run continuously, carry broad scopes, and are reused across systems without interactive sign-in friction. That makes them attractive targets and hard to review manually. When they are not rotated or retired, they create persistent access paths that can outlive the application or workflow they were created for.

Q: What do organisations get wrong about AI agent authorisation?

A: They often treat agent access as a tooling problem instead of an identity problem. If an agent can obtain credentials, call tools, and keep working without clear token scope and revocation, the environment inherits machine identity risk. Agent authorisation should be explicit, short-lived, and auditable, especially when MCP is involved.

Q: How should teams decide whether MCP access is safe enough to allow?

A: Teams should allow MCP access only when the agent or server can be bounded with explicit scopes, revocable credentials, and traceable client registration. If the integration depends on static secrets, shared keys, or opaque delegation, the access model is too durable for reliable governance and should be redesigned before production use.

Technical breakdown

Human authentication and machine identity live in separate trust models

Human IAM assumes a person signs in interactively, proves who they are, and then works within a session governed by SSO, MFA, directory sync, and role assignment. Machine identity works differently. API keys, service accounts, OAuth grants, workload identities, and agent credentials operate continuously, often without a person present at execution time. That means access lifetime, credential storage, and scope enforcement matter more than login friction. The article’s core technical point is that one identity stack cannot safely substitute for the other when access patterns are fundamentally different.

Practical implication: split governance, review, and detection logic for human sessions and non-human credentials instead of forcing one access model across both.

NHI discovery, rotation, and lifecycle management are the control spine

Non-human identity programmes fail first at visibility. If teams cannot enumerate machine identities across cloud, SaaS, on-prem systems, secrets stores, and CI/CD tooling, they cannot assess exposure or ownership. Once discovered, the critical controls are rotation, decommissioning, and permission right-sizing. Long-lived keys, stale OAuth grants, and dormant service accounts create persistent attack paths because the credential remains valid even after the original use case has changed. Lifecycle governance is therefore not an administrative process. It is the mechanism that turns NHI sprawl into something measurable and reducible.

Practical implication: build inventory, rotation, and offboarding into the same operating model so NHI risk does not persist after business need ends.

OAuth 2.1 for MCP turns AI agent access into a standards problem

AuthKit for MCP places AI agents and MCP servers into an OAuth 2.1 authorisation model, which is important because agent access should be scoped, tokenised, and auditable rather than handled with static shared secrets. In practice, this shifts the problem from informal integration trust to controlled delegation. Dynamic client registration, scopes, PKCE, refresh tokens, and token introspection are the technical levers that make agent access reviewable. The real security question is not whether an agent can call a tool. It is whether the tool access is time-bound, purpose-bound, and revocable under standard identity controls.

Practical implication: require standards-based authorisation for MCP-based agent access and eliminate static secrets where delegated access can be tokenised.

Threat narrative

Attacker objective: The objective is to use trusted non-human credentials to reach infrastructure, data, or agent tooling without triggering human authentication controls.

1. Entry occurs when machine credentials such as API keys, OAuth tokens, or service accounts are embedded in workflows, logs, or agent memory and become accessible outside their intended context.
2. Escalation occurs when those credentials carry broad scopes or excessive privilege, letting an attacker or rogue workflow move from a narrow integration point to data, tools, or cloud resources.
3. Impact follows when compromised non-human identities bypass human-side controls and enable persistent misuse of infrastructure, sensitive data access, or chained agent actions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

NHI governance is now a bifurcated discipline, not a single stack. Human authentication, workload identity, and AI agent authorisation now require different control assumptions, different review cadences, and different evidence models. Treating them as one programme creates false confidence because the identity subject behaves differently in each layer. Practitioners should separate human sign-in governance from machine credential governance before they try to unify reporting.

Standing machine access remains the core NHI failure mode. The article reinforces a simple reality: long-lived credentials, broad OAuth grants, and dormant service accounts are still the easiest way for identity risk to persist unnoticed. That is why the issue is not only compromise, but accumulated exposure over time. The practitioner conclusion is clear: if access does not have a lifecycle, it becomes a liability.

Authorisation for AI agents should be standards-driven, not memory-driven. Once MCP servers and agents use OAuth 2.1, the governance question becomes whether the token, scope, and delegation boundary are explicit enough to survive audit and revocation. This is where the identity security market is heading. Practitioners should expect agent access to be managed like a high-volume NHI class, not a novelty feature.

Identity blast radius is the concept teams should use to prioritise controls. A single compromised machine credential can propagate far beyond the original service, especially when it is reused across pipelines, agents, and integrations. The article shows that the practical unit of risk is not the account itself but the access graph it unlocks. Practitioners should assess how far one credential can travel before they decide what to protect first.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why machine identity exposure often remains undetected until incident response begins.
• For a broader control baseline, Top 10 NHI Issues is the most useful next step for teams building an NHI programme.

What this signals

Identity blast radius is becoming the practical way to prioritise NHI controls. When one credential can reach pipelines, cloud resources, and AI integrations, the question is no longer whether the account is privileged, but how far compromise can travel before revocation or containment kicks in.

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 governance gap is structural rather than procedural.

Teams should expect identity programmes to split further across human, machine, and agentic control paths. The operational signal is simple: if your review process cannot distinguish a person from a workload or an autonomous agent, your governance model is already behind deployment reality.

For practitioners

• Inventory every non-human identity class Map service accounts, API keys, OAuth grants, workload identities, and agent credentials across cloud, SaaS, CI/CD, and secrets stores. Record owner, purpose, expiry, and privilege level so the programme can identify orphaned or duplicated access.
• Separate human and machine access reviews Use different review criteria for employee accounts and non-human credentials. Human access reviews should validate role fit, while NHI reviews should validate scope, rotation status, and whether the credential still maps to an active business process.
• Replace static secrets with revocable delegated access Where MCP or API integrations require ongoing access, prefer standards-based OAuth flows, short-lived tokens, and scoped client registration instead of long-lived shared keys stored in code or agent memory.
• Define offboarding for service accounts and agents Tie decommissioning to the business event that ends use, not to a manual cleanup ticket. Revoke tokens, disable dormant identities, and verify that downstream integrations no longer depend on the credential before closure.

Key takeaways

• Enterprise identity is splitting into human authentication and non-human identity governance, and the controls are not interchangeable.
• Machine identity sprawl remains the larger risk surface because long-lived credentials, broad scopes, and poor visibility let exposure persist.
• Practitioners should separate review, rotation, and offboarding processes for humans, workloads, and AI agents before they unify reporting.

Key terms

• Non-Human Identity: A non-human identity is any credentialed digital actor that accesses systems without being a person. It includes service accounts, API keys, tokens, certificates, workload identities, and AI agents. The governance challenge is not authentication alone, but owning, scoping, rotating, and retiring access across its full lifecycle.
• Identity Blast Radius: Identity blast radius is the amount of infrastructure, data, and tooling that a single credential can reach if it is misused or compromised. In NHI governance, it is a practical measure of exposure, because a broad token or service account can move far beyond the task it was originally meant to perform.
• Machine Identity Lifecycle: Machine identity lifecycle is the full process of creating, monitoring, rotating, certifying, and decommissioning non-human credentials. It matters because credentials that never leave the environment cleanly become durable attack paths. Lifecycle control is the difference between managed access and permanent exposure.

Deepen your knowledge

Identity governance for service accounts, API keys, and AI agent access is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme that has to cover humans, workloads, and agentic systems together, it is worth exploring.

This post draws on content published by WorkOS: Astrix Security vs. WorkOS: Non-Human Identity Meets Enterprise Authentication. Read the original.