An agent’s identity is not its authority.

Identity answers only the first question

A persistent identity can help an AI system carry responsibility across a workflow. It can connect a request to an actor, preserve a record through handoffs and make later review possible. But identity answers only one question: which actor is making this request? It does not answer what that actor may do now.

That distinction matters when an agent can retrieve files, call tools, modify data or trigger an external action. A credential that merely proves the agent’s identity can easily become a standing permission slip. If the same credential survives across unrelated tasks, contexts and operators, a traceable action can still be an over-authorized action. Accountability requires identity. Security requires a separate decision about authority.

Bind authority to the task

The practical pattern is narrow delegation. A grant should name the permitted action, the specific resource, the requesting task, the approving role and the time window. It should expire when the task ends, fail closed when required context is stale and require a new decision when the agent crosses into a different resource or higher-impact operation.

This is a design synthesis for agent systems, not a claim that NIST has published an AI-agent credential standard. The foundation is established security guidance. NIST Special Publication 800-207 says access should be granted per session with the least privileges needed to complete the task, and that authorization to one resource should not automatically grant access to another. NIST SP 800-53’s least-privilege control likewise applies to users and to processes acting on their behalf. The agent-specific step is to make the task itself part of the authorization boundary.

Record the delegation, not just the action

An audit trail that begins with the tool call is too late. The evidence should include who or what requested the work, which human or organizational role granted authority, what policy and evidence were considered, which credential was issued, when it expired, what the agent attempted and what effect the host independently observed.

That chain supports two different reviews. A security reviewer can ask whether the credential was valid for the action and whether revocation took effect. A governance reviewer can ask whether the grant itself was justified, whether an exception bypassed the intended review and whether responsibility remained clear after a handoff. A signed action is not necessarily an authorized action; the delegation record is what connects the two.

Test security and legitimate work together

I would evaluate this pattern with synthetic or consented workflows. One condition would give an identified agent a reusable credential with broad access. A second would use short-lived, task-scoped credentials. A third would add an independent approval step for high-impact actions and a complete delegation receipt. Hold the model, task set, tools and total resources constant.

Measure legitimate task completion, unauthorized attempts, independently observed unauthorized effects, stale-credential reuse, revocation latency, appropriate escalation, recovery time and operator burden. Include interrupted tasks, reassignment, conflicting instructions and urgent but legitimate requests.

This is a proposed study, not a report of measured results. The cybersecurity principle is simpler: identity should make an agent accountable across time, while authority should stay narrow enough to match the work in front of it. A durable name can support continuity. It should never become durable permission.