From Borrowed Credentials to Accountable Agents

The question at the center of this series is whether an AI agent should act through a human’s identity or remain identifiable as its own actor. The answer supported by the supplied material is clear but bounded: an agent needs a distinct identity when it can reason, delegate, and cause actions across enterprise resources, while the authority it exercises should still come from a human or organizational permission through an explicit, limited, and current delegation. This final synthesis turns that principle into a design judgment without treating a draft proposal or a research preprint as a finished standard.

Identity keeps authority accountable

A borrowed human credential solves one narrow problem: it lets an operation pass through an access system. It does not preserve the distinction between the person who initiated a task and the software actor that chose tools, retrieved data, delegated work, or caused a side effect. Once an agent can operate across several resources and make decisions at runtime, that distinction is not administrative decoration. It is the information needed to decide, explain, and later withdraw authority.

A distinct agent identity does not mean that the agent becomes an independent owner of the human’s permissions. It means that the system can identify the actor while evaluating the authority separately. Authentication can establish that the actor is a genuine or expected workload. Lifecycle controls can issue, update, or revoke its identity and keys. The authorization decision can then ask whether this named agent may exercise a bounded part of a human permission in the current context.

That separation is the answer to the title. The human may remain the root of authority, but the human should not be substituted for the actor. If a document-reading agent accesses a project file, the record should identify that agent. If a coding agent later writes to a repository, the record should identify the coding agent and the distinct delegation path that permits the write. If the action is denied, the system should be able to say whether the identity failed, the human permission was absent, the delegation did not cover the action, or the session was outside its scope.

The envelope model connects those facts. An agent receives a modeled permission only when three witnesses meet: a human or organization holds the underlying permission; a valid delegation chain connects that authority to the named agent; and the agent has a current session or scope compatible with the resource. A time, location, device, approval, or other condition may narrow the result further. The envelope is therefore not a role copied from a user. It is a live intersection that can shrink when any relationship changes.

This model also explains why identity and authorization must remain separate even when a single service handles both. A workload identity can be valid while its delegation has expired. A user can have permission while the agent is operating in the wrong project. A session can be active while the requested resource falls outside the human permission at the root. A single broad credential hides these differences; distinct identity makes them available for policy and audit.

The result is not unlimited autonomy. It is accountable autonomy: an agent may act without a human approving every routine step, but its actions remain tied to a recognizable actor, a human-rooted authority path, a bounded resource envelope, and a mediated decision point. The system does not have to predict every action in advance. It does have to prevent reasoning, message passing, or possession of a credential from silently becoming broader authority.

Preserve the useful parts of existing access systems

Giving agents distinct identities does not require discarding familiar identity and access infrastructure.