Why AI Agents Will Need Their Own Identity
AI agents are moving beyond conversation.
They can send emails, update calendars, access business systems, place orders, and communicate with other agents. As they begin to act on behalf of people and companies, a new question emerges:
How can a system verify who an AI agent represents—and what it is actually allowed to do?
Traditional login systems were designed for humans and conventional software. They can confirm that an account or API key is valid, but they often cannot distinguish between a person, an application, and an autonomous agent acting under delegated authority.
That gap is becoming harder to ignore.
Emerging technical proposals now explore dedicated identity and authorization frameworks for AI agents. These approaches differ in detail, but they share a common idea: an agent should have a verifiable identity, a clearly defined owner, limited permissions, and an auditable record of delegated authority. These proposals remain drafts rather than settled international standards, but they point toward an important shift in digital identity. (IETF Datatracker)
The Problem With Letting Agents Use Human Accounts
Most digital systems currently recognize two main types of actors.
A person logs in with an account, or an application connects with an API key or service credential.
AI agents do not fit neatly into either category.
An agent may use a person’s account, make its own decisions, call several tools, and pass part of a task to another agent. If all of those actions appear under the user’s identity, it becomes difficult to determine what actually happened.
Imagine that an AI purchasing agent places an order using an employee’s account. The system may record that the employee made the purchase, even though the agent selected the supplier, chose the product, and submitted the transaction.
That creates several unanswered questions:
- Which agent performed the action?
- Who authorized the agent?
- What permission was delegated?
- Was the action within the approved scope?
- Was another agent involved?
- Who is accountable if something goes wrong?
A valid login does not answer these questions. It only proves that a credential was accepted.
What an Agent Identity Would Need to Prove
An identity for an AI agent would need to contain more than a name or account number.
It would need to establish several relationships at once:
- the identity of the agent,
- the person or organization operating it,
- the user or system it represents,
- the authority delegated to it,
- the limits of that authority,
- and the period for which the authority remains valid.
A useful agent credential might effectively say:
This is a purchasing agent operated by Company A. It is acting on behalf of an authorized employee and may purchase approved office supplies from designated vendors, up to a specified amount, until the authorization expires.
The exact technology is still being debated. Some proposals give each agent a unique identifier and cryptographic key, requiring it to sign outbound actions. Others use decentralized identifiers, capability-based authorization, or signed delegation chains that preserve the link between the original principal and every downstream agent. (IETF Datatracker)
The underlying objective is the same: services should be able to verify not only who the agent is, but also why it has permission to act.
Identity Is Not the Same as Permission
Giving an agent a verifiable identity does not mean it should be trusted to perform every action.
The distinction is similar to the difference between showing identification and receiving authorization. A person may prove who they are without being permitted to access every room in a building.
Agent systems will need at least three separate checks.
Identity
Is this the agent it claims to be, and who operates it?
Authorization
What systems, data, tools, and transactions may it access?
Action validation
Is the specific action consistent with the user’s instruction and the organization’s policies?
A purchasing agent may be legitimate and authorized to place orders, for example, but a particular transaction should still be blocked if it exceeds its budget or uses an unapproved supplier.
The identity may be valid while the action is not.
Delegation Makes the Problem Harder
The issue becomes more complicated when agents begin working with other agents.
A travel agent may call separate airline, hotel, payment, and calendar agents. A corporate procurement agent may negotiate with a supplier’s sales agent. One agent may assign a specialized part of its task to another.
This creates a delegation chain:
Human → Primary agent → Specialist agent → External service
Every participant needs to know where the authority originated and whether it remained valid as it moved through the chain.
A delegated agent should not receive more authority than the original agent possessed. An agent authorized to spend up to $1,000 should not be able to give a sub-agent unlimited purchasing rights.
Several current Internet-Drafts propose cryptographically verifiable delegation chains and progressively narrower permissions for this reason. However, these documents are still individual or early-stage proposals and should not be treated as finalized IETF standards. (IETF Datatracker)
Why Existing API Keys Are Not Enough
API keys are convenient, but they are often too broad for autonomous agents.
A key may give access to an entire service rather than one task. It may remain active long after the original instruction has expired. It also may not identify which agent used it or which user approved the action.
When several agents share the same key, accountability becomes even weaker.
An agent-focused identity system would instead issue credentials that are:
- unique to the agent,
- limited to a specific task,
- restricted by time and scope,
- revocable,
- and linked to the original delegating party.
This is closer to a temporary power of attorney than a permanent password.
What Companies Can Do Now
Organizations do not need to wait for a universal standard before improving agent identity controls.
The first step is to stop treating agents as invisible extensions of human accounts. Each agent should have a separate identity and its own credentials. Shared user accounts and unrestricted API keys make it difficult to distinguish human actions from automated ones.
Permissions should also be limited by task, system, time, transaction value, and data type. High-impact actions such as payments, account changes, external communications, or data deletion should require an additional policy check or human approval.
Finally, every action should preserve its provenance. Organizations should be able to trace:
who requested the task → which agent accepted it → what authority was delegated → which tools were used → what action was completed.
Without that record, accountability disappears as soon as work passes from one agent to another.
The Cha Signal View
AI agents do not need identities because they are becoming people.
They need identities because they are becoming actors.
Once software can make decisions and perform transactions on behalf of others, a simple account login is no longer enough. Systems must know which agent acted, who authorized it, what it was permitted to do, and whether it stayed within those limits.
The next phase of agent development will not be defined only by intelligence or autonomy. It will also depend on whether agents can establish trust across organizations and services.
The most useful AI agent may not be the one that appears most human.
It may be the one that can clearly prove:
who it is, who it represents, and where its authority ends.
