โมเดลและแพลตฟอร์ม AI
Linux Foundation เปิดตัว Agent Name Service เพื่อยืนยันตัวตนของเอเจนต์ AI

Linux Foundation ประกาศเมื่อวันที่ 10 พฤศจิกายน 2026 ว่า Agent Name Service (ANS) เปิดตัวอย่างเป็นทางการในฐานะโครงการของมูลนิธิ โดยนำเสนอการระบุตัวตนที่ผูกกับโดเมน การค้นหา และการยืนยันตัวตนสำหรับเอเจนต์ AI ผ่านข้อกำหนดแบบเปิดและเครื่องมือโอเพนซอร์ส
ANS ออกแบบมาเพื่อให้ระบบตรวจสอบได้ว่ากำลังติดต่อกับเอเจนต์ที่ลงทะเบียนรายใด ก่อนจะใช้นโยบายความปลอดภัยของตนเอง ระบบผูกชื่อที่ระบุเวอร์ชันไว้กับโดเมนที่ผู้ดำเนินการเอเจนต์ควบคุม ใช้ Domain Name System (DNS) เผยแพร่ข้อมูลสำหรับการค้นหา และบันทึกเหตุการณ์ตลอดวงจรการใช้งานที่มีการลงนามไว้ในบันทึกความโปร่งใส แนวทางนี้นำโครงสร้างพื้นฐานอินเทอร์เน็ตที่มีอยู่มาใช้ซ้ำ แทนที่จะกำหนดให้ต้องมีทะเบียนเอเจนต์แบบกรรมสิทธิ์เฉพาะรายเดียว
การเปิดตัวครั้งนี้ต่อยอดจากประกาศเจตจำนงของมูลนิธิเมื่อวันที่ 23 มิถุนายน 2026และยกระดับให้เป็นโครงการที่มีระบบกำกับดูแล มูลนิธิระบุว่ามีองค์กร 11 แห่งร่วมพัฒนาหรือนำ ANS ไปใช้ตั้งแต่นั้น ได้แก่ Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP และ Trustmodel.ai
การลงทะเบียนและการยืนยันตัวตนด้วย ANS ทำงานอย่างไร
ข้อกำหนดเจ็ดชั้นครอบคลุมการระบุตัวตน การลงทะเบียน การตั้งชื่อที่ระบุเวอร์ชัน การเผยแพร่ผ่าน DNS ความโปร่งใส การตรวจสอบความถูกต้องครบถ้วน และการยืนยันตัวตนของเอเจนต์ ชื่อ ANS ผูกเวอร์ชันเข้ากับโดเมน ดังเช่น ans://v1.0.0.payments.example.com; เวอร์ชันใหม่ต้องลงทะเบียนใหม่
ระหว่างการลงทะเบียน ผู้ดำเนินการจะส่งโฮสต์ของเอเจนต์ เวอร์ชัน ปลายทาง และข้อมูลใบรับรองไปยังหน่วยงานรับลงทะเบียน ซึ่งจะตรวจสอบการควบคุมโดเมนและหลักฐานที่กำหนด จากนั้นผู้ดำเนินการเผยแพร่ระเบียน DNS ที่ได้รับกลับมา และหน่วยงานจะตรวจสอบระเบียนเหล่านั้นก่อนเปิดใช้งาน ต่อมาหน่วยงานจะลงนามในเหตุการณ์ตลอดวงจรการใช้งาน และให้บันทึกความโปร่งใสประทับรับรองเหตุการณ์นั้น เพื่อสร้างหลักฐานสาธารณะที่ผูกการลงทะเบียนเข้ากับใบรับรองที่ได้รับอนุญาต
เพียร์ใช้โปรไฟล์การค้นหาที่รองรับเพื่อค้นหาปลายทางและบันทึก _ans-badge ที่ใช้ร่วมกันเพื่อค้นหาหลักฐานความโปร่งใส การค้นหาเพียงอย่างเดียวไม่ได้ยืนยันตัวตนของผู้เรียกใช้ การยืนยันตัวตนต้องผ่านการตรวจสอบสามข้อ ได้แก่ ใบรับรองผูกกับข้อมูลระบุตัวตนที่ลงทะเบียนไว้ การลงทะเบียนยังคงมีผล และผู้เรียกใช้ถือครองกุญแจส่วนตัวที่ตรงกัน
ร่างข้อกำหนดการยืนยันตัวตน ANS-6ให้ความสำคัญเท่าเทียมกันกับ mutual TLS (mTLS) และ Demonstrating Proof of Possession (DPoP) ในชั้นแอปพลิเคชัน mTLS เหมาะกับเส้นทาง TLS แบบต้นทางถึงปลายทาง ส่วน DPoP ผูกหลักฐานที่ใช้ได้ครั้งเดียวเข้ากับคำขอ HTTP และยังใช้งานได้ผ่านเกตเวย์ที่ยุติการเชื่อมต่อ TLS ตัวตรวจสอบระดับแบดจ์จะสอบถามบันทึกความโปร่งใสเพื่อดูหลักฐานล่าสุด ส่วนระดับ SCITT จะตรวจสอบใบรับรองรับรองและโทเคนสถานะภายในเครื่อง โดยไม่ต้องเชื่อมต่อเครือข่ายทุกครั้งที่มีคำขอ DPoP ต้องใช้การผูกข้อมูลแบบ SCITT
ซอฟต์แวร์และการทำงานร่วมกันในระยะแรก
ซอฟต์แวร์ที่พร้อมใช้งานประกอบด้วยซอฟต์แวร์อ้างอิงที่เขียนด้วย Go สำหรับหน่วยงานรับลงทะเบียน บันทึกความโปร่งใส และตัวตรวจสอบแบบออฟไลน์ รวมถึง SDK สำหรับ Go, Rust และ Java ซึ่งมี API และขอบเขตความสามารถแตกต่างกัน โดย ans-cli เครื่องมือนี้รองรับการลงทะเบียน การค้นหา การจัดการใบรับรอง และการสอบถามบันทึกความโปร่งใสบน macOS, Linux และ Windows ส่วนคู่มือเริ่มต้นใช้งานภายในเครื่องใช้กุญแจสำหรับการพัฒนาและ noop ตัวตรวจสอบ DNS ซึ่งหมายความว่าการตรวจสอบใบรับรองรับรองที่ผ่านไม่ได้ทดสอบ DNS สาธารณะ การออกใบรับรองสำหรับระบบใช้งานจริง หรือการติดตั้งใช้งานจริง
ด้านการทำงานร่วมกัน Linux Foundation รายงานว่า Agent Directory Service ของ AGNTCY รองรับการตรวจสอบข้อมูลระบุตัวตน ANS และ ANS Finder ใช้ Agentic Resource Discovery (ARD) พร้อมผ่านการทดสอบความสอดคล้องกับทะเบียน ข้อกำหนดของ ARD เองมุ่งเน้นการค้นหาก่อนเรียกใช้งาน ไม่ใช่การดำเนินการ และเปิดให้มีบริการค้นหาหลายรายที่ใช้นโยบายด้านความน่าเชื่อถือ การจัดอันดับ และการเข้าถึงแตกต่างกัน แทนที่จะกำหนดให้ใช้แค็ตตาล็อกกลาง แนวทางนี้เชื่อมโยงหลักฐานยืนยันตัวตนที่ตรวจสอบได้เข้ากับการค้นหา โดยไม่สร้างไดเรกทอรีเอเจนต์สากลขึ้นมา
ร่างข้อกำหนดและขอบเขตด้านความปลอดภัย
คณะกรรมการกำกับดูแลด้านเทคนิคชุดแรกมีสมาชิกที่มีสิทธิออกเสียงห้าคน ได้แก่ Scott Courtney, Keith Perry และ Connor Snitker จาก GoDaddy, Ken Huang จาก DistributedApps.AI และ Michael Kantor จาก Hashgraph Online คณะกรรมการกำหนดทิศทางด้านเทคนิค ขณะที่ผู้ดูแลคลังซอร์สจะตรวจทานการเปลี่ยนแปลง จัดการการเผยแพร่รุ่น และรับมือกับรายงานด้านความปลอดภัย แม้เอกสารเผยแพร่ตอนเปิดตัวจะระบุว่าข้อกำหนดผ่านการจัดทำเป็นทางการแล้ว แต่เอกสารโครงการระบุว่าข้อกำหนดที่เผยแพร่ยังเป็นฉบับร่างและอยู่ระหว่างการพัฒนา โดย ANS-6 ระบุว่า DRAFT v1.0 เวอร์ชัน 0.2.0 ลงวันที่ 3 พฤศจิกายน 2026
แบบจำลองความปลอดภัยใช้เพื่อยืนยันตัวตน ไม่ใช่กำหนดสิทธิ์ การอนุญาต การมอบสิทธิ์ต่อเนื่องตลอดสายการเรียกใช้ และการให้คะแนนความน่าเชื่อถืออยู่นอกขอบเขตของ ANS-6 ทำให้แต่ละแอปพลิเคชันต้องตัดสินใจเองว่าเอเจนต์ที่ผ่านการยืนยันตัวตนแล้วทำอะไรได้บ้าง แฮชข้อมูลเมตาที่ประทับรับรองไม่ได้ยืนยันโค้ดที่ทำงานอยู่บนเครื่องระยะไกล และไม่ได้รับประกันพฤติกรรมของเอเจนต์ อีกทั้งไคลเอนต์ยังต้องใช้กุญแจบันทึกที่เชื่อถือได้ ตรวจสอบลายเซ็นและหลักฐานให้ถูกต้อง ตรวจสอบความใหม่ของข้อมูล และกำหนดนโยบายเมื่อเกิดข้อผิดพลาดด้วย นอกจากนี้ แบดจ์ ใบรับรองรับรอง และโทเคนสถานะสาธารณะอาจถูกนำกลับมาใช้ซ้ำได้ หากตัวตรวจสอบละเว้นการตรวจสอบการครอบครองกุญแจ
ใบรับรองยืนยันประวัติในบันทึก ไม่ใช่สถานะความถูกต้องในปัจจุบัน และยังใช้ตรวจสอบต่อไปได้แม้เพิกถอนตัวแทน AI แล้ว จึงต้องใช้ควบคู่กับการตรวจสอบสถานะปัจจุบัน ระดับความพร้อมของการผสานรวมยังแตกต่างกันด้วย งาน NVIDIA OpenShell ระบุว่าเป็นรุ่นตัวอย่างเพื่อการวิจัย และการตรวจสอบการลงทะเบียนปลายทางของงานนี้ไม่ได้ผูก ANS-6 เข้ากับใบรับรอง TLS ของคู่สื่อสารจริง
ขณะนี้ ANS มีกลไกกำกับดูแลโดยมูลนิธิ ร่างมาตรฐานที่เผยแพร่แล้ว และชุดอ้างอิงสำหรับการนำไปใช้ คุณค่าด้านความปลอดภัยในทางปฏิบัติขึ้นอยู่กับการที่ระบบติดตั้งใช้งานบังคับใช้การยืนยันตัวตน สถานะปัจจุบัน และการครอบครองกุญแจร่วมกัน พร้อมทั้งไม่นำการอนุญาตและการประเมินพฤติกรรมของตัวแทน AI มาเป็นส่วนหนึ่งของการอ้างสิทธิ์ด้านอัตลักษณ์












