Agentic payments ภายใต้นโยบายของมนุษย์

Agentic payments คือการชำระเงินที่เริ่มโดยซอฟต์แวร์ ไม่ใช่โดยคนที่หน้าเช็คเอาต์ เอเจนต์ AI ถือข้อมูลรับรอง ตัดสินใจว่าควรซื้อ และโอนเงินเอง ไม่ว่าจะจ่ายใบแจ้งหนี้ ต่ออายุสมาชิก หรือจองเครื่องบินเช่าเหมาลำ โดยไม่มีมนุษย์กดปุ่มสุดท้าย ข้อเท็จจริงที่แยกมันออกมาคือผู้เริ่มรายการ เมื่อคนคลิกซื้อ นั่นคือการชำระเงินด้วยบัตรธรรมดาที่มีแชตบอตอยู่ด้านหน้า แต่ agentic payment คือซอฟต์แวร์ที่ตัดสินใจ อนุมัติ และชำระเงินเองในวินาทีที่เงินเคลื่อนจริง ทุกความยากของหมวดนี้มาจากคุณสมบัติข้อเดียว คือผู้ใช้จ่ายไม่ใช่คน และไม่เหนื่อย ไม่ระแวง ไม่ลังเลอย่างที่คนจะเป็นก่อนโอนเงินให้คนแปลกหน้า

เพราะอย่างนี้ คำถามที่น่าสนใจจึงไม่เคยเป็นเรื่องว่าเอเจนต์จะใช้จ่ายเงินไหม เพราะตอนนี้ทำได้แล้ว คำถามคือใครเป็นผู้กำหนดกฎที่มันใช้จ่ายภายใต้ และกฎเหล่านั้นถูกบังคับใช้โดยแพลตฟอร์ม หรือเป็นเพียงคำสัญญาของเอเจนต์

จุดล้มเหลวชัดเจน และนั่นคือประเด็น

ให้เอเจนต์ถือข้อมูลรับรองการชำระเงินจริงโดยไม่มีเพดาน คุณก็สร้างเหตุการณ์ฉ้อโกงทางการโอนเงินที่ยังไม่เกิดขึ้นไว้แล้ว วิธีที่มันพังไม่ได้แปลกใหม่ prompt injection ที่ซ่อนในหน้าเว็บสั่งให้เอเจนต์จ่ายเงินให้ผู้โจมตี คำอธิบายเครื่องมือที่ผิดรูปชี้การซื้อที่ถูกต้องไปยังผู้รับผิดคน หรือลูปการลองซ้ำพยายามตัดเงินรายการเดิมเป็นพันครั้งเพราะสัญญาณความสำเร็จไม่เคยกลับมา ทั้งหมดนี้ไม่ต้องอาศัยผู้โจมตีที่ฉลาด เป็นบั๊กธรรมดาของซอฟต์แวร์อัตโนมัติ เพียงแต่ผลลัพธ์คือเงินไหลออกจากบัญชีของคุณ

ทางแก้ที่ฟังดูน่าลองคือทำให้เอเจนต์ระมัดระวังขึ้น ด้วยซิสเต็มพรอมต์ที่ดีกว่า คำสั่งที่เข้มกว่า หรือโมเดลที่คิดเรื่องการใช้จ่ายหนักขึ้น แต่นั่นวางการควบคุมไว้ในจุดที่เชื่อถือได้น้อยที่สุดของระบบ คือการให้เหตุผลของเอเจนต์เอง ซึ่งเป็นสิ่งที่ถูกโน้มน้าวให้เปลี่ยนได้ งบประมาณที่เอเจนต์เถียงเอาชนะได้ไม่ใช่งบประมาณ การควบคุมต้องอยู่ในที่ที่เอเจนต์เอื้อมไม่ถึง นั่นคืออยู่นอกเอเจนต์โดยสิ้นเชิง

นโยบายคือผลิตภัณฑ์ ไม่ใช่พรอมต์

โมเดลการควบคุมคือนโยบายที่แพลตฟอร์มบังคับใช้ก่อนเงินเคลื่อน ไม่ใช่หลังเอเจนต์ตัดสินใจไปแล้ว เอเจนต์แต่ละตัวมีเพดานต่อรายการและวงเงินรายวัน ในนโยบายเดโมของเราคือ €150.00 ต่อรายการ €500.00 ต่อวัน และเพดานรายเดือน €6,000.00 กำกับอยู่ด้านบน เหล่านี้คือกำแพงจริงที่แพลตฟอร์มตรวจสอบ ไม่ใช่คำสัญญาที่เอเจนต์รักษา เมื่อบอตท่องเที่ยวในเดโมพยายามจองเหมาลำ €640.00 รายการถูกปฏิเสธทันที เกินเพดาน ก่อนที่เงินสักเซนต์จะเคลื่อน เอเจนต์ที่ทำงานเรียบร้อยทุกวันก็ยังเกินกว่าที่เดือนหนึ่งอนุญาตไม่ได้

งบประมาณบอกว่าเท่าไร allowlist บอกว่าที่ไหน เอเจนต์จ่ายได้เฉพาะร้านค้าที่คุณระบุชื่อไว้ล่วงหน้า Ops Agent ในเดโมรู้จักเพียงสี่ราย และความพยายามจ่าย €180.00 ให้ผู้ขายนอกรายการถูกปฏิเสธว่าไม่อยู่ในรายการ ทั้งสองอย่างรวมกันวาดกรอบขึ้นมา เงินเท่านี้ ให้เฉพาะผู้รับเหล่านี้ ภายในกรอบ เอเจนต์ทำงานเต็มความเร็วโดยไม่ต้องขออนุญาต และกรอบนั้นคือสิ่งที่มนุษย์เป็นเจ้าของ

คำถามไม่เคยเป็นว่าเอเจนต์ AI จะใช้จ่ายเงินหรือไม่ แต่คือใครเขียนกฎที่มันใช้จ่ายภายใต้ และคำตอบควรเป็นมนุษย์เสมอ ล่วงหน้า และเป็นลายลักษณ์อักษร

มนุษย์เหนือเส้น

บางการตัดสินใจใหญ่เกินกว่าจะปล่อยให้กรอบจัดการ นโยบายจึงมีเกณฑ์ คือจำนวนเงินที่หากเกิน มนุษย์ต้องอนุมัติก่อนรายการจะผ่าน ในเดโม เส้นนี้อยู่ที่ €100.00 เมื่อ Ops Agent ติดธงใบแจ้งหนี้ #088 จาก Nord Logistics จำนวน €120.00 ซึ่งอยู่ในงบรายวัน €500.00 สบายๆ แต่เกินเส้นอนุมัติ มันไม่ได้จ่าย มันหยุด นำข้อเสนอไปให้คนดู และรอ คำตอบบรรทัดเดียวก็ปลดล็อก รายการชำระสำเร็จด้วยเลขอ้างอิง 9F21-0716 และเข้าบันทึกตรวจสอบเวลา 09:41 ต่ำกว่าเส้น เอเจนต์เดินหน้าเอง สูงกว่าเส้น คนต้องตอบก่อน

การอนุมัติไม่ใช่ช่องติ๊กที่หายไปเฉยๆ มันบันทึกว่าใครอนุมัติ บนอุปกรณ์ใด เวลาใด พร้อมลายเซ็นแนบ คืออนุมัติในแอป ด้วยคีย์บนโทรศัพท์ เวลา 09:41:12 เมื่อมีคนถามภายหลังว่าทำไมจึงเกิดการชำระเงินนี้ คำตอบคือบุคคลที่มีชื่อและเวลาที่ระบุ ไม่ใช่การยักไหล่

Kill-switch และบันทึกที่แก้ไขเงียบๆ ไม่ได้

แม้อยู่ในกำแพงที่ดี เอเจนต์ก็ยังทำงานผิดพลาด และนโยบายก็อาจผิดได้ มีการควบคุมสองอย่างรับมือเรื่องนี้ อย่างแรกคือ kill-switch แตะครั้งเดียวก็หยุดเอเจนต์และระงับทุกการชำระเงินที่มันอาจเริ่มได้ทันที คีย์ยังใช้งานได้ ส่วนอื่นจึงไม่พัง เอเจนต์เพียงใช้จ่ายไม่ได้จนกว่ามนุษย์จะเปิดกลับ และข้อเสนอที่ค้างอยู่จะถูกแช่แข็งไว้ ไม่หายไป ในกลุ่มเอเจนต์เดโม บอตท่องเที่ยวถูกหยุดไว้ที่ใช้จ่าย €0.00 คิวยังอยู่ครบ

อย่างที่สองคือ audit log แบบ append-only ทุกการตัดสินใจถูกบันทึกไว้ ไม่ว่าเอเจนต์พยายามทำอะไร ผ่านหรือไม่ผ่านการตรวจนโยบายข้อไหน ใครอนุมัติอะไร ไปจนถึงการหมุนเวียนคีย์ เพียงหนึ่งบันทึกก็ย้อนรอยการชำระเงินได้ทั้งรายการ เช่น decision DEC-4471 แสดงคำขอ การตรวจนโยบายแต่ละข้อพร้อมผลลัพธ์ (allowlist ผ่าน, วงเงินผ่าน, เกณฑ์ส่งต่อ escalate) ลายเซ็นของผู้อนุมัติ และยอดที่ชำระเสร็จสิ้นพร้อม rail และหมายเลขอ้างอิง ทุกรายการมีแฮชของตัวเอง แฮชของรายการก่อนหน้า และลำดับในเชน (#4,471 ในเดโม) ดังนั้นการแก้ไขฟิลด์ใดก็ตามจะทำให้ทุกรายการหลังจากนั้นเสียหาย log ส่งออกเป็น JSON พร้อมแฮชได้ เป็นของคุณที่จะส่งให้ผู้ตรวจสอบ ไม่ใช่ของเราที่จะเก็บไว้

ให้การชำระหนี้น่าเบื่อไว้ แล้วใส่ความใหม่ไว้ที่การอนุมัติสิทธิ์

มีสิ่งล่อใจให้ทำการชำระเงินแบบ agentic ให้ใหม่ไปหมดทุกชั้น ทั้ง rail ใหม่ เครื่องมือชำระเงินใหม่ และวิธีเคลื่อนย้ายเงินแบบใหม่ จงอย่าทำ ส่วนที่ใหม่จริง ๆ คือการอนุมัติสิทธิ์ (authorization) คือเอเจนต์พิสูจน์อย่างไรว่าตนมีสิทธิ์จ่าย ภายใต้นโยบายของใคร และด้วยการอนุมัติแบบใด เมื่อการชำระเงินผ่านด่านนี้แล้ว ก็ควรชำระหนี้บน rail ที่น่าเบื่อมาหลายปี ในเดโม ข้อเสนอที่อนุมัติแล้วมูลค่า €120.00 กลายเป็นการโอนเครดิต SEPA ธรรมดา ชำระหนี้ผ่าน SEPA Instant ภายในไม่กี่นาทีหลังอนุมัติ และปลายทางแยกไม่ออกจากการชำระเงินที่คนทำเอง ธนาคารไม่รู้และไม่สนว่าเอเจนต์เป็นผู้เริ่มต้น

การแยกส่วนนี้ตั้งใจทำ rail ที่น่าเบื่อคาดเดาได้ ย้อนรายการได้เท่าที่สกีมอนุญาต และทุกทีมธนาคารกลางและผู้ตรวจสอบที่คุณจะเจอเข้าใจดีอยู่แล้ว เมื่อใส่ความใหม่ไว้ที่นโยบาย และให้การชำระเงินไปบน rail ที่พิสูจน์แล้ว ส่วนที่เสี่ยงและเปลี่ยนเร็วจึงเป็นส่วนที่คุณควบคุมได้เต็มที่ ส่วนที่แตะธนาคารของคนอื่นก็เป็นส่วนที่ไม่มีใครต้องเรียนรู้ใหม่ เอเจนต์ใช้จ่ายจากแกนเดียวกับที่ตระกูลการชำระเงินที่เหลือทำงานอยู่ ตามที่อธิบายไว้ที่ /products/pay ไม่ใช่จากโลกคู่ขนานที่สร้างมาเพื่อหุ่นยนต์

โปรโตคอลยังไม่นิ่ง จงสร้างระบบให้รองรับสิ่งนี้

เอเจนต์ควรแสดงตัวตนและอำนาจที่ได้รับมอบ (mandate) ต่อร้านค้าอย่างไร ยังเป็นคำถามที่เปิดอยู่ มีหลายข้อเสนอแข่งกันว่าเอเจนต์จะพิสูจน์ตัวตน สิ่งที่ได้รับอนุญาตให้ซื้อ และวิธีที่ร้านค้าตรวจสอบก่อนรับเงินได้อย่างไร ยังไม่มีข้อไหนชนะ และการเดิมพันทุกอย่างกับข้อใดข้อหนึ่งตอนนี้ก็เร็วเกินไป ท่าทีป้องกันคือมองโปรโตคอลการอนุมัติสิทธิ์เป็นส่วนที่สลับได้ และให้ทุกอย่างเบื้องหลังคงที่ ทั้ง policy engine โมเดล audit และ rail ชำระหนี้ ไม่เปลี่ยนไปเมื่อ wire format ด้านหน้าเปลี่ยน

ในทางปฏิบัติ นั่นหมายถึงพื้นผิวการเชื่อมต่อที่เล็กและน่าเบื่อ เอเจนต์เชื่อมต่อผ่าน MCP ที่ mcp.protocore.io/agents เฟรมเวิร์กใดก็ตามที่รองรับโปรโตคอลนี้ถือ wallet ได้ อินเทอร์เฟซแคบโดยตั้งใจ คือเสนอการชำระเงินแล้วรับการตัดสินใจกลับมา เพราะตรรกะที่น่าสนใจอยู่บนแพลตฟอร์ม ไม่ใช่ใน prompt เมื่ออุตสาหกรรมตกลงกันได้ว่าเอเจนต์จะพิสูจน์ตัวเองต่อร้านค้าอย่างไร ด้านหน้าก็เปลี่ยนไป ส่วนกำแพงด้านหลังยังอยู่ที่เดิมทุกประการ

ตำแหน่งของเรื่องนี้

การชำระเงินแบบ agentic ไม่ใช่การเดิมพันว่าซอฟต์แวร์อัตโนมัติควรใช้จ่ายได้ไม่จำกัด แต่เป็นตรงข้าม คือการเดิมพันว่าซอฟต์แวร์จะใช้จ่ายอยู่แล้ว ข้อจำกัดจึงควรเป็นของจริง อยู่ภายนอก และอ่านเข้าใจได้ งบประมาณและ allowlist กำหนดกรอบ เกณฑ์วงเงินส่งการตัดสินใจใหญ่ ๆ ให้คน kill-switch หยุดได้ทุกอย่าง และ log แบบ append-only ทำให้ย้อนรอยทุกการชำระเงินได้ภายหลัง หน้าผลิตภัณฑ์ที่ /products/agents พาดูวงจรทั้งหมดด้วยข้อมูลเดโมชุดเดียวกับที่ใช้ที่นี่ ตั้งแต่สร้างเอเจนต์ ตั้งนโยบาย ไปจนถึงดูการชำระเงินถูกส่งต่อและชำระหนี้ ส่วน /products/pay คือแกนที่การชำระเงินเหล่านั้นทำงานอยู่ อิสระนั้นเป็นของจริง สายจูงก็เช่นกัน และมีคนถืออยู่