Agentic Identity
What Is Agentic Identity?
A practitioner-led definition of agentic identity — why an AI agent is technically a non-human identity but a distinct governance class, why authentication is necessary but not sufficient, and how delegated authority becomes the central control problem.
Agentic identity is the governance problem that appears when a non-human identity can act on behalf of a person or system, with delegated authority and some degree of autonomy. Technically, an AI agent is a non-human identity — it authenticates and is authorized like any other actor. But governing it takes more than authentication: an enterprise has to know what authority the agent holds, who delegated it, on whose behalf it is acting, and who is accountable for the result. In AVIKORE's model, agentic identity is a distinct governance class, not simply a new kind of account.
This is a fast-moving area, and the vocabulary is not yet settled. Where this resource draws a line, it says so as AVIKORE's analytical framing rather than a finished industry standard.
An AI agent can be an NHI — but that is not the whole governance problem
Start with what is not new. An AI agent needs an identity, authenticates with credentials, and is granted access — exactly like a service account or a workload. In that sense an agent is a non-human identity, and much of what already governs non-human identity still applies: discovery, ownership, least privilege, credential security, lifecycle and monitoring.
What is new is the kind of actor. A conventional service account executes a predetermined 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 — and it may do all of that *on behalf of* a person, an application or another agent. The Cloud Security Alliance, in its work on agentic identity and access management, frames this as a qualitatively different problem than managing a set of static service accounts, precisely because of autonomy, short-lived and multi-step behaviour, and delegation across systems.
Not every AI system is an agent, and not every agent has broad autonomy. A model that answers a question is not, on its own, an identity to be governed. The governance problem appears specifically when a software actor can be recognized, can hold or exercise authority, can take action across systems, and can act on someone else's behalf.
Authentication tells you who acted. It does not define what they may act for.
Security teams reasonably begin with authentication, and agents should not run on shared or hard-coded credentials. Knowing *which* agent acted is necessary. Knowing it authenticated successfully is necessary. Knowing what technical permissions it held is necessary. None of that stops mattering.
But for an actor that operates with delegated authority and autonomy, those answers are no longer sufficient. Successful authentication answers "was this actor allowed to authenticate?" It does not answer "was this action appropriate for the authority it was delegated?" Agentic systems therefore push identity closer to questions of purpose, scope and behaviour — dimensions that a credential and a permission set do not, by themselves, capture.
Delegated authority changes the control model
The pivotal property is that an agent can act *on behalf of* another subject. That is where governance has to become more precise about authority than about authentication.
Delegation itself is a recognized, specified concept. IETF's OAuth 2.0 Token Exchange (RFC 8693) 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 a standard has to distinguish "who is acting" from "on whose behalf" is the point: the mechanics of delegation exist.
What the protocol does not decide is the governance. Standards can express that authority was delegated; they cannot tell an enterprise whether the delegation was legitimate, what its boundaries are, what purpose it serves, how long it should last, or who remains accountable when the agent acts. Those remain enterprise decisions. Treating token exchange as a complete answer to agent governance mistakes a delegation mechanism for a delegation policy.
The AVIKORE Agentic Authority Model
AVIKORE evaluates a material agent through five lenses. Each is a question the enterprise should be able to answer before the agent reaches production.
- Identity — who is acting? The agent should be distinguishable from the user, application or platform that created it. Shared identities destroy attribution.
- Authority — what may it do? Defined at the level the task requires, in effect, not merely as an assigned permission set.
- Delegation — on whose behalf? An agent may have its own identity while operating under delegated user or application authority; that context has to be preserved, not flattened.
- Intent — what was it authorized to accomplish? An action can be technically permitted yet fall outside the task the agent was delegated to perform.
- Accountability — who owns the consequence? Not merely the developer. Someone must own the business use, the permitted authority and the risk.
Identity → Authority → Delegation → Intent → Accountability. That progression, not authentication alone, is the agentic identity problem in executive terms.
The combined-authority problem
There is a further issue that traditional access models handle poorly. An agent may accumulate authority from more than one source at once: authority delegated by a human, plus its own application or service privileges, plus access reached through tools and connected systems. Each grant may be individually legitimate. The combined effective authority may be something no single source intended.
Consider an agent that can read a supplier record, modify banking details, create a payment and route an approval. Each capability might be authorized in isolation; the combination is a path no human would ordinarily be permitted to complete alone. This is AVIKORE's framing of a real risk, and it rhymes with separation-of-duties thinking — but it is not the same. Classic separation of duties assumes a human actor and known role combinations. Agentic systems compose authority dynamically across tool calls, so the enterprise has to reason about *chains of action*, not just isolated permissions. AVIKORE treats this as an analytical concern to design for, not a settled standard control.
What enterprises need to govern
The practical conclusion is not a checklist; it is a change in what the operating model has to account for. For a material agent, an enterprise should be able to establish:
- a distinct identity, so the agent is knowable apart from whoever created it;
- explicit ownership, technical and business, for the agent's use and risk;
- scoped authority, matched to the task rather than inherited wholesale from a creator;
- delegation context, preserving who or what authorized the activity;
- bounded autonomy, so the agent's discretion has limits appropriate to its purpose;
- attributable, reconstructable action, so an auditor can see what the agent did across systems;
- lifecycle and revocation, including a reliable way to withdraw an agent's authority without disrupting unrelated users or services.
None of these are answered by authentication. They are answered by treating the agent as a governed actor with delegated authority — which is what makes agentic identity a distinct class.
Where agentic identity fits in enterprise identity
Agentic identity is best understood as the newest stage in a longer shift. Human identity built its controls around people; non-human identity extended them to software that acts; agentic identity adds actors that act *on behalf of* others. Across that arc 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?" That evolution — and why it is a change from an identity problem to an authority problem — is the subject of AVIKORE's signature thesis.
What to understand next
- The definitional foundation: What Is a Non-Human Identity?
- The evolution and the identity→authority thesis: Human → Non-Human → Agentic
- The deeper market analysis of how agents changed the conversation: AI Agents Just Changed the NHI Conversation
- Why accountability comes before tooling: You Don't Have an NHI Tool Problem
If a major identity or agent-governance decision is imminent, AVIKORE's advisory model exists for exactly that kind of judgment.
Research Sources
External standards and neutral frameworks are cited to establish that delegation and agentic identity governance are recognized problems being specified; the models and positions here are AVIKORE's analysis.
Research sources
Market and vendor material reviewed as evidence during research — cited for context, not as endorsement.
Related insights
Human → Non-Human → Agentic: How Enterprise Identity Is Changing
AVIKORE's thesis on how enterprise identity is evolving — from a human operating model, to software that acts, to agents that act on behalf of others — and why the governing question is shifting from identity to authority.
AI Agents Just Changed the NHI Conversation
Why agentic identity is less about another account type and more about controlling delegated authority across enterprise systems.