An account answers only one question
A common way to deploy an AI agent is to create a service account, attach a token, and let the agent call the tools it needs. That answers one operational question: how can the software authenticate? It does not fully answer the questions that appear when the agent sends an email, edits a repository, changes a record, or approves a payment.
Who asked for the action? Which agent instance interpreted that request? What authority was delegated to it? Was the permission limited to this task, this resource, and this time window? Can someone later prove what the agent actually did?
These questions are becoming a repeated theme in public developer conversations. The concern is not that agents lack credentials. It is that a credential can hide the chain between human intent, agent behavior, and the resulting action.
NIST’s concept paper on software and AI agent identity and authorization puts that chain at the center. It raises identity, authentication, authorization, delegation, auditing, non-repudiation, and prompt injection as connected design problems. Its direction is practical: distinguish an agent from a human, bind the agent’s identity to the human or organization it represents, manage entitlements, and preserve verifiable evidence of authority and action.
A recent survey of AI identity reaches a similar conclusion from the research side. Existing identity standards were built around more stable actors. Agents can cross system boundaries, use tools, delegate work, and change behavior over a long-running task. The gap is not solved by giving each agent a nicer name or another API key.
Delegation is the missing middle
Consider a simple instruction: prepare a release and notify the customer. A human may authorize the plan, one agent may inspect the repository, another may run tests, and a separate tool may send the message. If every step uses the same service identity, the final log can show that an account acted while hiding which agent made which decision and which human authority allowed it.
Trust grows when the delegation chain is visible from intent to action.
An agent identity should therefore be more than a label. It should be a verifiable link between at least four elements:
- the principal whose intent started the task;
- the concrete agent instance and version that handled it;
- the scope of authority, including tools, data, time, and limits;
- the action, result, and evidence that can be checked later.
In practice, the record should also preserve the task identifier, expiration time, delegation depth, and reason for each scope change. A downstream agent should not be able to widen its authority silently; a new scope should create a new decision. Separating the request, policy decision, tool execution, and outcome makes the chain useful during incident review instead of leaving one opaque service-account event.
For a small implementation, start with a bounded schema: human principal, agent instance and version, task identifier, allowed tools and resources, expiry, approval reference, tool call, and outcome. The exact protocol can evolve later, but losing these links at the beginning is expensive to repair.
Long-running work needs one more check. The system should verify at each meaningful step whether the token expired, a person cancelled the task, or a delegated scope changed. Agent identity is not a label issued once at startup; it is a chain of responsibility that must remain valid until the work ends.
This structure does not require turning every action into a bureaucratic approval ceremony. Low-risk, reversible work can run within a predefined scope. Higher-risk actions can require a fresh human decision. The important part is that the difference is explicit and machine-checkable.
Identity is not a safety guarantee
A strong identity can still be used to do the wrong thing. A valid agent may misunderstand an instruction, follow a malicious tool description, or make a damaging change within its authorized scope. Identity solves attribution and authority provenance; it does not replace tool isolation, least privilege, monitoring, human review, or rapid revocation.
There is also a maturity warning. NIST’s document is a concept paper, not a finished universal standard, and the research survey describes open gaps rather than a complete implementation recipe. Teams should not wait for one perfect protocol. They can start by recording the human principal, agent instance, delegated scope, tool call, approval decision, and outcome as separate fields instead of collapsing them into one account log.
The useful question for builders
The question is not whether an agent feels like a person. It is whether a system can answer, with evidence, who acted, on whose authority, within which boundary, and with what result.
As agents move from drafting text to changing systems, identity becomes the connective tissue between permission and accountability. The next step in agent infrastructure is not simply issuing more credentials. It is making delegated action understandable, limited, and provable.
