Human → Non-Human → Agentic: How Enterprise Identity Is Changing

Enterprise identity is moving through three overlapping governance domains — human, non-human and agentic. Human identity built its controls around people. Non-human identity extended those controls to software and machines that act. Agentic identity adds actors that can act on behalf of others, with delegated authority and some degree of autonomy. As it does, the governing question widens from "who is this actor, and may it access this?" toward "what is it allowed to act for, on whose behalf, and who is accountable?" — a shift from identity to authority.

These domains are not a maturity ladder, and they are not three mutually exclusive technical categories. They coexist in every enterprise. What changes as you move across them is not how many identities you hold, but how much *autonomous action* an actor can take — and how well your operating model can account for it.

Identity governance began with a human operating model

Enterprise identity and access management grew up around people. The model had recognizable anchors: an employee, a manager, a job, a role, a joiner-mover-leaver lifecycle, an HR system of record, and periodic access reviews. Access was requested, approved, certified and — eventually — removed, because there was almost always a person and an organizational structure behind it.

None of this means human identity governance is solved. Workforce IAM still struggles with over-entitlement, role complexity, rubber-stamp certifications, orphaned accounts and privilege creep. The point is narrower and more durable: human identity inherited *accountability structures*. Even when the controls are imperfect, an enterprise can usually name who a human identity belongs to, who approved its access, and what event should end it. That inheritance is exactly what the next two domains lack.

Non-human identity changed the actor

Digital operations increasingly run on actors that are not people: service accounts, applications, workloads, API clients, automation, devices, managed identities and other software principals. The consequential shift is not that there are more identities. It is that systems now act directly — authenticating, holding access and doing work without a person in the loop at that moment.

Those actors still need what human identities have: a purpose, an owner, authentication, authorization, a lifecycle and accountability. The structural problem is that operating models designed around people rarely provide equivalent anchors for software. A service account created by a deployment four years ago may have no owner, no review and no retirement condition — not because the enterprise lacks tools, but because the human operating model was never extended to it. (For the precise definition of a non-human identity, and why a credential is not the identity, see What Is a Non-Human Identity?.)

Scale can amplify this, but scale is not the argument. An enterprise with a few hundred unowned, unretired software actors has the same governance gap as one with a few hundred thousand — it simply has fewer of them.

Agentic identity changes the authority problem

AI agents introduce a further shift. A conventional service account executes a defined operation. An agent may instead interpret an objective, choose a sequence of steps, select tools, retrieve information, invoke systems and make bounded decisions along the way. Not every AI model is an identity, and not every assistant is an agent with broad autonomy; the governance question arises specifically when a software actor can be recognized, can hold or exercise authority, can take action, and can potentially act on behalf of another subject.

That last property is the pivot. The transition is from acting to acting on behalf of — and once an actor is acting on someone else's behalf, authenticating it is no longer the hard part. This thesis does not attempt to define agentic identity in full; the canonical definition, including why an agent is technically an NHI but a distinct governance class, is What Is Agentic Identity?, and the deeper analysis of why agents are more than service accounts with a new label is in AI Agents Just Changed the NHI Conversation.

From "Who are you?" to "What are you allowed to act for?"

This is the centre of the thesis. Traditional identity control asks two questions well: *who is this actor?* and *may this actor access this resource?* Authentication answers the first; authorization answers the second. Neither stops mattering. But for actors that operate with delegated authority and autonomy, they are increasingly insufficient on their own. The enterprise must also be able to answer:

• What may this actor do — in effect, not just in theory?
• On whose behalf is it acting?
• Under what conditions and for what purpose?
• With what degree of autonomy?
• Who is accountable for the result?

That progression — from identity, to access, to authority — is the change AVIKORE sees reshaping enterprise identity. It is worth being precise about the word *authority*, because it is easy to collapse it into privilege. Privilege, permission and entitlement describe what a principal technically may access or execute. In AVIKORE's framing, authority is broader: the legitimate scope in which an actor may act — potentially on behalf of another subject — under a defined purpose, constraints and accountability. Two agents can hold identical permissions and very different authority, because authority includes on whose behalf, for what, and within what limits they are entitled to act.

Delegation itself is not a new or exotic idea; identity standards already model it. IETF's OAuth 2.0 Token Exchange (RFC 8693), for example, deliberately separates the subject — the party on whose behalf a request is made — from the actor, the acting party, and lets a token state through its `act` and `may_act` claims that one party is authorized to act on behalf of another. That the standard has to distinguish "who is acting" from "on whose behalf" is itself the point. The mechanics of delegation exist. Knowing that an action was delegated, however, is not the same as governing whether it should have been — its purpose, its bounds, and who answers for it remain enterprise decisions, not protocol settings.

The operating model has to change with the actor

If the actor is changing, the operating model has to follow. Across all three domains the same questions recur, but they get harder as autonomy rises:

• Ownership — a named, accountable owner that survives personnel change.
• Purpose — why the actor exists, in terms a reviewer can understand.
• Authority — the legitimate scope of action, not merely assigned permissions.
• Delegation — on whose behalf the actor may act, preserved as context.
• Lifecycle — creation, change, review and a real retirement condition.
• Accountability — who answers for what the actor does.

For a human, most of these are inherited from employment and management. For a non-human identity, they must be deliberately established. For an agentic actor, they must be established *and* bounded by delegation, purpose, conditions and intent. This is why AVIKORE treats Human, Non-Human and Agentic as one identity fabric rather than three programs: the actors differ, but the accountability model has to be continuous across them.

What enterprises should recognize now

The practical conclusion is not a checklist. It is a change of emphasis. Programs that were built to answer *who are you?* need to become equally good at answering *what are you allowed to act for, on whose behalf, and who is accountable?* Human identity already has structures that make those questions answerable; the work is extending that same accountability to software and, increasingly, to agents — before autonomous actors are in production rather than after.

Enterprises that recognise this early tend to adopt automation and agents faster, because identity and authority are designed in as an enabler rather than retrofitted as an emergency control. The organisations that struggle are usually the ones that treated non-human and agentic identity as more of the same authentication problem, when the harder problem had already moved to authority.

What to understand next

• The definitional foundation: What Is a Non-Human Identity?
• Extending a human-shaped IAM program to every identity class: Your IAM Program Was Designed for People
• Where strategy, architecture, exposure and decision meet — AVIKORE's identity advisory model.

Research Sources

External standards are cited to establish that concepts such as delegation are recognized and specified; the thesis and its framing are AVIKORE's own analysis.