Agent mua hàng thay bạn: Ủy quyền chi tiêu phải có bằng chứng mật mã

Tóm tắt cốt lõi: Agent mua hàng không nên được chi tiền chỉ vì có quyền gọi API: giao dịch phải gắn với ý định, checkout được cam kết và bằng chứng ủy quyền có thể kiểm tra. Với SME, ưu tiên là tách mô hình khỏi khóa ký, áp hạn mức bằng mã thực thi và triển khai xác nhận trước khi mở quyền tự động.

Một agent tìm được giá tốt chưa chắc là một agent được phép thanh toán. Khoảng cách giữa hai việc ấy chính là nơi doanh nghiệp có thể mất tiền: chọn nhầm biến thể, chấp nhận phí phát sinh hoặc gửi lại lệnh mua sau khi kết nối bị ngắt.

Vấn đề không nằm ở việc mô hình có thông minh hơn hay không. Nó nằm ở câu hỏi: ai cho phép giao dịch này, cho phép điều gì và bằng chứng nào còn lại khi có tranh chấp? Từ góc nhìn vận hành của AI Ops Solutions, lớp thanh toán phải được thiết kế như một hệ thống kiểm soát tài chính, không phải phần mở rộng của cửa sổ chat.

Phạm vi nguồn: các chi tiết về Amex và codelab Google trong bài dựa trên hồ sơ nghiên cứu được cung cấp, chưa được đối chiếu độc lập tại đây. Những thông số phiên bản và demo cần được kiểm tra lại với tài liệu triển khai; các hạn mức và phép tính SME dưới đây là ví dụ thiết kế, không phải báo giá hay cam kết của nhà cung cấp.

Vì sao được phép truy cập không đồng nghĩa với được phép chi tiền?

Trả lời nhanh: Quyền truy cập chỉ xác định agent được gọi dịch vụ nào; quyền chi tiêu phải xác định mua gì, từ ai, tối đa bao nhiêu và trong bao lâu. SME nên dùng ba chốt độc lập: chính sách ngân sách, xác nhận checkout và bằng chứng ủy quyền gắn với giao dịch cụ thể.

API key không phải chữ ký trên hóa đơn

Một API key có thể cho phép tạo checkout nhưng không chứng minh chủ thẻ đồng ý với món hàng trong checkout ấy. Tương tự, đăng nhập bằng OAuth giải quyết quyền truy cập theo scope, không mặc nhiên giải quyết sự đồng thuận với từng khoản chi.

Đây là khác biệt giữa danh tính và mandate: danh tính trả lời ai đang hành động; mandate trả lời hành động nào được ủy quyền, trong điều kiện nào. Agent hợp lệ vẫn có thể tạo giao dịch không hợp lệ.

LLM không nên làm trọng tài cuối cùng

Người dùng nói “mua loại cũ, dưới một triệu”. Agent phải diễn giải loại cũ là mã hàng nào, ngân sách có gồm vận chuyển không và có chấp nhận nhà bán khác không. Nếu các câu hỏi ấy chỉ tồn tại trong hội thoại, một prompt injection từ trang sản phẩm có thể làm lệch quyết định.

• Mô hình: Đề xuất sản phẩm và giải thích lựa chọn.
• Policy engine: Kiểm tra SKU, merchant, tiền tệ, tổng tiền và hạn mức.
• Thành phần ký: Tạo bằng chứng phê duyệt trong phạm vi được phép.

Không giao cả ba vai trò cho cùng một agent. Đây là nguyên tắc quan trọng hơn việc chọn mô hình nào.

Ba lớp của giao dịch: ý định, cam kết và ủy quyền

Intent: chuyển lời nói thành điều kiện kiểm tra được

Intent cần ghi rõ mặt hàng, số lượng, biến thể, merchant được phép, tổng ngân sách và thời hạn. “Giày trắng size 9” chưa đủ: phải xác định hệ size, nhãn hiệu bắt buộc hay tùy chọn, và mức chênh giá có thể chấp nhận.

Trong thực tế SME, nên chuyển yêu cầu sang schema rồi cho người dùng xem lại. Điều kiện cứng phải tách khỏi sở thích mềm. “Không vượt 1.000.000 đồng” là điều kiện cứng; “ưu tiên giao ngày mai” có thể là sở thích.

Commitment: merchant cam kết đúng checkout

Agent có thể tìm sản phẩm lúc giá thấp nhưng thanh toán sau khi giá đổi. Vì vậy, cần một bản checkout xác định rõ sản phẩm, thuế, phí, tiền tệ và thời hạn báo giá. Chữ ký merchant giúp chứng minh bản checkout đến từ bên ký và không bị sửa.

Chữ ký không chứng minh sản phẩm tốt hoặc merchant trung thực. Nó bảo vệ tính toàn vẹn và nguồn gốc của cam kết, không thay thế thẩm định nhà cung cấp.

Mandate: phê duyệt đúng bản cam kết ấy

Ủy quyền phải liên kết với checkout cụ thể, thường bằng hash. Nếu giá, SKU hoặc địa chỉ giao hàng thay đổi trong phần được ràng buộc, hệ thống phải yêu cầu đánh giá lại thay vì dùng chữ ký cũ.

Đừng hỏi agent có nhớ người dùng muốn gì không. Hãy hỏi hệ thống có chứng minh được giao dịch cuối cùng nằm trong phạm vi đã duyệt không.

Amex Intent Intelligence Framework giải quyết điều gì?

Theo bản tin TechCrunch ngày 13/10/2026 được trích trong hồ sơ nghiên cứu, American Express giới thiệu Intent Intelligence Framework nhằm gắn chỉ dẫn mua hàng với quá trình cấp thông tin thanh toán cho agent.

Từ Create Intent API đến Proof of Intent Token

Luồng được mô tả bắt đầu bằng Create Intent API: ghi lại chỉ dẫn, ngân sách tối đa, merchant và sở thích sản phẩm. Khách hàng xác thực danh tính, ký duyệt intent; hệ thống tạo Intent ID cùng Proof of Intent Token. Token được dùng để đổi lấy thông tin thanh toán số dùng một lần thay vì đưa số thẻ thật cho agent.

Điểm đáng chú ý không chỉ là giấu số thẻ. Nó là khả năng nối yêu cầu ban đầu → bằng chứng phê duyệt → công cụ thanh toán. Tuy nhiên, không nên suy ra rằng thông tin dùng một lần tự động ràng buộc mọi thuộc tính sản phẩm; điều đó phụ thuộc cơ chế kiểm tra thực tế.

Bài kiểm tra Nike và Adidas

Ví dụ Amex nêu là khách muốn giày Nike trắng size 9, nhưng agent gửi yêu cầu mua Adidas. Hệ thống có thể chặn trước khi thanh toán. Đây là kiểm soát sai lệch ý định, khác với phát hiện một kẻ lạ đánh cắp thẻ.

Hồ sơ cũng dẫn khảo sát Amex Trendex: 66% người Mỹ được hỏi có khả năng dùng agent so sánh giá trong 12 tháng tới, 61% dùng để nhận gợi ý. Những tỷ lệ này phản ánh ý định sử dụng, không phải tỷ lệ sẵn sàng giao quyền chi tiền.

Amex cho biết chưa thấy khiếu nại do agentic commerce gia tăng. Điều đó không chứng minh mô hình đã an toàn ở quy mô lớn; nó giải thích vì sao cần xây kiểm soát trước khi lượng giao dịch tăng.

UCP và AP2 phối hợp từ khám phá merchant đến thanh toán ra sao?

UCP và AP2 xử lý các phần khác nhau. UCP cung cấp cách mô tả năng lực thương mại và tương tác với merchant; AP2 tập trung vào bằng chứng ủy quyền thanh toán. Có thể tham khảo tài liệu chính thức của Universal Commerce Protocol để kiểm tra capability và phiên bản đang được hỗ trợ.

Khám phá không đồng nghĩa với tin cậy

Codelab được dẫn trong nghiên cứu mô tả khám phá merchant qua /.well-known/ucp, rồi tìm sản phẩm và tạo checkout bằng JSON-RPC 2.0 trên MCP. Endpoint khám phá cho biết dịch vụ công bố khả năng gì; nó không tự chứng minh merchant đáng tin hoặc được doanh nghiệp cho phép mua.

Gateway vẫn phải kiểm tra domain, danh sách merchant được duyệt, capability cần dùng và payment handler. MCP là lớp kết nối công cụ, không phải giấy phép chi tiêu.

Hai miền tin cậy, không đơn giản là hai token

Theo mô tả AP2 v0.2 trong hồ sơ, merchant ký checkout qua ap2.merchant_authorization; phía người dùng ký CheckoutMandate và PaymentMandate dưới dạng SD-JWT, liên kết bằng hash của checkout đã ký. Bên xử lý thanh toán xác minh PaymentMandate trước khi chuyển tiền.

“Hai lớp khóa” nên được hiểu là tách miền tin cậy merchant và người phê duyệt, không phải cứ có hai mandate là phải có đúng hai khóa. Cũng theo hồ sơ, CheckoutMandate thay CartMandate của bản trước; tích hợp phải kiểm tra schema theo phiên bản, không trộn tên trường.

Thời hạn 600 giây chỉ là cấu hình demo

Demo sử dụng exp = iat + 600, tức 10 phút. Đây không phải thời hạn bắt buộc cho mọi giao dịch. TTL ngắn giảm cửa sổ lạm dụng nhưng tăng checkout hết hạn và nhu cầu xác nhận lại.

Nhóm triển khai nên đối chiếu kho mã AP2 của Google Agentic Commerce trước khi xây bộ xác minh. Cần kiểm tra chữ ký, issuer, audience, thời hạn, khóa bị thu hồi, ràng buộc checkout và chống phát lại; chữ ký hợp lệ chưa đủ nếu cùng bằng chứng được sử dụng nhiều lần.

Khi nào agent mua hàng phải xin xác nhận?

Trả lời nhanh: Hãy yêu cầu xác nhận khi xuất hiện merchant mới, thay SKU, vượt hạn mức hoặc thay đổi điều kiện đã duyệt. Chỉ tự động hóa mua lặp lại trong phạm vi hẹp. Ví dụ thử nghiệm: tối đa 500.000 đồng mỗi đơn, 2 triệu đồng mỗi ngày; đây là hạn mức minh họa.

Xác nhận phải hiển thị đúng dữ liệu sẽ được ký

Nút “Đồng ý” không đủ nếu màn hình chỉ hiện bản tóm tắt do LLM viết. Giao diện phải lấy trực tiếp từ checkout: merchant, mặt hàng, số lượng, tổng tiền, tiền tệ và điều kiện thay thế. Hash cần gắn với chính dữ liệu người dùng được xem.

Mẫu require_confirmation trong codelab tạm dừng agent trước complete_purchase. Nhưng xác nhận trong hội thoại và chữ ký thanh toán là hai cơ chế khác nhau; hệ thống phải nối chúng bằng trạng thái và định danh giao dịch rõ ràng.

Không để agent tự sinh khóa rồi tự phê duyệt

Codelab được mô tả yêu cầu production ký trên thiết bị tin cậy, có thể sử dụng sinh trắc học, thay vì khóa do agent tự sinh. Sinh trắc học thường dùng để mở quyền sử dụng khóa trên thiết bị; không cần gửi dữ liệu sinh trắc học cho merchant.

• Mua lần đầu: Người dùng kiểm tra merchant và xác nhận checkout.
• Mua lặp lại: Chỉ tự động nếu SKU, nhà bán và giới hạn giá đều đạt.
• Thay đổi bất thường: Dừng khi đổi tài khoản nhận tiền, địa chỉ giao hoặc tiền tệ.
• Thiếu bằng chứng: Từ chối mặc định; không nhờ LLM đoán xem có nên bỏ qua.

Với ủy quyền định kỳ, khóa dịch vụ phải nằm trong hệ thống quản lý khóa phù hợp và chịu policy độc lập. Không đưa khóa bí mật vào prompt, bộ nhớ agent hoặc log workflow.

So sánh chatbot, agent không mandate và agent có mandate

Bảng dưới đây so sánh ba cách triển khai. Có mandate không tự động đồng nghĩa được hoàn tiền; quyền khiếu nại còn phụ thuộc hợp đồng, phương thức thanh toán và pháp luật áp dụng.

Điểm lựa chọn không phải “agent càng tự chủ càng tốt”. Nếu doanh nghiệp chỉ mua vài đơn mỗi tuần, chatbot hỗ trợ lựa chọn cộng phê duyệt thủ công có thể hiệu quả hơn hệ thống ký phức tạp. Khi tự động hóa, nên chọn quy trình SME có đầu vào rõ và guardrail đo được, thay vì mở toàn bộ quyền mua hàng.

Chi phí thật: đo trên giao dịch đúng, không chỉ trên token

Một phép tính vận hành minh họa

Chi phí mỗi giao dịch đúng = tổng chi phí vận hành / số giao dịch hoàn tất đúng phạm vi ủy quyền. Tử số gồm suy luận, công cụ, xác minh, quan sát hệ thống, nhân sự duyệt và xử lý lỗi. Mẫu số không tính đơn mua sai rồi phải hoàn.

Giả sử mỗi tháng có 10.000 lượt thử, tổng chi phí 500 USD và 8.000 giao dịch đúng: chi phí là 0,0625 USD/giao dịch. Nếu giảm hóa đơn mô hình 50 USD nhưng phát sinh 200 USD hỗ trợ, hệ thống đã đắt hơn. Đây là ví dụ tính toán, không phải benchmark.

API hay tự host không có một ngưỡng chung

Hồ sơ nghiên cứu dẫn các ước tính khác nhau về H100, mô hình mở và mốc 1 tỷ token/tháng. Không nên biến chúng thành quy tắc mua sắm: chi phí GPU ở batch lớn không thể so trực tiếp với giá endpoint đã gồm phục vụ, dự phòng và vận hành.

SME nên bắt đầu bằng API thương mại, trừ khi có yêu cầu dữ liệu hoặc tải ổn định đủ lớn. Quyết định tự host phải tính utilization, độ trễ, trực vận hành và chi phí dự phòng. Giá output cũng cần lấy từ đúng bảng giá, không mặc định luôn đắt gấp một tỷ lệ cố định.

Retry là điểm vừa tốn tiền vừa nguy hiểm

Sau timeout, agent không biết thanh toán thất bại hay chỉ mất phản hồi. Cách đúng là truy vấn trạng thái bằng payment attempt ID, không lập tức tạo lần mua mới. Dùng idempotency key cho ý định giao dịch và phối hợp với cơ chế của nhà cung cấp.

Như nguyên tắc trong bài quản trị tokenomics để tránh phình ngân sách AI, cần đo vòng lặp và số lần thử. Với thanh toán, bổ sung chỉ số đơn trùng, chi ngoài phạm vi và thời gian hòa giải giao dịch.

Lộ trình 90 ngày cho SME: tách agent khỏi quyền phát tiền

Ngày 1–30: chỉ đọc và chạy đối chứng

Chọn một nhóm hàng chuẩn hóa, ít biến thể và merchant quen thuộc. Agent chỉ đọc catalog, so sánh và đề xuất; nhân viên mua như trước. Đo tỷ lệ chọn đúng SKU, tổng tiền và khả năng phát hiện thay đổi điều kiện.

Đồng thời xây schema intent, registry merchant và bộ kiểm tra xác định. Nếu chưa phân biệt được hàng “tương tự” với hàng “được phép thay thế”, chưa nên mở thanh toán.

Ngày 31–60: checkout có xác nhận

Kiến trúc gợi ý là agent → policy gateway → checkout → phê duyệt → payment adapter. Với n8n, workflow điều phối trạng thái và thông báo; khóa ký, credential thanh toán và bộ xác minh nên nằm ngoài ngữ cảnh LLM.

• Trước xác nhận: Chuẩn hóa checkout, kiểm tra ngân sách và tạo bản ghi chờ duyệt.
• Sau xác nhận: Kiểm tra lại hash, thời hạn và trạng thái chưa sử dụng.
• Khi timeout: Hòa giải trạng thái trước khi thử lại.
• Khi không hỗ trợ chuẩn: Dùng adapter riêng; không gọi log nội bộ là mandate được merchant công nhận.

Ngày 61–90: tự động hóa có điều kiện

Chỉ mở cho mua lặp lại trong phạm vi đã kiểm chứng. Áp hạn mức theo đơn, ngày và toàn doanh nghiệp; giữ chỗ ngân sách bằng thao tác nguyên tử để nhiều agent không cùng tiêu phần ngân sách còn lại.

Kiểm thử bắt buộc gồm checkout bị sửa, token hết hạn, replay, phí tăng, webhook giả và timeout sau khi đã trừ tiền. Phải có kill switch, chủ sở hữu sự cố và quy trình khiếu nại. Không mở rộng chỉ vì một bản demo chạy thành công.

Những rủi ro chữ ký mật mã chưa giải quyết hết

Ủy quyền đúng không bảo đảm thực hiện đúng. Merchant vẫn có thể giao sai hàng, agent chọn nhầm nhưng người dùng không đọc kỹ, hoặc khóa hợp lệ bị lạm dụng. Mandate giúp xác định trách nhiệm; nó không loại bỏ tranh chấp.

SD-JWT hỗ trợ tiết lộ có chọn lọc, nhưng không tự bảo đảm quyền riêng tư. Cần xác định bên nào được thấy trường nào, tránh identifier liên kết hoạt động không cần thiết và giới hạn thời gian lưu. Đừng đẩy toàn bộ địa chỉ, sở thích cùng token nhạy cảm vào log quan sát.

Hồ sơ kiểm toán nên nối được intent, checkout, mandate, kết quả policy, payment attempt và đơn hàng, đồng thời phân quyền truy cập. Lưu bằng chứng cần thiết không có nghĩa lưu vô hạn mọi dữ liệu thô.

Mức tự chủ phù hợp không phải mức agent làm được, mà là mức doanh nghiệp có thể kiểm soát, giải trình và xử lý khi sai.

Câu hỏi thường gặp

Agent có mandate rồi thì có thể bỏ bước người dùng xác nhận không?

Có thể với giao dịch nằm trong ủy quyền trước còn hiệu lực, nếu hệ thống thanh toán hỗ trợ và chính sách cho phép. Nhưng mandate cho một checkout không mặc nhiên cho phép checkout khác. Merchant, SKU, tổng tiền hoặc điều kiện thay thế vượt phạm vi phải kích hoạt phê duyệt mới.

Hash checkout có đủ để ngăn agent mua sai hàng không?

Không. Hash giúp phát hiện dữ liệu thay đổi sau khi được ràng buộc; nó không chứng minh checkout ban đầu đúng ý người dùng. Cần kiểm tra intent trước khi ký, hiển thị dữ liệu chính xác và xác định rõ trường nào nằm trong nội dung được băm.

SME dùng n8n có cần tự triển khai toàn bộ AP2 không?

Không nhất thiết. Nên ưu tiên cổng thanh toán hoặc SDK hỗ trợ chuẩn phù hợp, dùng n8n điều phối và gọi dịch vụ xác minh độc lập. Nếu merchant chưa hỗ trợ, doanh nghiệp vẫn có thể áp dụng phê duyệt và hạn mức nội bộ, nhưng không nên tuyên bố tương thích AP2 chỉ vì có token tự tạo.

Khi xảy ra tranh chấp, bằng chứng nào quan trọng nhất?

Cần chuỗi bằng chứng liên kết được: ý định đã duyệt, checkout được cam kết, phạm vi mandate, kết quả xác minh, yêu cầu thanh toán và đơn hàng cuối. Chuỗi này giúp phân biệt lỗi diễn giải, sửa dữ liệu, mua trùng và giao sai hàng; khả năng hoàn tiền vẫn phụ thuộc quy định áp dụng.

Kết luận: tự động hóa lựa chọn, kiểm soát chặt quyết định chi

Agent mua hàng chỉ đáng tin khi doanh nghiệp chứng minh được đã mua đúng thứ được phép, đúng điều kiện và không vượt ngân sách. Điểm khởi đầu thực dụng là intent có cấu trúc, checkout có xác nhận, policy độc lập và nhật ký đối chiếu được. Sau đó mới tăng quyền tự chủ bằng mandate và giới hạn đã kiểm thử.

Tác giả: Cường Nguyễn — Founder AI Ops Solutions | Verified n8n Creator. Kết nối: Facebook · LinkedIn · YouTube · TikTok