Delegated identity

Whose Identity Should an AI Agent Use When Acting for a Human?

The system should show both who authorised the work and which non-human actor actually performed it.

Direct answer

An AI agent acting on behalf of a human should generally be distinguishable from the human principal rather than simply inheriting the human’s identity. The system should preserve the relationship between the human principal, the agent identity, the delegated authority, the action performed and the resulting audit record.

Two facts must remain visible

When a person asks an agent to perform work, two facts are simultaneously true: the person is the source of authority, and the agent is the actor that selected or executed the operation. A system that records only the person loses execution context. A system that records only the agent loses the source of authority.

The stronger model keeps both. The human is the principal. The agent is a delegated non-human actor. The permission, task or token connecting them explains why the agent was allowed to act.

Delegated identity model: “Agent A acted, using authority granted by Human H, for Task T, within Scope S.”

Why simple impersonation is risky

If an agent signs in exactly as the human, the service may be unable to tell whether a person clicked a button or an automated process made the decision. This weakens investigation, policy enforcement and user trust. It may also give the agent every permission the user has, even when the task needs only one narrow capability.

Long-lived shared credentials create further problems. They are difficult to rotate without affecting the user, difficult to revoke for the agent alone and easy to reuse outside the original task. The system also loses a clear boundary between interactive human access and automated access.

A better delegation pattern

The agent should authenticate as a recognised non-human actor. The user or organisation should then grant it a defined authority, ideally through a scoped and time-limited mechanism. The receiving service can evaluate both the agent and the delegation instead of treating one identity as a substitute for the other.

  • Principal: the human or organisation that has the original authority.
  • Agent: the non-human identity that performs the work.
  • Delegation: the explicit relationship that grants the agent a limited power.
  • Context: the task, resource, duration and conditions attached to that power.
  • Evidence: the record connecting the request, decision, action and outcome.

Where a target service only supports user-context access, short-lived delegated tokens can still preserve more context than sharing a password or long-lived session. The exact mechanism varies, but the semantic distinction should remain.

When the agent may act inside a user session

Some desktop and browser tasks necessarily occur inside a session already opened by the user. That does not mean the agent must disappear into the user’s identity. The local runtime can still identify the agent, record the initiating task, require approval and preserve an audit trail even when the remote service sees only the user session.

This is a pragmatic fallback rather than the ideal identity model. As services become more agent-aware, they should expose ways to receive both the human principal and the delegated actor.

Identity does not settle accountability by itself

Technical records cannot decide every legal or organisational question. They can, however, prevent the facts from being blurred. A reviewer should be able to see whether the user directly selected the action, approved a proposal, established a standing policy or merely created the agent long before the event.

Architecture principle: never force a reviewer to choose between knowing who authorised an action and knowing what actually executed it.

How this relates to Smallsoft Identity

Smallsoft’s identity work focuses on keeping principals, agent identities, delegated authority and audit evidence connected. This allows agent access to be limited and revoked without erasing the human relationship behind it.

Explore Smallsoft Identity

Frequently asked questions

Should an AI agent ever use a human user’s credentials?

Directly sharing long-lived credentials is usually a poor design. Where a service only supports user-context access, prefer scoped delegation or short-lived tokens that preserve as much agent context as possible.

Who is accountable when an AI agent acts?

That depends on the legal and organisational context. The technical system should preserve who authorised the action, which agent executed it, what authority applied and what outcome followed.

Can a service show both the user and the agent?

Yes. A service can evaluate the agent as the acting identity while retaining the human principal and delegation as related context.