เมื่อ Wallet ไม่ได้มีไว้แค่เก็บ Private Key: ออกแบบความปลอดภัยของสินทรัพย์ดิจิทัลในวันที่ AI เริ่มทำธุรกรรมแทนมนุษย์

เมื่อองค์กรและสถาบันการเงินเริ่มนำ Digital Asset มาใช้งานจริงมากขึ้น การบริหารจัดการ Wallet ก็มีความซับซ้อนมากกว่าการเก็บ Private Key ให้ปลอดภัย โดยเฉพาะในระดับองค์กรที่อาจต้องบริหารสินทรัพย์มูลค่าสูง มีผู้ใช้งานหลายคน และมีธุรกรรมจำนวนมาก 

แล้ว Wallet สำหรับองค์กรควรถูกออกแบบอย่างไร? เราควรให้อำนาจคนแต่ละคนมากแค่ไหน?

ธุรกรรมแบบใดควรทำอัตโนมัติ และแบบไหนควรมีมนุษย์เข้ามาตรวจสอบ? ยิ่งไปกว่านั้น เมื่อ AI Agent เริ่มสามารถซื้อขาย ชำระเงิน และทำธุรกรรม On-chain ได้ด้วยตัวเอง เราจะกำหนดขอบเขตให้ AI เหล่านี้อย่างไร?

ประเด็นเหล่านี้ถูกหยิบมาพูดผ่าน Session “Wallet Control in Production: Policy Engines, Automation, and Institutional-Grade Guardrails”  ในงาน REDeFiNE TOMORROW 2026 

โดย Michael Lewellen, Head of Solutions Engineering, Turnkey ได้แชร์มุมมองเกี่ยวกับการออกแบบ Wallet Infrastructure สำหรับองค์กร รวมถึงบทบาทของ Automation และ AI Agent ที่กำลังเข้ามามีส่วนในโครงสร้างพื้นฐานทางการเงินมากขึ้น 

Wallet ที่ปลอดภัย ไม่ได้หมายถึงแค่ Private Key ที่ปลอดภัย

Michael อธิบายว่า หนึ่งในความเข้าใจทั่วไปเกี่ยวกับ Wallet คือการมองว่า Wallet มีหน้าที่หลักในการเก็บ Private Key แต่เมื่อมองจากบริบทขององค์กร การรักษาความปลอดภัยจำเป็นต้องครอบคลุมมากกว่านั้น

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

ต่างจาก Personal Wallet ที่เจ้าของอาจมีสิทธิ์เต็มในการจัดการสินทรัพย์ของตัวเอง องค์กรจำเป็นต้องกำหนดบทาทหน้าที่ การยินยอมให้เข้าใช้ และ ขอบเขตและนโยบาย ที่ชัดเจน เพื่อควบคุมว่าใครสามารถเคลื่อนย้ายสินทรัพย์ จาก Wallet ใด ไปยัง Address ใด และภายใต้เงื่อนไขแบบไหน

แทนที่จะเพิ่มคนอนุมัติ ลองออกแบบสิทธิ์ให้ละเอียดขึ้น

วิธีหนึ่งที่องค์กรใช้ลดความเสี่ยงคือการกำหนดให้หลายคนร่วมกันอนุมัติธุรกรรม เช่น 2 ใน 3 คน หรือ 3 ใน 5 คน แต่หากทุกธุรกรรมต้องรอหลายคนอนุมัติ กระบวนการที่ควรจะช่วยเพิ่มความปลอดภัยก็อาจกลายเป็นเพิ่มภาระในการทำงาน

Michael จึงเสนออีกวิธีคิด คือแทนที่จะเพิ่มขั้นตอนให้กับทุกธุรกรรม เราสามารถกำหนด Policy ให้ละเอียดขึ้นตามลักษณะของงาน

ยกตัวอย่างเช่น หากบริษัทต้องจ่ายเงินให้คู่ค้ากลุ่มเดิมเป็นประจำ สามารถกำหนด Address เหล่านั้นเป็น Approved Addresses และให้พนักงานที่เกี่ยวข้องมีสิทธิ์ทำธุรกรรมได้ภายในวงเงินที่กำหนด

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

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

เมื่อ AI Agent สามารถทำธุรกรรมทางการเงินได้ ควรต้องกำหนดว่าอะไรคือสิ่งที่  “ห้ามทำ”

อีกหนึ่งประเด็นสำคัญของการสนทนาคือการนำ AI Agent มาใช้กับการทำธุรกรรมบนบล็อกเชน ม่ว่าจะเป็นการชำระเงิน การซื้อขายหลักทรัพย์  หรือการทำงานร่วมกับระบบแลกเปลี่ยนเงินตรากระจายศูนย์ 

Michael มองว่าหลักการในการควบคุม AI Agent ไม่ได้แตกต่างจากการกำหนดสิทธิ์ให้คนหรือ Software อื่นๆ มากนัก นั่นคือ ต้องเริ่มจากการกำหนดว่า Agent จำเป็นต้องทำอะไร และระดับความเสี่ยงสูงสุดที่องค์กรสามารถยอมรับได้คือเท่าไร

ตัวอย่างเช่น AI Agent สำหรับการซื้อขายสินทรัพย์ อาจได้รับสิทธิ์ซื้อขายสินทรัพย์บน Exchange ที่กำหนด แต่ไม่ควรมีสิทธิ์ถอนเงินออกจาก Exchange หรือโอนสินทรัพย์ไปยัง Address ใดก็ได้

Policy จึงทำหน้าที่เป็น กรอบควบคุมว่า AI สามารถทำงานอัตโนมัติได้มากน้อยแค่ไหน ส่วนธุรกรรมที่ต้องใช้สิทธิ์หรือมีความเสี่ยงสูงกว่า จะถูก ส่งต่อให้มนุษย์ตรวจสอบและอนุมัติก่อนดำเนินการ

แม้ AI จะเข้ามาช่วย Automate กระบวนการได้มากขึ้น แต่ Michael มองว่า Human-in-the-loop ยังคงมีความสำคัญ โดยเฉพาะในเรื่อง Accountability และการกำหนด Policy ตั้งแต่ต้น

บทเรียนจากการ Hack: วามปลอกภัยต้องถูกออกแบบเป็นหลาย Layer

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

หากองค์กรกำหนดไว้ว่า Wallet สำหรับใช้งานประจำ สามารถโอนสินทรัพย์ไปยัง Approved Addresses เท่านั้น Transaction ที่พยายามส่งเงินออกไปยัง Address อื่นก็สามารถถูกกีดกั้น หรือ ต้องการได้รับการอนุมัติเพิ่มเติม ได้ แม้ว่าผู้ใช้งานจะถูกหลอกให้อนุมัติ ธุรกรรม นั้นก็ตาม

หลักการสำคัญคือการไม่ให้บัญชีที่มีสิทธิ์สูงสุดถูกนำมาใช้งานประจำ โดยตรง แต่แยกฐานของผู้ใช้งาน สำหรับการจัดการ Policy และ Permissions ออกจากผู้ใช้งานที่ทำธุรกรรมในแต่ละวัน

สำหรับองค์กรที่กำลังเข้าสู่ Digital Asset เริ่มจากการสร้างความเข้าใจภายใน 

สำหรับสถาบันการเงินหรือองค์กรที่กำลังเริ่มต้นเข้าสู่ Digital Asset คำแนะนำของ Michael คือการเริ่มจากการทดลองก่อน และการสร้าง Domain Knowledge ภายในองค์กร

ทีมควรได้ทดลองใช้ เทคโนโลยีจริง ทำความเข้าใจความเสี่ยง และการดำเนินธุรกิจของตัวเอง ก่อนตัดสินใจว่าโครงสร้างพื้นฐาน และ การความคุมให้เกิดความปลอดภัย แบบใดเหมาะกับการนำไปใช้งานในระดับ Production อีกหนึ่ง สิ่งสำคัญคือการเลือกระหว่าง Non-custodial และ Custodial Model

รูปแบบ Non-custodial ช่วยให้องค์กรสามารถควบคุม Wallet ได้มากขึ้น แต่ก็มาพร้อมกับความรับผิดชอบในการดูแล ความปลอดภัย การเข้าถึง และการกู้คืน ด้วยตัวเอง ขณะที่การใช้ Custodian หรือผู้ให้บริการรับฝากสินทรัพย์ สามารถช่วยลดภาระบางส่วนได้ แต่ในขณะเดียวกัน องค์กรก็ต้องพึ่งพา ความปลอดภัยและความพร้อมใช้งานของระบบ ของผู้ให้บริการด้วย

เมื่อโครงสร้างพื้นฐานของ Digital Asset เริ่มเชื่อมโยงทั้งคน Software และ AI Agent มากขึ้น การรักษาความปลอดภัยของ Wallet จึงไม่ได้มีเพียงคำถามว่า “Private Key ถูกเก็บไว้อย่างปลอดภัยหรือไม่” แต่รวมถึงการออกแบบว่า ใครหรือระบบใดมีสิทธิ์ทำอะไรได้บ้าง ภายใต้เงื่อนไขใด และเมื่อไรที่จำเป็นต้องมีการตรวจสอบเพิ่มเติม

Policy Engine และ Guardrails จึงเป็นกลไกสำคัญที่ช่วยให้องค์กรสามารถ ทำงานแบบอัตโนมัติได้มากขึ้น โดยยังคงกำหนดขอบเขต ควบคุมสิทธิ์ และรักษาความปลอดภัยให้เหมาะสมกับการใช้งานในระดับสถาบัน

ติดตามบทสนทนาฉบับเต็มจากเซสชันได้ที่ https://youtu.be/9RqYXN5QMLs?si=Iv-bNLMLRq-hFDzB 

----------------------

ที่มา :

เรียบเรียงจาก  Session:“Wallet Control in Production: Policy Engines, Automation, and Institutional-Grade Guardrails” ใน REDeFiNE TOMORROW 2026