What Is Agentic Identity? Governing AI Agents as Identities

Agentic identity is the governed identity an AI agent acts under when it takes actions in enterprise systems: a distinct, attributable identity that binds the agent to an accountable human owner, a delegated and bounded scope of authority, the policies that constrain it, and the evidence of every action it completes. Governing AI agents as identities means every agent can be named, scoped, monitored, and revoked, and every action it takes can be traced back to the person whose authority it used.

The term matters because agents changed what software does. A model answers. An agent acts: it resets a password, requests access for a new hire, disables an account, and chains those steps together at machine speed. The moment software acts on a system of record, the question stops being about model quality and becomes an identity question. Which identity did this? On whose authority? Under which policy? And where is the proof?

This piece is the Agentic AI hub for the Avatier Identity Anywhere 2027™ series, and it deliberately stays at the definitional and governance level. The mechanics of how an agent authenticates (consent flows, delegation tokens, agent credentials) are covered in depth in Identity for AI Agents and Agentic Authentication. The broader population of workloads and service accounts is covered in Machine Identity Management and Service Account Governance and Non-Human Identity. What follows is the frame that sits above both: what an agentic identity is, how it differs, and what it takes to govern one.

What agentic identity means, and what it does not

An agentic identity has four parts, and a governance program missing any one of them is not really governing the agent.

The agent itself. A distinct, registered identity for the agent, not a borrowed service account or a shared API key. If five agents share one credential, the audit log can only ever say that one of them did it.

The delegating principal. The human (or, for fully autonomous agents, the accountable owner) whose authority the agent is exercising. An agent has no authority of its own. It borrows it.

The scope. What the agent is allowed to do for that principal, for this task, right now. Scope is narrower than the principal's own entitlements, never wider.

The evidence. A record, produced as the action completes, that ties the other three together: who asked, what ran, under whose authority, and which policy allowed it.

Agentic identity is not an authentication protocol, although it depends on good ones. It is not the chat window a user types into; that is an interface, not an identity. And it is not a service account with a new label. Treating agents as ordinary service accounts is the most common early mistake, because it quietly discards the one fact that makes agents different: they act for someone, and that someone changes from one task to the next.

Human vs. machine vs. AI-agent identity

Identity programs already govern two populations. Human identities come from HR, carry job functions, and move through joiner-mover-leaver events. Machine identities (workloads, services, APIs, service accounts) come from deployment artifacts and execute the logic they were built with. AI agents borrow traits from both and match neither, which is why neither playbook transfers cleanly.

	Human identity	Machine / service identity	AI-agent identity
Who acts	A person, making their own decisions	A workload running fixed, pre-written logic	Software that plans and chooses its next step, usually for a person
Authority source	Role and job function, granted through HR-driven provisioning	Standing permissions scoped to the workload's purpose	Delegated from a human principal or accountable owner, bounded per task
Lifecycle	Joiner, mover, and leaver events tied to employment	Created on deployment, retired on decommission	Registered per agent, scoped per task, revoked when the purpose ends or the delegator's access changes
How it's audited	Periodic manager access reviews plus login and activity logs	Owner-team scope reviews, credential inventory, and rotation	Per-action evidence linking agent, principal, authority, policy, and result

Three rows do most of the work. Who acts is the difference in kind: a service account executes, an agent decides, so the blast radius of an over-scoped agent grows with every increment of autonomy it is given. Authority source is the difference in accountability: a service account's authority is its own standing permission set, while an agent's authority belongs to someone else and is only on loan. How it's audited is the difference in evidence: a periodic review tells you what an identity could do, but for an agent the auditor's question is what it did, on whose behalf, at the moment it did it.

Humans decide, machines execute, and agents decide on someone else's behalf, which is why agents need per-action evidence the older populations never did.

The practical consequence: an agent needs a standing entry in the identity inventory like a machine identity, an accountable human owner like a person, and per-action evidence that neither older population has ever required.

Delegated authority: the agent acts, a human stays accountable

Delegated authority is the principle that an AI agent acting on behalf of a person may exercise only authority that person holds, only within the scope granted for the task, and never beyond it. It is the concept that separates agentic identity from everything else in the identity stack.

A clean delegation chain has five links:

1. A principal with authority. An employee, manager, or administrator authenticates and holds entitlements in the systems your identity platform already governs.
2. A request. The principal asks an agent to do something: unlock my account, add the new analyst to the reporting group, disable the contractor whose engagement ended today.
3. An approved capability. The agent does not reach into the directory directly. It invokes a specific, pre-approved capability that exists for that action.
4. A policy decision. The identity platform, not the agent, decides whether the action is permitted, checking the principal's authority, the agent's scope, approval requirements, and separation-of-duties rules.
5. Evidence. The completed or refused action is recorded with every link of the chain attached.

The rule that makes this chain safe is short: the agent is the interface, never the authority. An agent can collect the request, choose the capability, and report the result. It cannot grant itself permission, widen its own scope, or talk its way past an approval step, because the decision is made somewhere the agent does not control. If a manager lacks the authority to approve privileged access, an agent acting for that manager lacks it too.

The agent collects the request and invokes a capability; the identity platform decides and records, so authority never passes to the agent itself.

Two failure patterns show why this matters. When an agent runs under a broad standing service account, every action looks like the agent's, and the human intent behind it disappears from the record. When an agent simply reuses the user's full session, the agent disappears instead, and nobody can tell which actions a person took and which an agent took for them. Delegated authority keeps both identities in the record: the agent that acted and the human whose authority it used. The token-level mechanics of carrying that chain are in the agentic authentication reference. Governance is about making sure the chain exists and is enforced for every action.

The agent identity lifecycle: create, scope, monitor, revoke

Every identity that can act needs a lifecycle, and agents are no exception. The difference is tempo. An agent can be created in an afternoon and forgotten by the end of the quarter, which is the orphaned-account problem with a much faster failure mode. Four stages cover it.

1. Create. Register the agent as a distinct identity with a named human owner, a documented purpose, and the systems it is expected to touch. An agent that is not registered should not be able to act through governed channels at all. This is the step most early deployments skip, usually by handing the agent an existing credential just for the pilot.
2. Scope. Grant the minimum capabilities the purpose requires, and bind delegated actions to the principal's own authority. Prefer narrow, task-level capabilities (unlock an account, request a role) over broad permissions (write to the directory). Put human approval in front of the sensitive actions: privileged access, terminations, and bulk changes.
3. Monitor. Compare what the agent actually does with what it was scoped to do. Every action should produce evidence, and patterns that drift from the declared purpose (new systems, unusual volume, repeated refused requests) should reach a reviewer. The agent and its owner belong in access reviews like any other identity.
4. Revoke. Retire the agent when its purpose ends, when its owner leaves, or when anything about it looks wrong, and make revocation a single step that removes all of its access at once. Revocation should also follow the principal: when a delegating human's access changes, what agents can do on that person's behalf changes with it.

Create, scope, monitor, revoke: revocation is where most agent programs fail, because nothing forces the question until something goes wrong.

The revoke stage is where most programs are weakest, for the same reason dormant human accounts pile up: nothing forces the question. The patterns in Orphaned and Dormant Accounts apply directly. An ownerless agent is simply an orphaned account that can take actions on its own.

The four questions every agent action has to answer

Avatier's CISO, Dr. Sam Wertheim, framed the audit problem at the Identity Anywhere 2027 launch in a way that doubles as a working definition of agentic governance. Auditors, he said, are moving past asking whether an organization has MFA. They want to know which human or AI identity touched a regulated system, what authority it used, what policy was enforced, and where the evidence is. His conclusion: "If an organization cannot audit an AI-initiated identity action, it does not fully control it."

That yields four questions, and each maps to a specific piece of evidence that has to exist when the action completes, not be reconstructed weeks later from scattered logs.

Auditor's question	Evidence that answers it
Which identity acted?	The identity involved, plus the initiating agent or experience
Under what authority?	The authorization context: the delegating principal and the scope granted
Under which policy?	The policy applied to the request
With what evidence?	The action taken and the final result, recorded together with the fields above

The right-hand column is not hypothetical. It is the set of fields Avatier records for each Secure Outcome in Identity Anywhere 2027: the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. The design point is that the evidence is born with the action. When an agent resets a password or removes access, the record of who asked, what ran, and what allowed it is a byproduct of doing the work, not a separate reporting project someone assembles before the audit.

How that evidence becomes an answer for an auditor, a CFO, or a security team is the subject of the spoke on AI agent audit trails with Avatier Ledger.

Governing agents through approved capabilities, not raw access

Many enterprise agents now reach tools through the Model Context Protocol (MCP), the open standard introduced by Anthropic in November 2024 that lets AI assistants connect to tools and data through MCP servers exposing tools, resources, and prompts. MCP matters for agentic identity because it changes where governance can sit. Instead of giving an agent a credential and hoping it only does the right things, you expose a defined set of identity capabilities as tools, and every agent action has to pass through one of them.

That design supports the controls that conservative security guidance already recommends:

• Least privilege and allow-listing. Expose only the capabilities a use case needs, and only to the agents approved for it.
• Scoped, short-lived authorization. The MCP authorization specification builds on OAuth 2.1. Scope tokens to the task and keep them short-lived.
• Human approval for sensitive actions. Terminations, privileged grants, and bulk changes route to a person before they run.
• Logging on every call. Each invocation produces evidence, including the refusals.
• Prompt-injection and tool-poisoning awareness. Treat content an agent reads as untrusted, and vet the MCP servers you connect the same way you vet any supply-chain dependency.

The deeper treatment lives in the spokes. MCP Identity Governance covers how identity outcomes are governed when they run through MCP, and How to Secure MCP Servers covers hardening the servers themselves. The governance idea for this hub is narrower: an agent should act through approved capabilities that enforce your policy, never through raw access that assumes the agent will behave.

What Avatier ships toward this pattern

Avatier Identity Anywhere 2027™ is built to govern people, applications, machines, credentials, and AI agents, and to generate audit evidence for human, machine, and AI-agent identity actions. The pieces that map most directly to agentic identity are two MCP connectors announced on September 24, 2026.

Avatier Actions exposes more than 50 identity outcomes as MCP tools across eight modules: Password Management, Help Desk, Lifecycle Management, User Management, Group Management, Access Governance, Workflow Approval, and Reports. These are the approved capabilities an agent invokes. Every request runs through the customer's existing policies, approvals, and roles, and nothing bypasses governance, because the assistant is the interface, never the authority. AI assistants do not receive unrestricted access: each request must invoke an approved Avatier capability and remains subject to authentication, authorization, delegated authority, policy enforcement, and audit controls. Avatier determines whether an identity action is permitted and records what occurred. Help Desk actions such as assisted reset sit alongside the verification discipline described on the Assisted Reset pillar.

Avatier Ledger turns every outcome into evidence. It records who asked, what ran, under whose authority, and what policy allowed it, for human-initiated and agent-assisted actions alike. Persona Briefings then shape the same evidence for the person asking: compliance frameworks and remediation windows for a CISO, cost and breach prevention for a CFO, and exposure, dormant and orphaned access, and privileged activity for the security team.

Both connectors work inside Claude, Claude Code, Microsoft Copilot, Avabot, and any MCP-compatible assistant. Setup is one administrator connection, and permissions are inherited from the platforms customers already run (Microsoft Entra ID, Active Directory, Okta, Ping), so agent actions are bounded by the entitlements and roles that already exist rather than by a new permissions model. Avatier runs alongside those platforms, and alongside SailPoint, Saviynt, ServiceNow, and Moveworks, rather than replacing them. A healthcare organization with more than 100,000 identities is running or piloting the platform.

The commercial model follows the same unit. Under Pay Per Identity Action™, customers pay only for completed, verified, policy-compliant outcomes, so every charge corresponds to an action that already carries its own evidence. Getting started is free, deployment services are included, and a 45-day money-back guarantee applies. The Avatier Trust Center publishes the compliance posture behind it: SOC 2 Type II audited with zero exceptions noted, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, CSA STAR Level 1, and NIST 800-53 Rev. 5 aligned.

What agentic identity governance does not solve

Governing agents as identities closes the accountability gap. It does not close every gap, and it is worth being precise about where it stops.

It does not make the agent's judgment trustworthy. Policy decides whether an action is permitted, not whether it was wise. A prompt-injected agent that requests an action inside its legitimate scope will be allowed to take it. Narrow scopes and human approval on sensitive actions limit the damage; they do not prevent the coercion.

It only governs the path you govern. Evidence and policy apply to actions that flow through approved capabilities. An agent a developer wires straight to a directory with a pasted API key sits outside that path entirely. Discovering those shadow agents, and making the governed path the easy one, remains your job.

It inherits the strength of the human side. A delegation chain is only as trustworthy as the principal's authentication. If the person delegating authority signed in with a phishable factor, every action taken on their behalf inherits that weakness.

It does not replace authentication or machine-identity hygiene. Agent credentials, token lifetimes, secrets, and workload identity still need their own controls, covered in the agentic authentication and machine identity references.

It does not write your policy. A governance layer enforces the rules you define. If approval rules are loose or roles are over-provisioned, agents will act faithfully within loose rules and over-provisioned roles. As the Ai4 2026 briefing argued, agent governance only works on top of an identity foundation that already functions.

There is also no settled industry standard yet for how agent identities should be represented across vendors, and anyone who says otherwise is ahead of the evidence. The durable part is the frame: a distinct agent identity, a delegating principal, a bounded scope, and evidence for every action. Build to that frame, and the mechanics can change underneath it without the accountability changing with them.