The Agent Passport: Identity and Authority for AI Systems

When an agent sends an email, edits a record, or purchases a service, “the AI did it” is not an acceptable identity model. Operators need to know which agent acted, for whom, under what instruction, with which credential, and inside what limit.

Separate Identity From the User

Giving an agent a person’s broad account makes access easy and accountability weak. A stronger design gives each deployed agent its own workload identity, then records the person or process that delegated a specific task.

The authorization should be narrow in four dimensions:

• Action: read, draft, submit, approve, refund, or delete.
• Resource: the exact mailbox, dataset, customer, project, or account.
• Value: spending, volume, sensitivity, or other consequence limits.
• Time: a short validity window that closes when the task ends.

Check Authority at the Moment of Action

A planning model may propose any number of steps. The execution layer must independently verify that each step is allowed. This prevents a poisoned page, stale instruction, or model error from turning a legitimate session into broad authority.

Credentials should also be revocable without rebuilding the agent. If a workflow behaves unexpectedly, an operator needs a reliable stop mechanism that removes access immediately and preserves the event trail.

Make Delegation Visible

Before a consequential action, the interface should show the agent identity, requested operation, target, evidence, and delegated limit in plain language. Approval should mean “allow this action,” not “trust everything this agent may decide later.”

The useful metaphor is a passport with visas, not a master key. Identity says who the agent is; authorization says where it may go today.