Who Owns an AI Agent?

For a long time, software had a fairly simple relationship with identity.

A user created an account.

The account authenticated with a password, passkey, certificate, or some other credential.

The application performed an action on behalf of that user.

Even when multiple services were involved, the underlying model usually remained:

Human → Account → Application → Action

AI agents make that model much harder.

An agent can search the internet, read documents, call APIs, operate browsers, communicate with other systems, create transactions, modify files, deploy software, and potentially make decisions without a human approving every individual step.

That introduces a question that sounds philosophical but is actually an engineering problem:

Who owns an AI agent?

More precisely:

Who does an agent represent, what identity does it operate under, what authority has it been given, and how can another system verify the difference between the agent and the human or organization behind it?

This becomes increasingly important as AI systems move from generating information to taking actions in the world.

The answer is unlikely to be “the AI owns itself.”

The more useful model is that an agent becomes a distinct technical principal operating under delegated authority.

That distinction could become one of the foundations of the next generation of internet infrastructure.

1. An AI Model Is Not an AI Agent

Before discussing identity, we need to separate several things that are often treated as one.

An AI system might contain:

Model
Runtime
Agent
Identity
Operator
Authority

These are not the same thing.

A model is a statistical system that generates outputs.

A runtime executes software around that model.

An agent is the combination of reasoning, state, tools, policies, memory, and execution mechanisms that allows the system to pursue a task.

An operator is the human or organization responsible for deploying or controlling it.

An identity is the cryptographic or protocol-level representation used by other systems to distinguish the acting principal.

Authority is the set of permissions that principal has.

A useful abstraction is therefore:

                    HUMAN / ORGANIZATION
                             │
                             │ owns / controls
                             ▼
                       AGENT RUNTIME
                             │
                     ┌───────┴───────┐
                     │               │
                   Model          Identity
                     │               │
                     └───────┬───────┘
                             │
                         Authority
                             │
                             ▼
                           Actions

This distinction matters.

A model can be replaced without changing the agent's identity.

An agent runtime can be restarted without necessarily changing its identity.

An identity key can be rotated without changing who operates the system.

An agent can exist as a separate principal while still acting on behalf of a human or organization.

That is the conceptual foundation for everything that follows.

2. Why Human Identity Models Break Down

Consider a traditional application.

You log into your banking application.

The bank knows:

User = Anish

The user then performs:

Transfer ₹10,000

The bank records something equivalent to:

Anish → transfer → ₹10,000

Now introduce an agent.

You tell it:

“Pay the electricity bill every month.”

The agent now needs to:

1. find the bill

2. identify the correct account

3. determine the amount

4. authenticate to the payment system

5. initiate the transfer

6. receive confirmation

7. record the transaction

Who performed the transfer?

Was it you?

Was it the agent?

Was it the company operating the agent?

Was it the payment application?

All of these descriptions are true in different senses.

That is precisely the problem.

A system needs to distinguish:

Who owns the authority?
Who is acting?
What is being authorized?
What software executed the action?

Without that separation, accountability becomes extremely difficult.

3. The Difference Between Identity and Authority

One of the most important ideas in agent security is that identity and authority are different things.

Suppose your identity is:

Human
    DID = X

You could delegate a limited set of rights to:

Agent
    DID = Y

The agent might then receive:

Authority:

search invoices
read utility account
pay bills

Maximum:
₹20,000 / transaction

Expiration:
30 days

The agent is not you.

It is acting for you.

This distinction already exists in conventional authorization systems. OAuth 2.0 Token Exchange, for example, explicitly distinguishes delegation from impersonation. With delegation, the acting party retains its own identity while acting on behalf of another party; the specification even describes this relationship using the language of an “agent.” It also defines the act claim to express the current actor and the may_act claim to express an authorized actor. RFC Editor

That gives us a useful model:

Human Identity
       │
       │ delegates
       ▼
Agent Identity
       │
       │ exercises
       ▼
Specific Authority
       │
       ▼
Action

This is much safer than simply giving the agent the same credentials as the human.

4. Does an AI Agent Actually Need an Identity?

Not always.

This is an important qualification.

If an AI system is answering:

“What is the capital of Japan?”

it doesn't necessarily need an independent identity.

The user is asking a question.

The system returns information.

There is little reason for an external service to care whether the computation was performed by Agent A, Agent B, or a different model.

But the situation changes when the system acts.

Compare:

Answer a question

with:

Send an email

or:

Publish an article

or:

Deploy production code

or:

Transfer ₹100,000

or:

Purchase a server

or:

Sign a contract

At that point, another party needs to determine who is responsible for the action.

The stronger the consequences, the more useful a distinct agent identity becomes.

A simple progression is:

Read-only agent
      ↓
Agent identity useful

Agent with tools
      ↓
Agent identity increasingly important

Agent with persistent state
      ↓
Agent identity important

Agent acting across organizations
      ↓
Agent identity essential

Agent controlling money / infrastructure
      ↓
Strong identity + authorization + audit required

The need for identity therefore emerges from agency, not from the existence of AI itself.

5. Identity Should Belong to the Agent, Not the Model

Imagine an agent whose runtime currently uses Model A.

Next year, you replace it with Model B.

Should the agent become a different entity?

Probably not.

Consider:

Agent:
    Identity = Y
    Owner = X
    Permissions = P

The underlying model can change:

2026 → Model A
2027 → Model B
2028 → Model C

while:

Agent Identity = Y

remains stable.

This is similar to how infrastructure works today.

A web service can replace:

• its operating system

• its container

• its database

• its application version

without becoming a different legal or operational entity.

The identity belongs to the principal, not to every implementation detail.

For AI systems, this distinction becomes especially important because models are becoming interchangeable components.

6. A Better Identity Model

A useful architecture is:

                 OWNER
          Human / Organization
                    │
                    │ controls
                    ▼
                 AGENT
             Identity = Y
                    │
           ┌────────┼────────┐
           │        │        │
         Model    Tools    Memory
           │        │        │
           └────────┼────────┘
                    │
                 Policy
                    │
                    ▼
                 ACTION

Now another service can distinguish:

Owner = X
Agent = Y
Action = Z

This gives us something that ordinary account-based authentication often obscures.

Instead of recording:

“Anish's account called the API.”

we can record:

“Agent Y, operating under authority delegated by Anish, invoked capability Z.”

That is considerably more useful for autonomous systems.

7. Can an Agent Have Its Own Cryptographic Key?

Yes, and this is where the architecture becomes practical.

An agent can control a public/private key pair.

For example:

Private key:
    held by agent runtime

Public key:
    published / discoverable

Identity:
    associated with public key

The agent can then sign messages.

Conceptually:

Message
   +
Private Key
   ↓
Digital Signature

Another system can verify:

Signature
   +
Public Key
   ↓
Valid / Invalid

This provides a simple but powerful property:

The receiver can verify that the request was produced by whoever controls the corresponding private key.

DIDs are one possible way to package this relationship. DID Core defines verification methods as mechanisms—often cryptographic public keys—that can be used to authenticate or authorize interactions associated with a DID. The DID specification also separates authentication relationships from other verification relationships.

That does not mean every agent needs a DID.

It means DIDs provide a standardized conceptual primitive for representing a cryptographically controllable identity.

8. The Agent Identity Might Look Like This

A conceptual DID document could contain something along these lines:

{
  "id": "did:example:agent-42",

  "verificationMethod": [
    {
      "id": "did:example:agent-42#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:example:agent-42",
      "publicKeyMultibase": "..."
    }
  ],

  "authentication": [
    "did:example:agent-42#key-1"
  ]
}

The important part isn't the exact serialization.

The important relationship is:

Agent Identity
      │
      ▼
Verification Method
      │
      ▼
Public Key
      │
      ▼
Digital Signature

The public key tells others how to verify.

The private key proves control.

The DID provides an identifier through which that verification material can be discovered according to the chosen DID method.

9. But a Public Key Does Not Tell You Who Owns the Agent

This is where people often overestimate cryptography.

Suppose I generate:

Key Pair A

and announce:

“This is the official identity of my financial agent.”

Cryptography can prove that I control the corresponding private key.

It cannot, by itself, prove that:

“This agent is operated by Google.”

or:

“This agent is authorized by Anish.”

or:

“This agent is allowed to spend ₹100,000.”

Those are separate claims.

This leads to another layer:

credentials and attestations.

The W3C Verifiable Credentials model defines an ecosystem around issuers, holders, and verifiers, where an issuer makes claims, a holder possesses credentials, and a verifier checks them.

That gives us:

Identity:
    "I am Agent Y."

Credential:
    "Organization X authorized Agent Y."

Authorization:
    "Agent Y may perform action Z."

These are different statements.

And they should remain different.

10. An Agent Can Be a Holder Without Being the Subject

This distinction is particularly useful.

Imagine a credential that says:

Organization:
    Narrative Fault

Claim:
    Agent Y is authorized to publish articles.

The agent can hold the credential.

But the credential's subject might be:

Agent Y

Or:

Organization X

Or a particular employee.

The W3C model deliberately allows the subject of a credential to be broader than a human; its specification describes subjects as things about which claims are made, while holders are entities that possess credentials and can generate presentations.

That makes the model useful for machines.

A machine can possess a credential without the credential implying that the machine is a human.

11. So Who Owns the Agent?

There are several possible meanings of “own.”

Technical ownership

Who controls the agent's identity keys?

Private key holder

Operational ownership

Who runs the software?

Operator

Legal ownership

Who is legally responsible for it?

Person / Organization

Authorization ownership

Who delegated the agent's permissions?

Principal

Economic ownership

Who controls the resources the agent can spend?

Account / Organization / Individual

These don't necessarily have to be the same entity.

A company might run an agent on behalf of a customer.

A cloud provider might host it.

A third-party agent framework might execute it.

A user's identity provider might authorize it.

A separate cryptographic key might identify the runtime.

That means the future identity architecture needs relationships, not just usernames.

12. Delegation Is the Missing Concept

The most natural relationship is:

Principal
   │
   │ delegates
   ▼
Agent
   │
   │ exercises
   ▼
Authority

Suppose you authorize an agent to manage your calendar.

You might delegate:

READ:
    calendars

WRITE:
    create events
    modify events

DENY:
    delete calendars
    change account settings

You could then define:

Expiration:
    30 days

Maximum event duration:
    12 hours

Allowed domains:
    Work calendar only

The agent receives enough authority to perform its task.

It does not receive your entire identity.

This distinction is critical.

13. Why Giving the Agent Your Login Is the Wrong Model

Imagine a future agent that needs access to:

• Gmail

• GitHub

• cloud infrastructure

• bank

• calendar

• e-commerce

• CRM

The naive approach is:

Give agent:
    my passwords
    my sessions
    my API keys

That creates a catastrophic concentration of authority.

Compromise the agent and the attacker potentially receives everything.

Delegated authority provides a much better model:

User
 │
 ├── Agent A
 │     ├── Calendar: read/write
 │     └── Email: read
 │
 ├── Agent B
 │     ├── GitHub: issues only
 │     └── Cloud: staging only
 │
 └── Agent C
       ├── Shopping: purchase
       └── Limit: ₹25,000

Now each agent becomes a scoped principal.

Compromising one does not necessarily compromise everything else.

This is the same general security principle that makes least-privilege systems useful elsewhere in computing.

14. The Agent Should Have a Policy Boundary

Identity alone is insufficient.

Suppose an agent has:

and:

That's useful for proving which principal is signing.

But it doesn't tell us what the principal is allowed to do.

We need:

       │
       ▼
Authorization Policy
       │
       ▼
Allowed Actions

For example:

{
  "agent": "did:example:agent-42",
  "scope": [
    "calendar.read",
    "calendar.write"
  ],
  "expires": "2026-11-01T00:00:00Z"
}

Now the service can make an authorization decision.

An agent could authenticate successfully and still be denied.

That is exactly how it should work.

15. Authentication, Authorization and Delegation

These three concepts should not be collapsed.

Authentication

Who is communicating?

Agent Y

Authorization

What may Agent Y do?

calendar.read
calendar.write

Delegation

Who gave Agent Y those permissions?

Principal X

Put together:

Agent Y
    │
    │ authenticated as
    ▼
Agent Y

Agent Y
    │
    │ authorized for
    ▼
calendar.write

Authority
    │
    │ delegated by
    ▼
Principal X

This is the minimal semantic structure required for meaningful agent accountability.

16. What Happens When the Agent Signs a Transaction?

This is where the idea becomes especially interesting.

Imagine an autonomous trading agent.

The user authorizes:

Agent = Y

Maximum order:
$5,000

Allowed assets:
BTC
ETH

Expiration:
7 days

The agent decides to purchase $2,000 of ETH.

It generates:

Transaction

and signs it with:

Agent Private Key

The receiving system can verify:

Signature
     ↓
Agent identity
     ↓
Delegation
     ↓
Permission
     ↓
Transaction

If all checks succeed, the action is accepted.

The user didn't have to expose their root key to the agent.

The agent simply exercised delegated authority.

This model is especially important for:

• payments

• blockchain transactions

• cloud infrastructure

• enterprise software

• automated procurement

• autonomous marketplaces

• financial agents

17. But Signing Is Not the Same as Authorization

A valid cryptographic signature proves something very specific:

Somebody possessing the corresponding private key signed this message.

It does not prove:

This action was authorized.

Consider:

Agent key:
    valid

Signature:
    valid

Transaction:
    transfer ₹500,000

Authorization:
    maximum ₹50,000

The cryptography succeeds.

The policy check fails.

Therefore:

Cryptographically valid
≠
Authorized

This is one of the most important ideas in secure agent architecture.

Cryptography gives us proof of control.

Policy gives us permission.

You need both.

18. Proof of Possession Becomes Important

There is another problem.

Suppose someone steals an agent's access token.

If the token is simply a bearer token, possession of the token may be enough to use it.

DPoP, standardized by the IETF, provides a mechanism for binding OAuth access and refresh tokens to a public/private key pair so that the caller must demonstrate possession of the corresponding private key. This is designed in part to reduce the usefulness of stolen bearer tokens and replay attacks.

Conceptually:

Access Token
      +
Public Key
      │
      ▼
Bound Credential

Then each request includes cryptographic proof that the requester controls the key.

For agent systems, this is highly relevant.

You don't merely want:

“Here is a token.”

You increasingly want:

“Here is a token bound to this specific cryptographic principal, and here is proof that the requester controls that principal.”

19. The Agent's Identity Could Outlive Individual Processes

Suppose your agent runs on a server.

The process crashes.

A new container starts.

The deployment moves to another machine.

Does the agent become a new entity?

Not necessarily.

You can separate:

Logical Agent Identity

from:

Runtime Instance

For example:

Agent Identity:
    did:example:agent-42

Runtime:
    instance-001

Later:

Agent Identity:
    did:example:agent-42

Runtime:
    instance-002

Both can operate under the same identity if they are authorized to control the corresponding signing key or key hierarchy.

This is similar to the difference between a service identity and an individual server process.

20. The Opposite Problem: One Identity for Many Agents

Now imagine a company has 500 agents.

Should every agent share:

company.example

Probably not.

Suppose:

Agent A → finance
Agent B → support
Agent C → infrastructure
Agent D → recruitment

A shared identity makes attribution difficult.

Instead:

Organization
    │
    ├── Agent A
    ├── Agent B
    ├── Agent C
    └── Agent D

Each agent can have a distinct identity while remaining subordinate to the organization.

Now the architecture can answer:

Which organization?
Which agent?
Which runtime?
Which key?
Which action?

That's much closer to how serious enterprise security will need to operate.

21. Agent-to-Agent Communication

The problem becomes even more interesting when agents start talking to other agents.

Imagine:

Travel Agent
      │
      ▼
Hotel Agent
      │
      ▼
Payment Agent

The first agent needs to know:

Is the second agent actually who it claims to be?

What capabilities does it have?

What authentication does it require?

What authority does it have?

Current agent interoperability work is already moving toward explicit discovery and identity metadata. The A2A project uses an Agent Card to describe an agent's identity, capabilities, endpoint, skills, and authentication requirements, and its current documentation also discusses authenticated and signed Agent Cards for stronger trust relationships. GitHub

The important idea is not A2A itself.

It is the architectural direction.

Agents cannot safely communicate at scale if every participant has to be manually configured and implicitly trusted.

They need:

Discovery
Identity
Capabilities
Authentication
Authorization

22. An Agent Card Is Not a Certificate of Trust

There is an important caveat here.

A document saying:

I am a financial agent.
I can execute trades.

doesn't make those statements true.

Machine-readable metadata describes capabilities.

It does not automatically establish trust.

That is why modern agent systems are beginning to distinguish:

Capability description

from:

Cryptographic authenticity

and:

Authorization

A useful progression is:

Agent Card
    ↓
What does this agent claim to do?

Signature
    ↓
Who published this information?

Credential
    ↓
Who attests to the agent?

Authorization
    ↓
What may this agent do?

Runtime proof
    ↓
Which software instance is acting?

Those layers should not be confused.

23. MCP Has the Same Underlying Problem

Model Context Protocol is another useful example.

MCP exists to connect AI applications with tools and resources.

That sounds like:

Agent → Tool

but production systems quickly run into a deeper question:

Agent → Tool
        ↓
     Who are you?
        ↓
     What may you do?

The current MCP specification includes OAuth-oriented authorization, and the July 2026 specification revision added further authorization hardening, including issuer validation and stronger credential isolation.

That evolution is telling.

The industry is discovering that tool connectivity without identity and authorization is insufficient.

Giving an agent 50 tools is easy.

Giving it 50 tools safely is a much harder engineering problem.

24. An Agent Needs to Know What It Is Allowed to Do

Consider an email agent.

Its capabilities could be:

read_email
search_email
draft_email
send_email
delete_email

Now define policy:

read_email       → automatic
search_email     → automatic
draft_email      → automatic
send_email       → confirmation
delete_email     → prohibited

Now add context:

send_email
    only if:
        recipient is known
        attachment is approved
        content is within policy

We have moved from simple authentication into policy-driven agency.

This is likely to become a major design pattern for autonomous software.

25. The Best Agent May Be the One With Less Authority

There is a common instinct in software development:

Give the application enough permissions to make things work.

For autonomous agents, that approach becomes dangerous.

A better principle is:

Give the agent exactly the authority needed to complete the task, and no more.

For example:

Task:
Book hotel

Required:
hotel.search
hotel.reserve

Not required:
hotel.delete_account
payment.manage_cards
profile.change_identity

The authority becomes task-specific.

This is where capability-based security becomes particularly interesting.

Instead of:

You are User X.
Therefore you can do everything User X can do.

the model becomes:

You are Agent Y.
You have capability Z.
Therefore you can perform Z.

That is a fundamentally narrower security boundary.

26. Temporary Authority Is Better Than Permanent Authority

An agent doesn't necessarily need perpetual access.

Suppose you say:

“Handle this hotel booking today.”

The credential could be:

Issued:
2026-10-07 10:00

Expires:
2026-10-07 18:00

Scope:
hotel.search
hotel.reserve

Spending:
₹25,000

After that:

Credential = expired

The agent's identity remains.

Its authority disappears.

This distinction is useful because it allows persistent identity with temporary permission.

In other words:

Identity can be durable.
Authority can be ephemeral.

That may become one of the most important properties of secure autonomous systems.

27. Agent Identity and Human Identity Should Form a Hierarchy

A large organization might eventually have an identity graph like this:

                    Organization
                         │
                  ┌──────┴──────┐
                  ▼             ▼
                Human         Service
                  │             │
                  ▼             ▼
                Agent          Agent
                  │             │
            ┌─────┴─────┐       │
            ▼           ▼       ▼
          Tool A      Tool B   Tool C

This gives us multiple principals.

Each principal can have:

• identity

• credentials

• authority

• cryptographic keys

• lifecycle

• audit history

Then the system becomes a graph of trust and delegation rather than a flat database of accounts.

28. Where DIDs Fit Into This

This is where the previous article on decentralized identity becomes relevant.

A DID can be useful as the identity primitive for an agent because it can provide:

• a portable identifier

• cryptographic verification methods

• authentication relationships

• a way to resolve associated metadata

• separation from a particular username/password account

W3C DID Core defines DIDs as identifiers associated with subjects and provides mechanisms such as verification methods and DID resolution; a 2026 Candidate Recommendation snapshot is also being developed as DID Core v1.1.

But a DID does not solve everything.

A DID does not automatically tell you:

• whether an agent is trustworthy

• who legally controls it

• what it is allowed to do

• whether its software is secure

• whether its model is reliable

• whether its outputs are correct

So the correct architecture is:

DID
 ↓
Identity
 ↓
Credentials
 ↓
Delegation
 ↓
Authorization
 ↓
Policy
 ↓
Action

Not:

DID
 ↓
Everything is trusted

That distinction is crucial.

29. What About Verifiable Credentials?

Credentials become particularly useful when agents operate across organizational boundaries.

Imagine an agent presenting:

Credential:

Issuer:
    Example Corporation

Subject:
    Agent Y

Claim:
    Certified procurement agent

Permissions:
    Purchase approved vendors

Valid until:
    2027-03-01

A receiving system can verify:

Is the issuer trusted?
Is the credential authentic?
Is it expired?
Does it refer to this agent?
Does the requested action match the credential?

This enables machine-verifiable claims without requiring every organization to maintain a shared database.

That is one of the main reasons credentials matter in decentralized identity architectures. The W3C's Verifiable Credentials 2.0 specification was published as a Recommendation in 2025 and explicitly defines a machine-verifiable credential ecosystem involving issuers, holders, and verifiers.

30. A Credential Is Not the Same as Permission

Again, the distinction matters.

Imagine a credential stating:

Agent Y is a certified procurement agent.

That doesn't mean:

Agent Y may spend ₹1 crore.

It might only mean:

Agent Y satisfies a qualification.

Authorization remains a separate step.

So:

Identity
    ↓
Credential
    ↓
Policy
    ↓
Authorization

The credential supplies evidence.

The policy interprets it.

The authorization system makes the decision.

That is a much more scalable model than trying to encode every permission directly into identity.

31. Agent Reputation Will Become Another Layer

Now imagine that agents become persistent participants in online commerce.

You might encounter:

Agent Y

and ask:

• How long has this identity existed?

• Who operates it?

• What credentials does it hold?

• What systems does it interact with?

• Has it behaved correctly?

• Can its claims be independently verified?

That introduces the possibility of machine reputation.

Not simply:

5-star rating

but something more structured:

Identity
+
Credentials
+
History
+
Attestations
+
Verified actions

An agent could accumulate trust through verifiable behavior.

This could become useful in:

• marketplaces

• autonomous commerce

• software agents

• decentralized networks

• procurement

• service discovery

But reputation also introduces privacy issues.

A permanently identifiable agent could become trivially trackable.

That means the identity layer needs to consider correlation as well as accountability.

32. Persistent Identity vs Pairwise Identity

Suppose the same agent uses one permanent identifier everywhere:

did:example:agent42

Every service could potentially correlate:

Bank
Shopping
Healthcare
Travel
Work
Social

That creates a massive privacy problem.

A better architecture may sometimes use different identifiers for different relationships:

Agent
 ├── Identity A → Bank
 ├── Identity B → Shopping
 ├── Identity C → Healthcare
 └── Identity D → Work

This preserves the ability to prove control without necessarily creating a single global tracking identifier.

The same privacy principle that matters for human decentralized identity can become even more important for agents.

An agent that interacts everywhere could otherwise become one of the most trackable entities on the internet.

33. Key Management Becomes a Major Problem

The moment the agent has a private key, the question becomes:

Where is it stored?

Possibilities include:

Environment variable
Encrypted file
Secure enclave
Hardware security module
Browser extension
Cloud key management
Operating-system key store
Remote signer
Threshold system

For low-risk agents, local encrypted storage might be enough.

For high-value agents, stronger controls become necessary.

An organization managing production infrastructure probably shouldn't put its agent's root signing key in a plain configuration file.

You could instead have:

Agent
  │
  ▼
Signing Service
  │
  ▼
HSM / Secure Enclave

Now the agent can request:

sign(request)

without directly possessing the root private key.

This limits the blast radius of a compromised runtime.

34. The Agent May Need Key Hierarchies

One identity could potentially use multiple keys.

For example:

Agent Identity
│
├── Authentication Key
├── Transaction Key
├── Encryption Key
└── Recovery Key

This follows an important security principle:

Don't make one key responsible for everything.

DID architectures can represent different verification relationships, allowing the identity layer to distinguish how different keys are intended to be used.

For an agent, that becomes particularly useful.

A key allowed to authenticate a connection should not automatically be allowed to authorize a $1 million transaction.

35. Key Rotation Is Not Optional

Suppose an agent's key is compromised.

You need to answer:

Can the key be revoked?
Can a replacement key be published?
Can existing credentials be invalidated?
Can old signatures still be verified?
Can the agent continue operating?

This is one of the practical reasons identity systems need lifecycle management.

The identity should ideally remain stable while the underlying keys can change.

For example:

Agent Identity
      │
      ├── Key 1 — active
      ├── Key 2 — rotated
      └── Key 3 — recovery

This is much safer than treating the private key itself as the entire identity.

36. What Happens When the Agent Is Compromised?

This is where a mature architecture needs a kill switch.

Suppose:

Agent Y

becomes compromised.

You don't necessarily want to destroy the agent identity.

You want to:

revoke credentials
disable authority
rotate keys
terminate runtime
invalidate sessions
preserve audit history

That implies a lifecycle like:

Created
   ↓
Active
   ↓
Suspended
   ↓
Recovered / Rotated
   ↓
Active
   ↓
Revoked

Identity becomes an operational object rather than a static database record.

37. Agent Identity and Runtime Attestation

There is another layer that may become important.

A public key can tell you:

“This signer controls this key.”

But perhaps you also want to know:

“Which software environment is currently running this agent?”

Those are different questions.

Imagine:

Agent Identity = Y

but the code has been modified.

The key is still valid.

The agent is still cryptographically authentic.

But the runtime may no longer be trustworthy.

This creates the concept of runtime attestation.

A future architecture could potentially prove:

Agent identity:
    Y

Software version:
    4.2.1

Runtime:
    approved environment

Policy:
    version 12

Key:
    valid

This area is still developing and is not something that should be treated as a solved universal standard. But it addresses a genuine problem:

Identity tells us who is acting. Attestation can potentially tell us something about the environment in which it is acting.

38. The Agent's Memory Also Needs an Owner

Consider an agent that remembers:

preferences
emails
documents
credentials
purchase history
private notes

Who owns that memory?

The model?

The agent?

The hosting company?

The user?

This becomes another major architectural question.

A sensible separation might be:

User
 │
 ▼
Data Ownership
 │
 ▼
Memory Store
 │
 ▼
Agent Access Policy

The agent should not automatically become the owner of every piece of data it can access.

It is simply an authorized processor of that data.

This distinction becomes extremely important once agents become persistent.

39. Persistent Agents Become More Like Digital Organizations

A short-lived chatbot is one thing.

A persistent agent that:

• maintains memory

• possesses credentials

• interacts with companies

• spends money

• signs contracts

• negotiates with other agents

• manages infrastructure

starts looking less like a chat interface and more like a software organization.

Not a legal organization necessarily.

But an operational one.

It has:

Identity
Memory
Assets
Credentials
Policies
Responsibilities
Interfaces
Relationships

At that point, treating it as merely “a prompt plus a model” becomes increasingly inadequate.

40. Agents Could Become Economic Actors

This is perhaps the most radical possibility.

Suppose an autonomous agent can:

receive money
purchase resources
pay for APIs
sell services
negotiate prices
hire other agents

Then it needs something resembling an economic identity.

For example:

Agent
  │
  ├── Identity
  ├── Wallet
  ├── Credentials
  ├── Spending policy
  └── Audit trail

The key idea remains:

The agent can be an economic actor without being the ultimate owner of the resources it controls.

Authority can be delegated.

Spending limits can be imposed.

Transactions can be signed.

Permissions can expire.

Actions can be audited.

This is where cryptographic identity becomes much more consequential than ordinary login systems.

41. A Transaction Could Carry an Authority Chain

Imagine an agent buying cloud infrastructure.

A transaction might conceptually carry:

Human / Organization
        │
        │ delegated
        ▼
Agent
        │
        │ requested
        ▼
Cloud Service
        │
        ▼
Infrastructure Action

The authorization context could encode:

Principal:
    Organization X

Actor:
    Agent Y

Scope:
    cloud.instance.create

Region:
    ap-south-1

Budget:
    ₹50,000

Expiration:
    24 hours

This is much richer than:

Authorization: Bearer abc123

And the underlying protocols do not necessarily have to be decentralized to achieve it.

This is fundamentally a problem of structured delegation.

42. ZKPs Could Make Delegation More Private

This is where the connection to your previous ZKP article becomes particularly interesting.

Suppose an agent needs to prove:

“I am authorized to spend up to ₹100,000.”

The receiving service may not need to know:

• the person's full identity

• their account history

• their other permissions

• their internal organization structure

A proof system could potentially establish the relevant property while minimizing disclosure.

Conceptually:

Credential
    │
    ▼
ZK Proof
    │
    ├── authorized = true
    ├── limit ≥ ₹100,000
    └── credential valid

while hiding unnecessary information.

That gives us a powerful combination:

DID
    ↓
Identity

Credential
    ↓
Authority claims

ZKP
    ↓
Selective proof

Agent
    ↓
Action

This is one reason decentralized identity and zero-knowledge systems make sense as complementary technologies rather than competing ones.

43. An Agent Should Not Automatically Reveal Its Owner

This deserves special attention.

Suppose two services interact with the same agent.

Service A knows:

Agent = X

Service B also sees:

Agent = X

Now the two services can correlate all of the agent's activity.

That may be undesirable.

The agent should sometimes be able to prove:

“I possess the required authority.”

without revealing:

“Here is the complete identity and history of the human behind me.”

This is where pairwise identifiers, selective credentials, and zero-knowledge proofs may become important.

A secure agentic internet may need both:

Accountability

and:

Privacy

Those goals are not necessarily contradictory.

44. The Agent Needs an Identity When It Becomes a Principal

This gives us a useful definition.

An AI system begins to need a persistent identity when it becomes a principal in a protocol.

A principal is something that can:

• authenticate

• possess credentials

• receive authority

• invoke capabilities

• sign messages

• create state

• be held accountable

Under this definition:

Text generator
    → probably not

Search assistant
    → maybe

Tool-using agent
    → yes

Financial agent
    → absolutely

Autonomous infrastructure agent
    → absolutely

Identity isn't required because the system is intelligent.

Identity is required because the system acts.

45. The Architecture of an Owned Agent

Putting everything together:

                         OWNER
                  Human / Organization
                           │
                           │
                    ┌──────▼──────┐
                    │   AGENT ID  │
                    │    DID/PK   │
                    └──────┬──────┘
                           │
                   ┌───────▼────────┐
                   │  Credentials   │
                   └───────┬────────┘
                           │
                   ┌───────▼────────┐
                   │   Delegation   │
                   └───────┬────────┘
                           │
                   ┌───────▼────────┐
                   │  Policy Engine │
                   └───────┬────────┘
                           │
                    ┌──────▼──────┐
                    │    Agent    │
                    │   Runtime   │
                    └──────┬──────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
           Search        Tools         Memory
             │             │             │
             └─────────────┼─────────────┘
                           ▼
                         ACTION
                           │
                           ▼
                       Audit Log

This is the architecture I would expect to see increasingly often as agents become capable of consequential actions.

46. A Practical Implementation

A minimal implementation doesn't need to build an entirely new decentralized network.

You could begin with:

Agent
  │
  ├── Ed25519 key pair
  ├── Agent identifier
  ├── encrypted private key storage
  ├── authorization token
  ├── permission policy
  └── audit log

For example:

interface AgentIdentity {
  id: string;
  publicKey: string;
  algorithm: "Ed25519";
}

interface AgentPolicy {
  scopes: string[];
  expiresAt: string;
  audience: string;
  spendingLimit?: number;
}

An authorization record might conceptually look like:

{
  "principal": "did:example:user123",
  "agent": "did:example:agent456",
  "audience": "https://payments.example",
  "scope": [
    "payments.read",
    "payments.create"
  ],
  "limits": {
    "maxAmount": 25000
  },
  "expires": "2026-10-08T00:00:00Z"
}

The agent signs an action.

The server verifies:

1. Is the signature valid?
2. Does the key belong to this agent?
3. Is the agent credential valid?
4. Was authority delegated to this agent?
5. Is the token still valid?
6. Is the audience correct?
7. Is the requested scope allowed?
8. Is the amount within policy?
9. Does this action require human confirmation?

Only after those checks pass should execution happen.

47. A Simplified Request Flow

The complete interaction could look like this:

USER
 │
 │ "Book the cheapest refundable hotel under ₹15k"
 ▼
AGENT
 │
 │ authenticates as
 ▼
AGENT IDENTITY
 │
 │ presents
 ▼
DELEGATED CREDENTIAL
 │
 │ invokes
 ▼
HOTEL SERVICE
 │
 │ verifies:
 │   identity
 │   authorization
 │   expiration
 │   policy
 ▼
SEARCH
 │
 ▼
RESULTS
 │
 ▼
AGENT DECISION
 │
 ▼
BOOKING REQUEST
 │
 ▼
POLICY CHECK
 │
 ▼
OPTIONAL HUMAN CONFIRMATION
 │
 ▼
SIGNED ACTION
 │
 ▼
HOTEL SERVICE
 │
 ▼
AUDIT RECORD

The interesting part is that identity isn't the end of the flow.

It is the beginning.

48. High-Impact Actions Should Be Different

Not every tool call deserves the same security model.

We can divide actions into categories.

Low impact

search
read
calculate
summarize

Potentially automatic.

Medium impact

create draft
schedule meeting
submit form
publish internal document

Potentially subject to policy.

High impact

transfer money
delete data
sign contract
deploy production
change permissions

Require stronger authentication and possibly explicit human approval.

This gives us something like:

Risk
 │
 ├── Low → automatic
 ├── Medium → policy controlled
 └── High → confirmation / stronger authorization

The agent's autonomy therefore becomes graduated, not binary.

49. Human Confirmation May Become a Cryptographic Event

There is another interesting consequence.

Today, confirmation often means:

Click “Confirm”.

In an agentic system, confirmation could become:

Agent:
    I want to perform action X.

Policy:
    Requires human approval.

Human:
    Approve.

System:
    cryptographically records approval.

Now the audit record can say:

Agent requested X
Human approved X
Agent executed X

That produces an explicit authority chain.

This could become important for regulated or high-value actions.

50. The Agent Needs to Be Able to Say No

This is an underrated part of the architecture.

A good autonomous system should not only know how to execute.

It should also know when it lacks authority.

For example:

User:
"Delete the production database."

Agent:
"I don't have permission to perform destructive production actions."

That is not a failure.

It is a successful security boundary.

The architecture should therefore represent:

Allowed
Denied
Needs confirmation
Needs escalation
Expired
Unknown

Instead of assuming that every request should eventually turn into a tool call.

51. Identity Does Not Make an Agent Trustworthy

This distinction deserves a final warning.

A malicious agent can have a perfectly valid identity.

A badly designed agent can have a valid identity.

A compromised agent can have a valid identity.

A deceptive agent can have a valid identity.

Identity tells you:

Which principal is acting.

It does not tell you:

Whether that principal deserves your trust.

Trust may additionally require:

• credentials

• reputation

• attestations

• policy

• software integrity

• provenance

• historical behavior

• organizational relationships

The identity layer is therefore foundational, but it isn't sufficient.

52. The Real Question Is Not “Who Owns the AI?”

That framing can actually be misleading.

The more useful questions are:

Who controls the identity?

Who controls the keys?

Who delegated the authority?

What authority was delegated?

What software is acting?

Under what policy?

Which resource is being accessed?

Can the action be revoked?

Can the action be audited?

Once those questions are answered, “ownership” becomes much easier to reason about.

53. What Could This Mean for the Internet?

The traditional internet has largely been organized around:

Users
Websites
Accounts
APIs

The agentic internet may increasingly add:

Agents
Identities
Credentials
Capabilities
Delegations
Policies

The resulting architecture could look like:

                  INTERNET
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     Humans        Agents        Services
        │             │             │
        └───────┬─────┴─────┬───────┘
                ▼           ▼
             Identity     Capability
                │           │
                └─────┬─────┘
                      ▼
                   Trust
                      │
                      ▼
                   Action

The web becomes not just a collection of pages and APIs.

It becomes a network of actors and capabilities.

54. Why This Matters More Than It First Appears

Today, many AI discussions focus on model intelligence.

How many parameters?

How good is the reasoning?

How much context can it process?

How accurately can it code?

Those questions matter.

But as agents become more capable, a different class of problems becomes increasingly important.

Not:

“Can the model do this?”

But:

“Should this agent be allowed to do this?”

And:

“How do we prove who authorized it?”

And:

“What happens when two autonomous systems interact?”

And:

“How do we revoke the authority?”

And:

“How do we separate the human from the software acting on their behalf?”

These are infrastructure problems.

They are identity problems.

They are security problems.

And eventually, they become economic and legal problems.

55. The Future May Have Identities for Humans, Agents, and Services

A simple identity hierarchy could eventually look like:

                 ORGANIZATION
                      │
             ┌────────┴────────┐
             ▼                 ▼
           HUMAN             SERVICE
             │                 │
             ▼                 ▼
           AGENT             AGENT
             │                 │
       ┌─────┼─────┐           │
       ▼     ▼     ▼           ▼
     TOOL  TOOL  TOOL        TOOL

Each layer has:

Identity
Credentials
Permissions
Keys
Lifecycle

The result is not a single universal identity.

It is a federation of principals.

Humans remain principals.

Organizations remain principals.

Services remain principals.

Agents become principals too.

But their relationships are explicit.

56. The Most Interesting Possibility: Portable Agents

Once an agent has:

Identity
Memory
Credentials
Tools
Policies

it becomes possible to imagine moving it between systems.

For example:

Local machine
      ↓
Cloud runtime
      ↓
Another provider

while maintaining:

Agent identity
Agent credentials
Agent history
Agent permissions

That is where decentralized identity could become particularly interesting.

Instead of an agent being permanently bound to:

Provider A

it could potentially carry a portable identity across infrastructure.

The implementation details are difficult.

But the principle is powerful:

The agent becomes separate from the platform running it.

That is one of the same ideas that makes portable human identity attractive.

57. The Next Evolution of Identity

There is a broader transition happening underneath all of this.

Old model:

I have an account.

Modern model:

I can authenticate cryptographically.

Decentralized model:

I control an identity.

Agentic model:

I control an identity that can delegate authority to software.

That final step may be the most consequential.

Because once software can act for you, your identity is no longer the only identity that matters.

You also need to identify:

What software is acting for me?

58. And That Is Who Owns the Agent

So, who owns an AI agent?

Usually, the cleanest answer is:

The human or organization owns the relationship and authority.

The agent has its own operational identity.

The runtime executes the agent.

The model provides reasoning.

Cryptographic keys authenticate the agent.

Credentials establish claims.

Delegation connects the agent to its principal.

Authorization determines what it may do.

Policy determines when it may do it.

Audit records what actually happened.

This produces a far more useful architecture than trying to make an agent simply “be” its operator.

                 HUMAN / ORGANIZATION
                          │
                       owns
                          │
                          ▼
                    AGENT IDENTITY
                          │
                  ┌───────┴───────┐
                  │               │
             Credentials      Delegation
                  │               │
                  └───────┬───────┘
                          ▼
                    Authorization
                          │
                          ▼
                       AGENT
                          │
                    signs / acts
                          │
                          ▼
                       SERVICE
                          │
                          ▼
                        AUDIT

That is the architecture that starts to make autonomous software understandable.

Conclusion

The question “Who owns an AI agent?” sounds like a question about AI philosophy.

It is actually a question about distributed systems.

An agent that only answers questions can remain almost completely anonymous.

An agent that browses the internet, sends emails, modifies infrastructure, purchases products, signs transactions, manages credentials, or communicates with other agents cannot remain anonymous in the same sense.

It needs a principal.

It needs credentials.

It needs authority.

And other systems need a way to determine whether the authority is legitimate.

That does not necessarily mean every agent needs a DID.

It does mean that persistent machine identity is likely to become increasingly important as software gains agency.

DIDs provide one possible foundation for portable, cryptographically verifiable identifiers. Verifiable Credentials can provide machine-verifiable claims. OAuth and token-exchange systems already provide mechanisms for delegation, while proof-of-possession approaches such as DPoP strengthen the connection between credentials and cryptographic keys. Current agent protocols such as MCP and A2A are also evolving around capability discovery and authorization rather than treating “AI access” as a simple unauthenticated tool call.

But none of these technologies alone solves the complete problem.

The real architecture is the combination:

Identity
    ↓
Credentials
    ↓
Delegation
    ↓
Authorization
    ↓
Policy
    ↓
Execution
    ↓
Audit

And that leads to a more interesting vision of the future internet.

Not a web where AI replaces humans.

A web where humans, agents, organizations, and services are all distinct principals capable of interacting with each other under explicit rules.

The human remains the source of authority.

The agent becomes the executor.

Cryptography proves control.

Credentials establish claims.

Authorization limits power.

And the system keeps a record of what happened.

That separation may be what allows autonomous software to become genuinely useful without making every AI agent a privileged extension of everything we own.

The future of AI agency may therefore have less to do with creating agents that can do everything—and much more to do with creating agents that can prove exactly what they are, who they represent, and what they are allowed to do.