The agent needs a principal

Giving an agent an account solves the smallest part of the identity problem. The account may have a name, a credential, a role, and a recognizable entry in an audit log. None of those facts explains why the agent was allowed to act in this instance. A durable security model needs the missing relationship: the person or institution whose authority the agent is exercising.

This is the direction of the 2026 NIST concept work on identity and authorization for software agents. The problem is larger than authenticating a workload. Agents act with varying degrees of autonomy, use services across administrative boundaries, and may delegate work to other agents. Identity must connect those acts to authority that can be understood, limited, and withdrawn.

The principal is not always the person who clicked the button. A staff member may initiate a process on behalf of a company. The company may possess the legal authority, while the staff member has a narrower operational role. A service owner may approve the agent class, while a case owner approves one consequential action. Good design does not flatten those relationships into a single user identifier. It records the chain that makes the act legitimate.

Authentication is not delegation

Authentication answers whether the caller is the agent represented by a credential. Delegation answers why that agent may invoke this capability now. An authenticated agent can still be unauthorized, overbroad, stale, or acting outside the task its principal assigned. When the two questions are collapsed, possession of a credential begins to look like permission to improvise.

Human accounts already suffer from this confusion. Long-lived tokens accumulate privileges, service identities become shared infrastructure, and logs show which technical account acted without showing which business purpose was served. Agents magnify the weakness because they can choose and sequence actions. A credential that was tolerable for a deterministic job may be dangerously expressive when attached to a system that plans.

An agent should not merely prove what it is; it should carry evidence of whose authority it is spending.

That evidence should be task-bound. It can name the principal, objective, authorized resources, permitted operations, consequence ceiling, expiration, and conditions for escalation. The result resembles a mandate more than a conventional role. A role says what an identity generally may do. A mandate says what this agent may do for this principal in this episode.

Time matters because delegated authority decays. A token issued for a month-long project should not silently survive the project. Approval to prepare a draft should not become approval to publish it after the underlying facts change. An agent that resumes from stored state should have to prove that the mandate remains live, not merely that its old credential still validates.

Authority must survive delegation

Multi-agent systems make the chain explicit. The NIST AI Agent Standards Initiative places agent identity and secure interoperability in the same program because authority must remain intelligible across these handoffs. An orchestration agent asks a research agent to collect sources, which asks a browser service to retrieve a page. Each handoff can preserve the original limits or quietly expand them.

The safer rule is attenuation: a downstream mandate can be narrower but never broader than the authority from which it derives. It should also retain provenance. The final log should show not only that the browser fetched a resource, but that it did so for a research task delegated by a named agent acting for an identified principal under a still-valid purpose.

This is where agent identity meets service design. APIs need a way to receive and evaluate scoped delegation claims. Policy engines need to consider resource, action, purpose, and consequence together. Revocation needs to propagate. A human who cancels the task should not have to discover every subordinate credential the system minted along the way.

Accountability also requires separating the principal’s intent from the agent’s discretion. The principal may authorize a goal without choosing every step. If the agent selects an unusual tool, crosses a jurisdiction, or incurs a new class of consequence, the record should identify that as the agent’s choice under delegated authority. Otherwise every machine judgment is falsely attributed to the human who initiated the process.

Design for the answer after the incident

After a disputed act, investigators will ask who authorized it. A system built around technical identities often answers with a service account. That is evidence about authentication, not responsibility. A better record reconstructs the mandate: who established it, which organizational power they held, what outcome they requested, which boundaries applied, what the agent selected, and where a fresh approval should have occurred.

This does not mean attaching a human name to every background operation. Some agents act for an institutional service rather than an individual. The point is still to identify the principal accurately. If the principal is a company process, the system should name the owning function, controlling policy, current operator, and escalation authority instead of inventing a person who supposedly made every choice.

The practical test is simple. Disable the agent account and ask whether the organization can still explain the authority behind its last ten consequential acts. If the answer depends entirely on the credential that happened to be used, identity has been implemented without delegation. The system knows the actor but not the legitimacy of the act.

Agents need identities because services must distinguish them. They need principals because institutions must govern them. The first prevents impersonation. The second prevents power from becoming ownerless. As agents move across tools and organizations, the principal is the thread that keeps authority attached to purpose.

— Dispatches · Summit Cognitive