# AI Agent Identity: Who Acted, and Under Whose Authority? > Source: > Published: 2026-09-08 00:00:00+00:00 Suppose you tell an agent: *move Acme to At Risk, create a task for the account owner, and prepare a renewal plan.* The agent does exactly that. What should your CRM say happened? **Last modified by Renat**, because you asked for it? **Last modified by Renewal Agent**, because the agent performed the operation? Or **Renewal Agent, on behalf of Renat**, because both facts matter? This looks like a UX detail. It isn't. It's the question of **AI agent identity**, and the honest answer is the third one. Almost no enterprise system has a place to put it. ## What is AI agent identity?[#](#what-is-ai-agent-identity) AI agent identity is the practice of giving an AI agent its own distinct, verifiable identity in your systems. That identity is separate from the human who asked it to act, and separate from the shared service account it might otherwise borrow. It exists so every action the agent takes can be attributed to it specifically. Most of the industry now agrees on that much. [Okta](https://www.okta.com/identity-101/what-is-ai-agent-identity/), Astrix and Strata all define it in roughly those terms. The hard part is what the definition leaves out, so let's name it immediately: - **Identity** answers*who performed this operation?* Call that the**actor** . - **Authority** answers*whose permissions allowed it to happen?* Call that the**authority** . A *principal*, in identity terms, is any entity a system can authenticate and grant rights to. For a human user, the actor and the authority are the same principal, so enterprise software only ever built one field. A user authenticates, the user has roles, the user performs an action, the audit log records the user. One principal, start to finish. An agent breaks that. Consider two chains that produce an identical database write, both routed through the Model Context Protocol (MCP), the emerging standard for connecting agents to tools: In both, the Renewal Agent is the actor. In the first, a person is the authority. In the second, running at 03:14 with nobody at a keyboard, the authority is an organizational policy and the permissions granted to the agent itself. Same actor, same write, completely different accountability. A system with one field cannot tell them apart. Hence the argument of this piece: **every production agent should have an identity, but not every agent should have its own authority.** Those are two separate decisions. Conflating them produces both of the common failure modes: agents that vanish behind a human's name, and agents handed far more power than the job needs. ## Enterprise software was built for one kind of actor[#](#enterprise-software-was-built-for-one-kind-of-actor) Identity systems have spent decades getting good at people. Then they added a second category, applications and service accounts, for machines running predefined operations. That gave us a clean two-box model: humans who decide, and software that executes. The second box is now enormous. Palo Alto Networks' 2026 *Identity Security Landscape* surveyed 2,900+ cybersecurity decision-makers and reports that [machine identities outnumber humans 109:1](https://www.paloaltonetworks.com/idira/idira-identity-security-landscape). Treat that as directional rather than precise, since the publisher sells identity security. The industry's name for that box is "non-human identity," and the operational concern behind it is sprawl: thousands of long-lived credentials nobody owns or rotates. Agents don't fit either box. An agent can reason, choose which tools to call, decide which records to modify, and initiate a sequence nobody specified. That's the human box. It also needs machine credentials, deterministic policy, and tight privilege scoping. That's the service-account box. ### Should an AI agent be a service account or a user account?[#](#should-an-ai-agent-be-a-service-account-or-a-user-account) Neither, exactly. Treating an agent as a service account gets you credential hygiene but loses the fact that it made a choice. Treating it as a user account gets you attribution but quietly grants it a person's entire authority. Both are the one-principal model straining against a two-principal reality. You can already see the split showing up in how AI tooling gets packaged. Across the Claude surfaces, [the question that separates the products is whose credentials run the work](/blog/claude-code-cowork-tag-routines), a personal checkout or an organization's shared credentials in a Slack channel, rather than which agent is smartest. That's an authority question wearing a product-packaging costume. ## Agentic identity: actor and authority are two different things[#](#agentic-identity-actor-and-authority-are-two-different-things) Once you separate actor from authority, a lot of confused arguments resolve. "Just let the agent use the user's OAuth token" is the most common shortcut. It's a statement about authority that accidentally destroys the actor. The agent gets the right permissions and becomes invisible in the process, because every action it takes is indistinguishable from the human's own. That's tolerable when the agent is summarizing a report. It's misleading when the agent decided something at 03:14. The mechanics for keeping both facts already exist in the identity world. OAuth's on-behalf-of flow and [RFC 8693 token exchange](https://www.rfc-editor.org/rfc/rfc8693) let one principal act with another's authority while remaining distinguishable, carrying a `subject` and an `actor` in the same token. What's been missing isn't cryptography. It's the enterprise convention of using it for agents, plus the fields in downstream systems to record the result. Microsoft's own guidance frames this as a question any agent identity model has to answer: [was the action performed on behalf of a user or by the application itself?](https://learn.microsoft.com/en-us/startups/build/identity-management/identity-fundamentals-ai-agents) That's the actor/authority distinction in a vendor's words, and it's a question your CRM's `Last Modified By` field structurally cannot answer. ## Five models of agent autonomy[#](#five-models-of-agent-autonomy) "AI agent" describes deployments so different that one identity policy can't cover them. Sorting by autonomy rather than architecture gives five models, and the amount of visible identity each needs rises as you go down the list. ### 1. The invisible assistant[#](#1-the-invisible-assistant) The agent searches, summarizes, or drafts using the user's permissions. From the business application's point of view the human is still the actor, and that's fine. For low-risk assistance, inventing a separate principal adds governance overhead with nothing to govern. ### 2. The named capability[#](#2-the-named-capability) The organization creates a recognizable "Renewal Agent" or "Research Agent." People invoke it, and it still runs on the invoking user's authority. The agent has a product identity without becoming an independent employee. Most internal AI tooling lives here, and most of it should. ### 3. The delegated agent[#](#3-the-delegated-agent) The agent has its own identity and acts under someone's delegated authority, so the system can record `subject: Renat, actor: Renewal Agent`. I'd expect the bulk of enterprise agent activity to land here, because it's the first rung that survives an audit: you can reconstruct both who wanted the work and what performed it. ### 4. The autonomous agent[#](#4-the-autonomous-agent) Its own identity *and* its own constrained permissions. It monitors, decides, and acts on organizational policy rather than waiting for a person to ask. Nobody is present, so borrowing a human's authority isn't just imprecise, it's a fiction. ### 5. The digital coworker[#](#5-the-digital-coworker) The agent becomes an organizational participant with its own account and presence, and colleagues interact with it roughly as they would another team member. Identity here is not optional or implied: the agent needs a first-class organizational account, because other people will address it, assign it work, and expect its actions to be attributable the way a colleague's are. The five models aren't competing standards to pick between. They're rungs, and the useful principle is directional: **the more independently an agent acts, the less acceptable it becomes for it to hide behind a human identity.** Ask an assistant to find your 10 largest renewals next quarter, and making it an independent business user buys you nothing. But when an agent independently decides at 03:14 that an opportunity is at risk and writes to Salesforce, recording **Last modified by Renat** is not a simplification. It's wrong. I wasn't there and I didn't make that decision. ### What are the 7 types of AI agents?[#](#what-are-the-7-types-of-ai-agents) The standard seven-type taxonomy sorts agents by internal architecture: simple reflex, model-based reflex, goal-based, utility-based, learning, multi-agent, and hierarchical. That taxonomy helps you build an agent. It tells you nothing about who should be accountable for one, because architecture and autonomy are independent axes. A simple reflex agent running unattended against production needs a stronger identity story than a sophisticated learning agent that only drafts text for a human to send. ## How six platforms handle agent identity today[#](#how-six-platforms-handle-agent-identity-today) Here's what makes this architecture rather than opinion. Six platforms have taken up the same distinction, in different idioms, with no shared standard between them. They are not equally far along, and the differences matter more than a tidy summary would suggest. | Platform | How it treats actor and authority | |---|---| | **Microsoft Entra Agent ID** | Ships both principals. Two explicit modes: [autonomous access, using access rights given directly to the agent identity, and delegated access, acting on behalf of human users with rights the user controls](https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities) . For agents created in Copilot Studio, it also records the user who created the agent as its**sponsor** , which is an authority field in a shipping product. | | **Google Cloud Agent Identity** | Ships both principals, a layer lower. Each agent gets [a strongly attested cryptographic identity based on the SPIFFE standard](https://docs.cloud.google.com/iam/docs/agent-identity-overview) , an open standard for issuing verifiable identities to workloads. Explicitly not a shared service account: not shared between workloads by default, not impersonable, no long-lived keys. It supports an agent using its own identity, and an agent acting for a specific user. | | **GitHub Copilot coding agent** | Ships both principals as two fields on one object: [commits are authored by Copilot, with the human who started the task marked as the co-author](https://docs.github.com/en/copilot/responsible-use/agents) . Neither identity disappears. | | **Salesforce Agentforce** | Addresses authority, not attribution. [Every agent is associated with a running user, an identity that determines what the agent can access and perform](https://www.salesforce.com/blog/best-practices-for-secure-agentforce-implementation-2/) . Whether standard audit fields name the agent is a separate question, discussed below. | | **ServiceNow** | Addresses authority by constraining it. Agents run as a dynamic user inheriting the invoking user's permissions, with [role-masking limiting them to a subset of that user's roles](https://www.servicenow.com/community/now-assist-articles/latest-access-control-enhancements-for-ai-agents-and-skill-kit/ta-p/3374036) . That's the intersection model below, shipped and mandatory. | | **Model Context Protocol** | Names both principals, and lists the work as unfinished. The spec already [forbids token passthrough](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) , while the roadmap states that[MCP authorization assumes a person with a browser at consent time](https://modelcontextprotocol.io/development/roadmap) and calls for agents to be reachable through their own or a user-delegated identity. | Two caveats, because the tidy version of this table is more confident than the sources are. First, Microsoft's agent user accounts are narrower than they're often described. Agents *can* be paired with [special Entra user accounts for scenarios that require them to "appear and operate as if they're human users"](https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities), but the same page is clear that agent identities represent software systems rather than people. Second, on Salesforce: the running user determines what an agent may do, but I could not find a Salesforce primary source stating that standard audit fields like `Created By` name the agent rather than that user. Treat agent-level attribution there as an open question, not a shipped guarantee. So the accurate scorecard is three platforms recording both principals today, two addressing the authority half, and the protocol maintainers naming both while the work is still in flight. That's the useful finding. Microsoft, Google and GitHub arrived at the same two-principal structure without coordinating on a standard, and the MCP maintainers independently named it as the gap to close. Four arrivals at one structure suggests the distinction is being forced by the problem rather than chosen as a fashion. ## What happens when an agent is deleted?[#](#what-happens-when-an-agent-is-deleted) The lifecycle question is where agentic identity stops resembling service-account management. Microsoft's own comparison is blunt: application identities carry "the expectation of long-term stability, known ownership, and managed lifecycle," whereas [an agent might exist for minutes, or be created and destroyed thousands of times per day](https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities). The stated goal of a dedicated agent identity is to let organizations create them in bulk, apply consistent policy, and retire agents without leaving orphaned credentials or permission assignments behind. That reframes provisioning. If an agent's offboarding depends on a person remembering to revoke a key, the process will not survive that rate of change. You accumulate exactly the orphaned-credential problem that non-human identity management was invented to solve. ## Agent permissions are an intersection, not an inheritance[#](#agent-permissions-are-an-intersection-not-an-inheritance) Once agents are identifiable principals, a second assumption breaks: *if I can do it, should every agent I use also be able to do it?* Clearly not. A chief revenue officer can view every opportunity, change ownership, approve discounts, delete records, and export customer data. A pipeline-analysis agent invoked by that executive needs to read opportunities, update a few fields, and create tasks. Nothing else. So the mental model isn't `agent permissions = user permissions`. It's closer to: `effective permissions = user authority ∩ agent permissions ∩ workflow policy` An intersection, not an inheritance: three constraints that all have to permit an action, rather than one grant flowing downhill. This isn't hypothetical. ServiceNow ships it. In an official ServiceNow community write-up, Victor Chen documents that agents [run as a "Dynamic user" which inherits the permissions of the invoking user (default)](https://www.servicenow.com/community/now-assist-articles/latest-access-control-enhancements-for-ai-agents-and-skill-kit/ta-p/3374036), and that role-masking "minimizes the roles with which AI Agents can execute to a subset of the invoking user's roles." Note what that is: the invoking user's authority intersected with an agent-specific grant. And it isn't advisory. On current releases it is "enabled for added AI Agents security" and "is also a required configuration" (specifically Zurich Patch 4 and Yokohama Patch 11, with the Now Assist AI Agents store app v6.0 or later). There's a broader shift hiding in this. Traditional role-based access control asks *what can this user do?* Agentic systems have to ask something richer: *what can this agent do, under this user's authority, through this tool, to this resource, in this context, right now?* That's a policy problem, which raises the question of where the policy lives. It cannot live inside the agent, because a prompt-shaped guardrail is a suggestion: [if the rules live in the agent you are one clever prompt away from a leak, whereas rules living in the layer the agent has to query hold](/blog/what-is-a-semantic-layer). The same instinct shows up in how autonomous data work gets governed, where [scoped, time-bound permissions with an immutable audit trail](/blog/agentic-data-engineering) are the mechanical half of separating actor from authority. Identity tells you who acted. Authority tells you why they were allowed to. Enforcement decides whether the answer was true. ## Why MCP authorization is now an agent identity problem[#](#why-mcp-authorization-is-now-an-agent-identity-problem) The Model Context Protocol is becoming a common interface between agents and enterprise tools, which makes it where identity assumptions get tested. An agent might soon execute a chain like `agent → MCP server → CRM → billing system → another agent`. ### Does MCP require OAuth?[#](#does-mcp-require-oauth) For HTTP-based servers, yes in practice: the authorization spec is built on OAuth 2.1, though the spec marks authorization itself as optional and tells stdio servers to take credentials from their environment instead. The naive implementation propagates a user's bearer token down that whole chain. The specification forbids it, in normative language: [clients must not send tokens to an MCP server other than ones issued by that server's authorization server, servers must only accept tokens valid for their own resources, and must not accept or transit any other tokens](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization). Tokens have to be validated as issued specifically for that server as the intended audience, per [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707). Audience-binding is a good rule. It solves the confused-deputy problem, where a service with broad permissions is tricked into using them on a caller's behalf. It does not solve the identity problem, and the maintainers say so. Their roadmap is unusually direct: [MCP authorization assumes a person with a browser at consent time, while increasingly the caller is an agent, a cloud workload with its own identity, acting for a user who isn't present, or spawning sub-agents that should get narrower authority than their parent](https://modelcontextprotocol.io/development/roadmap). They're blunt about the status quo too, noting that existing servers "lean on pasted API keys and long-lived refresh tokens," and about the goal: "an opinionated way for MCP servers to be reached by agents through their own identity or a user-delegated identity." Read that last line again. It's both principals, named by the people who maintain the protocol, listed as unfinished work. MCP started with an understandable mental model: person → AI client → tool. That's still how it's usually explained, and by default [an MCP server acts on behalf of the user, so the agent inherits the user's own permissions](/blog/what-is-an-mcp-server). The emerging reality is `person → agent → agent → MCP → service`, and sometimes just `agent → MCP → service`, with no human available to complete a consent screen. The practical failure is familiar to anyone who has wired one up against real data. Row-level security is the database rule that decides which rows a given user is allowed to see. Skip identity propagation and [it silently stops applying, because the server never passed the calling user's identity through](/blog/what-is-an-mcp-server-for-data), so every caller sees everything. MCP doesn't eliminate the identity problem. It makes solving it unavoidable. ## Agent observability: from audit log to action graph[#](#agent-observability-from-audit-log-to-action-graph) Traditional audit logs record a fact: *Renat changed field X from A to B at 14:32.* One actor, one action, one timestamp. That shape can't hold an agent's work. For an autonomous action, the questions that matter form a chain: 1. Who requested or triggered this? 2. Which agent decided to act? 3. What context did it use? 4. Which policy authorized it? 5. Was human approval required? 6. Which tool or MCP server did it invoke? 7. What did it change? 8. What happened as a result? Answer those and you no longer have a log. You have a graph, with nodes for principals, agents, policies and tools, and edges for delegation and causation. This is where agent observability stops being a debugging convenience and becomes the accountability record. The closest thing shipping today is GitHub's commit trail, worth looking at precisely because it's unglamorous. Copilot is the author, the delegating human is the co-author, [the commits are signed so they appear as "Verified"](https://docs.github.com/en/copilot/responsible-use/agents), and each commit message links to the agent session logs. Actor, authority, integrity and provenance: four facts on one object, in a system nobody would describe as an identity platform. One more concept that pure action-logging misses. Some agent output isn't an action, it's an artifact: code, a document, an account plan, a forecast, a proposal. For those, neither "Created by Renat" nor "Created by AI" tells the story, and shared authorship is the more honest record: created by the agent, delegated and approved by a person. The provenance of knowledge work deserves the same treatment as the provenance of database mutations, and today it rarely gets it. ## Which agents do we employ?[#](#which-agents-do-we-employ) So the question enterprises need to answer isn't *which AI agents do we allow?* It's: **which agents do we employ, who is responsible for them, what authority have we delegated to them, and can we reconstruct every consequential action they take?** We spent decades building identity systems on the assumption that meaningful business actions trace back to a human. Agents break that assumption by adding a second principal the schema never had room for. Getting this right means knowing more than which model generated a response. It means knowing who asked, which agent acted, under whose authority, what it was permitted to do, what it did, and why. That's what accountability looks like when humans and agents work the same jobs. ## Frequently asked questions - Are AI agents non-human identities? - Technically yes, but the category is misleading. "Non-human identity" was coined for service accounts, API keys, and machine credentials: things that perform predefined operations and never choose. An agent chooses which tools to call, which records to modify, and which steps to take in a sequence nobody specified. That makes it a third category, sitting between a human user and a service account. Treating an agent as just another non-human identity gets you credential hygiene, which is necessary, but it does not answer the accountability question of who is on the hook when the agent decides something wrong. - What are the 7 types of AI agents? - The usual seven-type taxonomy classifies agents by internal architecture: simple reflex, model-based reflex, goal-based, utility-based, learning, multi-agent, and hierarchical. That list is useful for designing an agent and nearly useless for governing one, because it says nothing about how much independence the agent has. For identity and access decisions the axis that matters is autonomy, which gives five models instead: the invisible assistant, the named capability, the delegated agent, the autonomous agent, and the digital coworker. Each rung demands a different amount of visible identity. - What is a non-human identity? - A non-human identity is any credentialed actor in a system that is not a person: a service account, an application registration, an API key, a workload, a CI/CD pipeline. The term comes from the identity-security world, where the operational concern is sprawl, meaning thousands of long-lived credentials nobody owns or rotates. Palo Alto Networks' 2026 Identity Security Landscape survey puts the ratio at 109 machine identities per human, which is why the category exists at all. - How do you implement authentication in MCP? - For an HTTP-based server, follow the Model Context Protocol's authorization spec: act as an OAuth 2.1 resource server, publish Protected Resource Metadata so clients can discover your authorization server, and validate on every request that the presented token names your server as its intended audience. The rule that catches most implementations is what you must not do: never accept a token minted for something else, and never forward the token you received to a downstream API. For a local stdio server, the spec says not to use this flow at all and to take credentials from the environment instead. - What is non-human identity management? - Non-human identity management is the practice of discovering, owning, scoping, rotating, and retiring credentials that belong to software rather than people. In most enterprises it began as a response to secrets sprawl: nobody could say which service accounts existed, who owned them, or what they could reach. Agents raise the difficulty, because they are created and destroyed far faster than service accounts and their authority may be borrowed from a human rather than granted directly. - What is the difference between identity and authority for an AI agent? - Identity is who performed the operation, the actor. Authority is whose permissions allowed it, the person or the organizational policy. For a human user those two collapse into one field, because the person who acted is also the person who was allowed to. For an agent they come apart: a renewal agent may perform an operation that a specific sales rep authorized, or that a nightly policy authorized with no human involved at all. Keeping both facts is what makes an agent's actions auditable. - Does MCP require OAuth? - For HTTP-based servers, the Model Context Protocol's authorization specification is built on OAuth 2.1, and the spec requires a server to accept only tokens issued for itself as the intended audience. Local servers communicating over stdio do not use it and retrieve credentials from their environment instead. The constraint that matters is not whether OAuth is required. It is that tokens must not be passed through: a token minted for one MCP server must never be forwarded to a downstream API. - Do MCP servers require authentication? - The specification makes authorization optional, but any server exposed over HTTP that touches real data should authenticate. The common failure in the wild is weak authentication rather than none. The MCP maintainers note that existing servers lean on pasted API keys and long-lived refresh tokens, neither of which tells you which agent acted or under whose authority. - What permissions should an AI agent have? - Fewer than the person invoking it, almost always. The workable model is an intersection: the invoking user's authority, AND the agent's own granted permissions, AND the policy governing that workflow. A pipeline-analysis agent invoked by a chief revenue officer needs to read opportunities, update a few fields, and create tasks. It does not need that executive's ability to approve discounts, change record ownership, delete records, or export customer data. Inheriting the invoker's full rights is the common default and the wrong one. - How do you retire an AI agent's identity? - Deliberately, and at a speed service-account processes were never built for. Microsoft's own guidance for Entra Agent ID notes that an agent may exist for minutes, or be created and destroyed thousands of times per day, and that the point of a dedicated agent identity is to let organizations retire agents without leaving orphaned credentials or permission assignments behind. If your offboarding process for an agent is a human remembering to revoke a key, it will not survive that rate of change. Read more about revenue operations, growth strategies, and metrics in our [blog](/blog) and follow us on [LinkedIn](https://www.linkedin.com/company/revos-ai/) and [Youtube](https://www.youtube.com/channel/UCqoOOxonDfeNEXpqoTuSSLQ). [All articles](/blog)