Why autonomous actors need their own identity model

The first time you give an agent real access to a system, you discover that most identity architectures were built around an assumption that no longer holds.

Every platform already knows how to deal with people and services. It has a login flow for users, complete with redirects, consent screens, MFA challenges, and sessions. It has a machine identity model for workloads, complete with credentials, client authentication, and narrowly scoped access. For years, those two models have been enough because almost every actor fit comfortably into one of them.

Agents do not.

An agent often operates using authority that originates from a person, yet it performs work without that person being present. It may execute minutes, hours, or days after the original authorization was granted. It may move across systems that the user never directly touches. It may combine capabilities in ways that nobody explicitly designed ahead of time.

The moment an agent begins participating in real workflows, the distinction between human and machine identity starts to feel less complete than it once did. The problem is not that agents are somehow half human and half service. The problem is that they separate responsibilities that traditional identity systems quietly combined.

The person authorizing the work is no longer the entity performing it, yet the relationship between those two identities remains essential. Identity systems can no longer treat authorization and execution as a single event because they may be separated by time, context, and hundreds of individual actions.

Most of what we now call agent identity is an attempt to reconcile that separation.

Why Human Accounts Break Down

Human accounts assume participation.

The same person who authorizes access is the same person who exercises it, which allows identity systems to center everything around explicit moments of interaction. A user logs in, reviews a consent screen, approves a set of permissions, establishes a session, and proceeds. The authority and the action belong to the same actor, so the chain connecting them rarely needs to be expressed directly.

That model begins to strain when the actor stops being the person who granted the authority.

An agent cannot pause every few minutes to ask someone to click through another consent screen. It cannot depend on an active browser session. It cannot assume that the user will be present when a task runs. The entire premise of agentic systems is that work continues after the user has stepped away.

Many early implementations try to avoid confronting this reality by forcing agents through the existing human model. Browser sessions are preserved and replayed. User tokens are shared across multiple executions. Consent flows designed for interactive use are scripted and automated.

These approaches usually work long enough to create confidence before they create confusion.

Once multiple agents begin operating under the same borrowed credentials, answering basic questions becomes surprisingly difficult. Which agent performed this action? Which user authorized it? Was the action executed under delegated authority or under independently granted permissions? The system may still have logs, but the identity model can no longer clearly explain what happened.

The problem is not that the authentication succeeded. The problem is that accountability has become blurred.

Why Agents Are Not Service Accounts

The natural reaction is to treat agents as another form of non-human identity.

That classification is technically correct, but it conceals a fundamental difference.

A service account acts entirely under its own authority. An agent does not.

A service account receives a credential and operates within a predefined boundary. Its permissions are known ahead of time. Its purpose is usually narrow. It performs work as itself and answers only for itself.

Agents move between contexts.

Reading a user’s calendar may require delegated permissions derived from that user’s consent. Creating execution records, maintaining state, interacting with infrastructure, or invoking internal services may rely on permissions owned directly by the agent itself. During a single workflow, an agent may alternate repeatedly between borrowed authority and independent authority.

The same identity continuously changes footing depending on the action being performed.

That distinction changes the role identity plays within the system.

A service account is often little more than a credential attached to a workload. An agent becomes an identity that can accumulate grants, own connections, participate in policy decisions, and appear directly in audit records. It is not simply a channel through which permissions pass. It becomes a first-class participant in the exchange.

You can see the shift in the token model itself.

Traditional clients rarely appear as meaningful actors within a delegation chain. They request tokens intended for downstream services and largely disappear from the security conversation. A first-class agent changes that relationship. Tokens are issued specifically for the agent. The agent validates that those tokens were intended for it. Delegation chains record the agent as a named participant rather than an invisible intermediary.

Even the audience claim begins to tell a different story. Instead of acting as a transport mechanism carrying credentials toward another destination, the agent becomes a recognized actor within the trust relationship itself.

The distinction may appear subtle, but it becomes increasingly important as agents gain reach across systems.

The Question Identity Has Always Asked

At its core, identity has always existed to answer a simple question:

Who is allowed to do what?

For years, we were able to simplify that question because the person authorizing an action was often the same person performing it. When that was true, principal and actor could safely collapse into a single identity.

Service accounts simplified things in a different direction. They largely removed delegation from the conversation. The service acted as itself, so there was rarely a need to ask on whose behalf it was operating.

Agents bring both concerns back at the same time.

The person authorizing the work matters. The entity executing the work matters. The relationship between them matters.

As a result, identity systems are forced to represent three distinct concepts explicitly:

• The principal who authorized the work.
• The actor performing the work.
• The delegation chain connecting them.

An agent account is ultimately a mechanism for preserving those relationships as work moves through autonomous systems. It is the place where principal, actor, and delegation stop being assumptions and become first-class objects.

What an Agent Account Actually Contains

Once the philosophical discussion ends, what remains is architecture.

A workable agent identity model begins by giving every agent its own identity. Not a shared credential. Not a repurposed user account. An actual identity that can be governed independently.

That identity becomes the anchor for everything else.

Permissions, connections, ownership, policy evaluation, and audit records all attach to the agent itself rather than being inferred from surrounding context. The system can now reason about the agent as an actor instead of treating it as a side effect of some other identity.

The model also needs to distinguish between delegated authority and independent authority. An agent must know when it is acting on behalf of a user and when it is acting as itself. That distinction determines how permissions are evaluated, how actions are recorded, and how responsibility is assigned.

Around that foundation sit the familiar primitives identity systems have always relied upon:

• Scopes that define what an agent may do.
• Delegations with explicit lifetimes.
• Consent records that capture authorization events.
• Credential resolution policies that determine whose authority is being spent.
• Session grants that govern connection reuse.
• Access summaries that describe current reachability.
• Audit records that preserve the full chain of execution.

None of these concepts are particularly new.

What changes is the actor they are being applied to.

The challenge is no longer managing a human session or securing a service credential. The challenge is preserving the relationship between authorization and execution while work moves through autonomous systems that may cross dozens of boundaries before it finishes.

Harnesses and Enforcement

An identity model only matters if it can be enforced consistently.

If every integration invents its own authentication model, delegation mechanism, and audit strategy, the agent account becomes little more than a diagram. Some systems will honor the model. Others will bypass it. Eventually the architecture and the implementation drift apart.

All of the controls described above need a common enforcement point.

Every tool invocation needs to pass through a layer capable of determining whether the operation should execute using delegated authority or independent authority. Every request needs a place where scopes can be evaluated, credentials resolved, delegation chains attached, and audit records generated.

Without that boundary, agent identity becomes difficult to govern because every integration becomes a special case.

With that boundary, identity becomes a property of the platform rather than a property of individual tools.

Why MCP Matters

This is where MCP becomes interesting.

MCP gives agents a standardized way to reach tools and services, but the protocol itself is only part of the story. More importantly, it creates a common surface where identity decisions can be applied consistently.

The protocol boundary becomes the place where delegated and independent execution are distinguished, where credentials are resolved, where scopes are evaluated, where delegation chains are attached to requests, and where audit records are generated.

The gateway in front of an MCP environment is where the agent account stops being an architectural concept and becomes an operational reality.

That consistency benefits everyone involved.

Users authorize access once and allow the agent to continue operating without repeated interruptions. Developers inherit identity, delegation, and auditing capabilities through a common protocol instead of rebuilding them for every integration. Security teams gain confidence that every request reaches a policy enforcement point before it reaches a tool.

Most importantly, the system retains the ability to answer the questions that matter.

Who performed this action?

Who authorized it?

How are those two connected?

Another kind of Identity

Agent accounts are not simply human accounts with automation attached, nor are they service accounts with broader permissions.

They represent a different identity pattern, one built around the separation of authorization and execution.

Humans allowed identity systems to collapse principal and actor into the same entity. Service accounts often removed delegation from the conversation altogether. Agents require both concepts to exist simultaneously and remain visible throughout the lifecycle of a task.

The future of agent identity comes from extending familiar security principles into a world where authority, action, and responsibility can no longer be assumed to reside in the same place.

As agents become more capable and more autonomous, preserving those relationships stops being an implementation detail and becomes the foundation on which trustworthy systems are built.

And all of this is only a small part of a much larger conversation. This post focused on identity because agents force us to rethink how we represent principals, actors, and delegation. The next challenge is authorization, and that problem is considerably messier. Context, risk, Human-in-the-Loop approvals, and dynamically evolving tasks all make it harder to answer not just who is acting, but whether an action should be allowed at all. Agent accounts provide a foundation for reasoning about identity. Whether our authorization models are ready for autonomous actors is a question for another post.