誰為 Agent 完成身份驗證？如何為代表客戶行事的 AI 建立身份機制
Who Authenticated the Agent? Building Identity for AI That Acts on a Customer’s Behalf
文章指出，代表客戶付款的 AI Agent 應分開識別客戶、執行操作的工作負載，以及客戶授予該工作負載的委派權限，不能只依賴客戶或服務憑證。付款後端應檢查授權範圍、限額、目的地及審批要求，並原子化記錄授權消耗、冪等鍵和派送意圖，避免重試重複消耗權限。工作佇列和後續工作者應保留發起者及委派記錄，並處理撤銷與已派送付款之間的競態。
Who Authenticated the Agent? Building Identity for AI That Acts on a Customer’s Behalf
A customer asks an AI assistant to pay an invoice. The assistant selects an account and submits the payment through an API.
The backend receives a valid token. But does that token identify the customer, the software executing the action, or both?
A customer credential alone may obscure the executing actor. A service credential alone does not establish the customer’s permission. An agent acting on someone’s behalf needs an enforceable relationship between these identities.
The Problem
Passing the customer’s existing access token into an agent runtime carries session authority into another execution environment. Its permissions may exceed the task, and downstream records may attribute every action solely to the customer.
A clearer architecture separates three concepts:
- Customer: Whose resources are affected.
- Workload: Which authenticated software invokes the operation.
- Delegation grant: What that workload may do for that customer.
Authentication establishes the actor. Delegation defines its authority. Authorization determines whether the requested operation fits that authority.
A prompt saying “you represent this customer” establishes none of those boundaries.
Where It Gets Difficult
Broad consent creates ambiguous authority
“Allow AI access” does not describe a useful payment boundary.
“Pay this biller once, from this account, up to ₹3,000, before this date” can become a structured grant with enforceable constraints.
Natural language may propose the permission. The backend should validate and store the approved policy.
Token protection does not authorize the transaction
Sender-constrained tokens can reduce the usefulness of a stolen token without its associated key. They do not establish customer approval of the payment.
DPoP, for example, does not sign the payment body or bind consent to its amount and beneficiary. Credential protection and transaction authorization address different risks.
Retries interact with consumed grants
Suppose the backend accepts a ₹2,750 payment and reserves the grant’s single permitted operation. The response is lost.
The retry must not consume authority again. After checking access and matching the request, the backend should return the existing operation associated with the scoped idempotency key.
Checking only whether the grant still has unused authority can incorrectly reject that recovery path.
Valid identity does not resolve prompt injection
A retrieved invoice or email may influence a legitimate agent’s tool use.
Backend constraints can reject an excessive amount or unapproved destination. They cannot always detect a harmful decision that remains within a broad grant.
Permission design must account for that residual risk.
Architectural Direction
Keep credentials in a controlled execution component outside model context and generated output. Authenticate the workload independently, then associate its permitted actions with a backend delegation record.
At payment acceptance:
- Validate credentials and resolve the customer and current actor.
- Check whether the scoped idempotency key already identifies an operation.
- For an existing operation, verify access and matching payment details.
- For a new operation, enforce grant status, limits, destination, and approval requirements.
- Atomically record authorization consumption, idempotency, and durable dispatch intent.
Define how revocation competes with acceptance. Revoking future authority does not necessarily cancel a payment already dispatched.
Preserve the initiating actor and delegation reference across queues and workers. A worker’s service identity should not erase who initiated the business operation.
The Takeaway
An authenticated agent is only one part of the design.
The backend must explain which software acted, whose authority it used, what that authority permitted, and how the operation recovered when execution became uncertain.
Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?
來源：DEV Community · dev.to