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 Alex, because you asked for it? Last modified by Renewal Agent, because the agent performed the operation? Or Renewal Agent, on behalf of Alex, 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?
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.
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):
Alex -> Renewal Agent -> MCP -> HubSpot
Renewal policy -> Renewal Agent -> MCP -> HubSpot
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
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. 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?
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.
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 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? 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
"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. 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. 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. The agent has its own identity and acts under someone's delegated authority, so the system can record subject: Alex, 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. 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. 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: 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.
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.
| Platform | How it treats actor and authority |
|---|---|
| Microsoft Entra Agent ID | Ships both principals. Two explicit modes: autonomous access (rights given directly to the agent identity) and delegated access (acting on behalf of human users). For agents created in Copilot Studio, it also records the user who created the agent as its sponsor. |
| Google Cloud Agent Identity | Ships both principals, a layer lower. Each agent gets a strongly attested cryptographic identity based on the SPIFFE standard. Not a shared service account: not impersonable, no long-lived keys. Supports an agent using its own identity, and 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. Neither identity disappears. |
| Salesforce Agentforce | Addresses authority, not attribution. Every agent is associated with a running user that determines what it can access. Whether standard audit fields name the agent is a separate, open question. |
| 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. The intersection model, shipped and mandatory. |
| Model Context Protocol | Names both principals, and lists the work as unfinished. The spec forbids token passthrough, while the roadmap states that MCP authorization assumes a person with a browser at consent time, and calls for agents to be reachable through their own or a user-delegated identity. |
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. 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.
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: agents run as a "Dynamic user" which inherits the permissions of the invoking user, and role-masking minimizes the roles an agent can execute to a subset of the invoking user's roles. That's the invoking user's authority intersected with an agent-specific grant, and on current releases it's a required configuration, not advisory.
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, and the policy cannot live inside the agent, because a prompt-shaped guardrail is a suggestion. Rules that live in the layer the agent has to query hold; rules that live in the prompt are one clever injection away from a leak.
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.
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, and servers must only accept tokens valid for their own resources. Tokens have to be validated as issued specifically for that server as the intended audience (RFC 8707).
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. They call for "an opinionated way for MCP servers to be reached by agents through their own identity or a user-delegated identity."
That's both principals, named by the people who maintain the protocol, listed as unfinished work.
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, so every caller sees everything. MCP doesn't eliminate the identity problem. It makes solving it unavoidable.
From audit log to action graph
Traditional audit logs record a fact: Alex 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: Who triggered this? Which agent decided to act? What context did it use? Which policy authorized it? Was human approval required? Which tool did it invoke? What did it change? 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: Copilot is the author, the delegating human is the co-author, the commits are signed so they appear as "Verified," 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.
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.
This article was originally published on the RevOS blog.
Want to see this on your own revenue data? Book a RevOS demo.
Top comments (2)
Really thoughtful breakdown of the actor-authority split — I've been thinking about this a lot. One place this distinction becomes operationally concrete is when an agent needs to authorize a payment. The agent can reason about what to pay and propose a transaction — that's the actor layer. But the signing key that releases the funds has to live in a separate context, because the authority to spend can't be delegated to the same principal that decided what to spend on. That boundary is where your two-principal model meets moving money. The agent gets the identity you asked for, but the wallet doesn't hand over the keys — it evaluates the proposal and confirms or rejects. This is the design constraint any production agent payment system has to solve, and the frameworks that preserve the actor-authority split in the payment domain are the ones that will survive an audit.
Payments are probably the cleanest example of why the split matters. With a CRM field, conflating actor and authority gives you a misleading audit log. With money, it gives you an agent that can approve its own spending.
What you describe maps nicely onto the "permissions as an intersection" idea: the agent can propose anything within its own scope, but the transaction only goes through if the authority side, in your case the wallet, independently agrees. The agent never holds the power to commit, only to ask.
The part I find interesting is the middle ground. Most teams won't want a human confirming every small payment, so the authority often becomes a policy ("auto-approve under €500 to known vendors"). That's the nightly-policy case from the post: the actor is still the agent, but the authority is a rule someone signed off on earlier. For the audit, you then need three things recorded, not two: who acted, under which authority, and which policy version approved it.
How are you handling that in practice? Explicit confirmation per transaction, or pre-approved limits?