Why AI Agents Cannot Borrow Our Identity
The subject of this series is enterprise software and AI agents that can make decisions and take actions with limited human supervision. This opening chapter focuses on the first question a trustworthy design must answer: why should an agent be identifiable as itself instead of simply using a human credential? The answer matters because readers need a way to judge whether an agent is merely connected to a system or is acting with authority that can be explained, limited, and withdrawn.
From answering to acting
A conventional software service can already automate a great deal. It can call an API, move data between systems, or execute a workflow. An agentic system adds a different kind of uncertainty: it receives an instruction, gathers more context from tools or data sources, reasons over what it finds, decides what to do next, and may repeat that process before returning a result or taking an action. NIST’s proposed work describes this as an architecture in which instructions lead to dynamic context acquisition, processing, possible action, and a response. The research framework makes the same point in a different vocabulary: an agent can plan, use tools, discover other agents, and delegate work while pursuing a goal.
That sequence changes the security boundary. The system is not only answering a question inside one application. It may read a document, consult a service, create a ticket, update a record, or ask another agent to perform a specialized task. Each step can involve a different resource and a different permission model. The agent’s next action is not necessarily a fixed operation chosen when the workflow was designed; it can depend on retrieved content, tool output, and changing context.
Consider an enterprise assistant asked to prepare a recommendation. It might retrieve internal documents, compare information from several systems, and ask a second agent to format or verify the result. If the assistant uses the employee’s broad credential throughout that process, the resulting audit trail may show only the employee. It may be impossible to tell which software actor read which source, which actor initiated a change, whether the action was still within the employee’s intended task, or how to stop one component without invalidating everything else.
The issue is not that every agent is malicious. It is that an agent’s behavior is not fully specified in advance, while its access can cross boundaries that were designed for more predictable actors. NIST therefore treats identification, authentication, authorization, delegation, logging, transparency, and data-flow tracking as separate areas of concern. The research paper likewise argues that least privilege must be enforced by policy at the action boundary rather than assumed from the model’s behavior.
The consequences vary with the work the agent performs. NIST’s possible enterprise uses include everyday assistance such as managing calendars or preparing policy documents, security agents that analyze sensitive information and recommend or take defensive actions, and development agents that work inside software delivery pipelines. These are not interchangeable permission problems. A calendar assistant may need delegated access to several scheduling and communication systems. A security agent may handle data whose exposure is itself consequential. A development agent may reach repositories or deployment environments where an incorrect action can change production software. In each case, the organization needs to know not only which employee initiated a task, but which non-human actor crossed which boundary and under what authority.
This is also why identity cannot be reduced to a label attached after the fact. If one broad user credential is reused everywhere, the system may be able to reconstruct that the employee was involved, but not the precise chain of responsibility. A separate agent identity creates a place to attach its authentication state, active session, delegated scope, and action record. It does not make the agent trustworthy by itself. It makes the questions of trust and permission answerable at the right level of detail.
The important boundary in this flow is between reasoning and action. An agent may propose a step because a document, tool response, or model inference suggested it. That proposal is not yet authority. The system still needs to decide whether this particular actor may perform this particular operation on this particular resource under the current conditions.
A name is not an authorization
“Identity” is often used as if it answered every access question. It does not. Identification establishes which actor a system is dealing with. Authentication supplies evidence that the actor is genuine or that its workload is running in an expected environment. Authorization decides whether that actor may perform a requested action. Those decisions are related, but they are not interchangeable.
NIST’s concept paper exposes the distinction by asking several different questions. What metadata should an AI agent have? Should its identity be fixed or depend partly on the task? Should it be tied to hardware, software, or an organizational boundary? What counts as strong authentication? How should keys be issued, updated, and revoked? And after the actor is known, how should zero-trust principles, least privilege, delegation, human approval, and proof of authority govern an action?
Those questions describe a lifecycle, not a single login. An agent may have a persistent identity that identifies the deployed workload, a short-lived session that identifies its current execution, and a delegation that says what it may do for a user. A key or token can help authenticate the actor or carry trusted facts, but it should not be mistaken for a universal answer to what the actor may do next.
The distinction becomes especially important when an agent acts “on behalf of” a person. The person may be the source of the original permission, but the agent is the actor that actually calls the tool. If the two are collapsed into one principal, accountability becomes ambiguous. If they are separated, a policy can ask both questions: did this human or organization have the underlying right, and was this named agent allowed to exercise a bounded part of it at this moment?
This is the central reason an agent should not borrow a human identity as its only identity. Borrowing a credential can make an action technically possible, but it hides the relationship that must be governed. It does not show whether the permission was delegated for a particular purpose, whether a second agent received a narrower share, whether the delegation expired, or whether the active execution was operating inside an approved scope.
The separation also avoids the opposite mistake: treating an agent as a generic service and losing the fact that its behavior is adaptive. A deterministic service may have a stable contract that maps a request to a known class of operations. An agent can select tools and sequence actions in response to information encountered at runtime. That does not mean it deserves unlimited discretion. It means the policy must preserve the agent as a recognizable principal while checking its authority at the point where a side effect is requested.
The control question is who may do what, now
The practical question for this series is therefore not simply, “Can the agent authenticate?” It is: Which named agent is asking, through whose authority, for which resource or action, under which current conditions? This formulation keeps the primary subject—the enterprise agent—at the center while connecting it to the human, the resource, and the policy that governs the relationship.
NIST’s proposed project is deliberately focused on this enterprise setting. It is a February 2026 draft concept paper seeking stakeholder input on use cases, standards, technical feasibility, and the value of a possible demonstration. Its initial scope emphasizes environments where organizations can maintain greater control and visibility over agents and the systems they access; external agents from untrusted sources are not part of the initial effort. That boundary matters. The document is not announcing a finished standard, and it does not claim that one protocol has already solved agent authorization.
The accompanying research preprint offers a more formal direction for the problem. It treats agents as first-class principals and treats delegation as a runtime relationship rather than only a static consent token. In that model, an agent’s access depends on a chain that begins with a human permission, is narrowed by delegation and scope, and is checked against the agent’s active session and context. The model is designed to work alongside existing authorization policies rather than erase them.
That direction gives us a way to examine the question without making a false choice between familiar identity infrastructure and new agent governance. Standards such as OAuth, OpenID Connect, SPIFFE/SPIRE, SCIM, and NGAC may contribute authentication, workload identity, lifecycle management, or policy capabilities. But the system still needs a runtime account of how authority travels from a human to an agent, how it can be narrowed for another agent, and how the result can be audited or revoked.
The rest of the series follows that relationship. It will first separate the layers of identity and permission, then examine why delegation needs explicit boundaries when agents can act recursively. From there, the key test is an authorization envelope: the intersection of the underlying human permission, a valid delegation path, and a compatible execution scope. That model can then be added to existing access policies and tested against a concrete prompt-injection scenario. Finally, the formal guarantees and performance measurements must be read with their assumptions intact.
The conclusion is modest but consequential. An agent’s identity is not valuable because it gives the agent more power. It is valuable because it keeps the actor visible while authority remains conditional. A system that knows only which human credential was used can record access. A system that knows which agent acted, whose permission it inherited, what narrowed its authority, and why the action was allowed can begin to govern that access.