ความปลอดภัยของ AI agent เริ่มต้นด้วยกฎข้อเดียว: AI agent ของคุณไม่ควรถือข้อมูลรับรองของคุณ นี่คือรูปแบบโบรกเกอร์อายุ 38 ปีที่บังคับใช้กฎนี้
AI agent คือรองผู้มีอำนาจที่สับสน นี่คือรูปแบบความปลอดภัยอายุ 38 ปี และคำตอบก็เก่าแก่พอ ๆ กัน: วาง โบรกเกอร์ — ชั้นกลางที่เชื่อถือได้ ตรวจสอบได้ กำหนดนโยบายได้ มีขอบเขตจำกัด ไม่ใช่ AI และไม่สามารถปลอมแปลงได้ — ระหว่าง agent กับ SaaS API ที่ต้องเรียก โดยให้โบรกเกอร์ถือข้อมูลรับรองที่ agent ไม่ควรมี
ในปี 1988 Norm Hardy ตีพิมพ์บทความสั้น เล่าถึงเหตุการณ์จริงสมัยทำงานที่ Tymshare คอมไพเลอร์ Fortran ชื่อ FORT อยู่ในไดเรกทอรีระบบชื่อ SYSX เพื่อเก็บสถิติการใช้งาน คอมไพเลอร์ต้องเขียนข้อมูลไปยัง (SYSX)STAT ระบบปฏิบัติการจึงให้ FORT มี "home files license" อนุญาตให้เขียนไฟล์ใดก็ได้ใน SYSX ไฟล์บิลลิ่งของระบบ (SYSX)BILL ก็อยู่ที่นั่นเช่นกัน ผู้ใช้สามารถระบุชื่อไฟล์เพื่อรับ debug output ได้ วันหนึ่งผู้ใช้ระบุ (SYSX)BILL คอมไพเลอร์ขอให้ OS เปิดไฟล์นั้นเพื่อเขียน OS เห็นว่า home files license อนุญาตจึงยอมให้เขียน ข้อมูลบิลลิ่งถูกเขียนทับ คอมไพเลอร์ทำตามหน้าที่ที่ออกแบบไว้ ข้อบกพร่องอยู่ที่สถาปัตยกรรม
Hardy เรียกสิ่งนี้ว่า ปัญหารองผู้มีอำนาจสับสน (confused deputy problem): โปรแกรมที่มีสิทธิ์ (รองผู้มีอำนาจ) ถืออำนาจของตัวเอง ผู้ใช้ที่มีสิทธิ์น้อยกว่าขอให้ทำบางอย่าง รองผู้มีอำนาจสับสนว่าใช้อำนาจของใคร และใช้ของตัวเอง วิธีแก้คือถอดอำนาจนั้นออกจากรองผู้มีอำนาจ แล้ววางไว้หลังชั้นกลางที่คอยกลั่นกรองการเรียกใช้งาน นั่นคือโบรกเกอร์
สามสิบแปดปีต่อมา ทุก AI agent ที่บริษัทของคุณรันอยู่ก็คือรองผู้มีอำนาจที่สับสน และส่วนใหญ่ก็รันโดยไม่มีโบรกเกอร์
ทำไม AI agent ทำให้ปัญหาความปลอดภัยแย่ลง
FORT ของ Hardy มีช่องทางรับข้อมูลเข้าเพียงช่องเดียว: คำสั่งบรรทัดคำสั่ง AI agent สมัยใหม่มีหลายสิบช่องทาง: เนื้อหาอีเมล หน้าเว็บที่ดึงมา PDF ที่อัปโหลด ผลลัพธ์เครื่องมือจากเซิร์ฟเวอร์ MCP ข้อความจาก agent อื่นในระบบหลาย agent อะไรก็ตามที่เข้ามาใน context window สามารถออกคำสั่งได้ และโดยการออกแบบ agent จะถือว่าทั้งหมดถูกต้อง
นั่นทำให้สมมติฐานที่ระบบควบคุมสิทธิ์แบบเดิมพึ่งพาแตกต่างออกไป: ผู้เรียกควบคุมอินพุต ในเว็บแอป ผู้เรียก (session ที่ยืนยันตัวตนแล้ว) กับอินพุต (HTTP request body) มาจากที่เดียวกัน สำหรับ agent ผู้เรียกคือใครก็ตามที่กำหนด prompt ซึ่งหมายความว่าแฮกเกอร์ที่เขียนอีเมลหรือฝังผลการค้นหาก็เป็นผู้เรียกได้
ในเดือนพฤศจิกายน 2025 นักวิจัยความปลอดภัยที่ PromptArmor สาธิต ว่าสิ่งนี้เกิดขึ้นจริงอย่างไร พวกเขาซ่อนคำสั่งอันตรายในฟอนต์ขนาด 1 พิกเซลบนคู่มือการเชื่อมต่อ เมื่อผู้พัฒนาชี้ Google Antigravity IDE ไปที่นั้น agent ก็ข้ามการป้องกันไฟล์แบบ .gitignore ของตัวเองด้วยการ shell ไปที่ cat จากนั้นจึงรั่วข้อมูลไฟล์ .env ไปยัง URL webhook.site ที่ผู้โจมตีควบคุมผ่าน subagent เบราว์เซอร์ของ Antigravity ผู้ใช้ตั้งค่าทุกอย่างถูกต้อง sandbox ก็ทำงาน Agent แค่แยกไม่ออกว่าผู้ใช้สั่งอะไรกับสิ่งที่อินพุตบอกให้ทำ
รูปแบบเดียวกับ FORT ของ Hardy แม้เวลาจะผ่านไปหลายสิบปี: อำนาจกว้าง อินพุตไม่น่าเชื่อถือ ไม่มีทางแยกสองสิ่งนี้ออกจากกัน
ชุมชนมีคำตอบ แต่กระจัดกระจาย
นี่ไม่ใช่ปัญหาใหม่ วงการความปลอดภัยเขียนคำตอบไว้หลายสิบปี:
ความปลอดภัยแบบ capability-based (Dennis & Van Horn, 1966; ต่อมาคือภาษา E และงาน Caja ของ Mark Miller ที่ Google) หลักการ: อย่าให้อำนาจโดยอาศัยตัวตนหรือที่ตั้ง ให้ส่ง capability ที่ระบุชัดเจนและปลอมไม่ได้สำหรับแต่ละ resource ที่โปรแกรมอนุญาตให้เข้าถึง capability จะรวม สิ่งที่ทำได้ กับ สิ่งที่ทำได้กับอะไร และไม่สามารถสับสนกับอย่างอื่นได้
Brokered Credentials (บัญญัติโดย OWASP LLM Top 10) อย่าใส่ API token ใน context ของ LLM ให้ชั้นกลางที่เชื่อถือได้เป็นผู้เรียก API แทน agent โมเดลตัดสินใจ จะทำอะไร โบรกเกอร์จัดการ ทำอย่างไร หาก prompt injection ขอให้โมเดลแสดงข้อมูลรับรอง ก็จะไม่ได้อะไร เพราะข้อมูลรับรองไม่ได้อยู่ที่นั่น
Phantom Token Pattern (Curity, เดิมสำหรับ OAuth ใน microservices) agent ถือ session handle ที่อ่านไม่ออก ไม่ใช่ bearer token จริง proxy จะตรวจสอบ handle สลับเป็นข้อมูลรับรองจริงที่ขอบเครือข่าย แล้วส่งต่อ upstream ถ้า agent รั่ว environment ผู้โจมตีจะได้สตริงที่หมดอายุเมื่อ session จบ
Just-in-time credential injection (ระบบ workload identity เช่น Aembit) ออกข้อมูลรับรองอายุสั้นและขอบเขตแคบต่อการเรียกแต่ละครั้ง แทนที่จะออก token อายุยาว
สิ่งเหล่านี้ไม่ได้หายไปจากตำรา แต่มันหายไปจากค่าตั้งต้น แพลตฟอร์ม agent ส่วนใหญ่ยังคงส่ง OAuth token ให้โมเดลโดยไม่มีโบรกเกอร์คั่นกลาง แล้วหวังว่าทุกอย่างจะปลอดภัย
โบรกเกอร์ของ Zero ทำงานอย่างไร
เราไม่ได้คิดค้นรูปแบบข้างต้น แต่เรานำมารวมเป็น โบรกเกอร์ เดียวที่รันเป็นค่าตั้งต้นสำหรับ agent ทุกตัวบน Zero มันคือชั้นกลางที่เชื่อถือได้ตามที่รูปแบบเหล่านั้นอธิบาย สร้างขึ้นสำหรับแพลตฟอร์ม AI agent ทุกการเรียกที่ agent ทำไปยัง connector จะผ่านโบรกเกอร์นี้ แต่ละ connector คือ SaaS ภายนอกหนึ่งตัว (Slack, GitHub, Notion ฯลฯ)
โบรกเกอร์อยู่ระหว่าง agent กับ connector ทุกตัว ข้อมูลรับรองจริงอยู่ฝั่งโบรกเกอร์เท่านั้น
คิดเป็นสามชั้น
1. การแยกข้อมูลรับรอง
sandbox ของ agent ไม่เคยถือข้อมูลรับรอง connector จริง เมื่อคุณเชื่อมต่อ SaaS กับ Zero OAuth token หรือ API key จะอยู่ฝั่งโบรกเกอร์ sandbox จะได้ placeholder ที่ดูเหมือน environment secret พอให้เครื่องมือเดิมทำงานต่อได้ แต่ SaaS upstream จะไม่ยอมรับ
เมื่อ agent ส่งคำขอไปยัง host ของ connector ที่ลงทะเบียนไว้ โบรกเกอร์จะจับคู่คำขอ แก้ไข template การยืนยันตัวตนของ connector และแทรกข้อมูลรับรองจริงที่ขอบเครือข่าย คำขอจะถูกส่ง upstream พร้อม auth ที่ถูกต้อง agent ไม่เคยถือข้อมูลสำคัญ หาก agent ถูก prompt injection แล้ว dump environment variable ผู้โจมตีจะได้ placeholder ไม่ใช่ SaaS token
นี่คือ phantom token pattern ที่นำมาใช้กับ AI agent
2. ประตู policy ของ connector
connector ใน Zero ควรเป็นมากกว่าสวิตช์เปิด/ปิด แต่ละ connector จะอธิบาย API base ที่ครอบคลุมและวิธี inject auth หาก upstream service เผยแพร่ mapping scope-to-endpoint ที่เสถียร ก็สามารถอธิบายได้ว่า permission ใดครอบคลุมแต่ละ method และ path ตัวอย่างที่ดีคือ slack-api-ref ของ Slack
ดังนั้นเมื่อ agent ที่เชื่อมต่อกับ Slack เรียก chat.postMessage โบรกเกอร์จะจับคู่คำขอกับ chat:write เมื่ออ่าน audit log นั่นคือ admin.analytics:read สำหรับแต่ละ agent permission_policies จะกำหนดว่า permission เหล่านั้นทำงานอย่างไร: อนุญาต ปฏิเสธ หรือถาม นโยบายจะถูกบังคับใช้ที่โบรกเกอร์ก่อน inject auth ไม่ใช่แค่เป็น hint ให้โมเดล หาก agent พยายามเรียกที่ถูกปฏิเสธ (เช่นถูก prompt injection) คำขอจะไม่ถึง upstream
ไม่ใช่ทุก connector จะได้ mapping นี้ในวันนี้ บาง API upstream ไม่เผยแพร่ mapping scope-to-endpoint ที่เสถียร GitHub GraphQL คือกรณีตัวอย่าง: REST mapping ได้ แต่ GraphQL ยังไม่ได้ สำหรับ connector เหล่านี้ โบรกเกอร์ยังคงควบคุมการ inject ข้อมูลรับรองและเส้นทางเครือข่าย ขณะที่ policy จะ fallback ไปที่ระดับ connector หรือ host ตามที่แพลตฟอร์มบังคับใช้ได้ เราเติมข้อมูลเหล่านี้เมื่อ upstream มีข้อมูล ไม่อ้างสิทธิ์ที่ยังไม่ได้สร้าง
Token จะไม่ให้อำนาจโดยรอบ อำนาจจะถูกโบรกเกอร์ต่อ agent ตามความละเอียดที่ upstream รองรับ นี่คือครึ่งหนึ่งของคำตอบแบบ capability-based
3. ลูปปฏิบัติการและ audit
Least privilege จะใช้ได้ก็ต่อเมื่อโหมดล้มเหลวใช้งานได้จริง agent เติบโตขึ้น หกสัปดาห์ผ่านไป agent วิจัยที่เริ่มจากอ่าน Notion อาจต้องเขียนสรุปกลับ ความล้มเหลวที่พบบ่อย: agent รันต่อโดยไม่มี permission ใหม่แล้วพัง หรือ operator ให้สิทธิ์เกินในภาวะฉุกเฉินแล้วไม่เคยลดสิทธิ์กลับ
คำขอ connector ที่ถูกปฏิเสธจะคืนค่า 403 ที่มีโครงสร้าง: connector, method, path, base URL และชื่อ permission ที่ตรงเมื่อโบรกเกอร์ระบุได้ system prompt ของ agent จะบอกวิธีวิเคราะห์การปฏิเสธและวิธีขอ permission ที่เพิ่งถูกปฏิเสธ พร้อม URL อนุมัติสิทธิ์แบบคลิกเดียวสำหรับผู้ใช้หรือ admin ทำให้เส้นทางขอสิทธิ์ผูกกับ permission ที่ร้องขอจริง แทนที่จะกลายเป็น "ให้สิทธิ์ทุกอย่าง"
คำขอเปลี่ยน permission จะอยู่ในคิว เจ้าของและ admin อนุมัติหรือปฏิเสธได้จากแดชบอร์ด เมื่ออนุมัติ agent จะได้ policy ใหม่และ retry ครั้งถัดไปจะผ่าน แพลตฟอร์มส่วนใหญ่ข้ามลูปนี้ ถ้าไม่มี "least privilege" ก็เป็นแค่สไลด์ ไม่ได้รันจริง
เส้นทางโบรกเกอร์เดียวกันนี้ใช้สำหรับ audit log ด้วย log เครือข่ายต่อ run จะบันทึกกิจกรรม sandbox ทั้ง HTTP, TCP, DNS และ packet ระดับล่างสำหรับทราฟฟิกที่ไม่ใช่ TCP คำขอที่ตรงกับ connector จะมี metadata โบรกเกอร์: connector, permission ที่ตรง (ถ้ามี), ผล allow/deny, ข้อมูล auth resolution และ billable flag หากมีคนถาม "agent นี้ทำอะไรวันอังคาร 3 โมง?" คุณสามารถย้อนดูจาก log ได้ การป้องกันอาจพลาด แต่ audit trail จะบอกคุณว่าเกิดอะไรขึ้น
สิ่งที่เรายังแก้ไม่ได้
แม้จะมีทั้งหมดข้างต้น agent ที่มี chat:write อย่างถูกต้องก็ยังอาจถูกชักจูงให้โพสต์ข้อความน่าอายไปยัง channel ที่มีสิทธิ์อยู่แล้ว โบรกเกอร์ช่วยลดขอบเขตความเสียหาย แต่ไม่สามารถกำจัดได้
อีกครึ่งหนึ่งของคำตอบคือการอนุมัติ action สำคัญ การตรวจสอบ output และถือว่า tool return ไม่น่าเชื่อถือโดยปริยาย งานเหล่านี้อยู่ในแผน ยังไม่ได้อยู่ในผลิตภัณฑ์ ใครที่อ้างว่าแก้ confused deputy ได้ครบวงจร กำลังขายของ
สิ่งเหล่านี้ควรเป็นมาตรฐาน ไม่ใช่ฟีเจอร์
ความปลอดภัยแบบ capability-based มีมาตั้งแต่ยุค 1970 Brokered credentials อยู่ใน OWASP LLM Top 10 Phantom token มีมาก่อนยุค LLM ทั้งหมดนี้ไม่ได้หายไปเพราะไม่มีใครรู้คำตอบ แต่มันหายไปเพราะแพลตฟอร์ม agent รุ่นแรกเน้น "ให้เดโมทำงาน" แล้วผลักความปลอดภัยไป release ถัดไปซึ่งมักไม่เกิดขึ้น
แพลตฟอร์มรุ่นต่อไปควรตั้งเป้าสูงกว่า Token ไม่ควรเข้า context ของโมเดล อำนาจควรถูกแจกแจงต่อ agent การขอสิทธิ์เพิ่มควรผ่านมนุษย์ ทุก action ควร audit ได้ครบวงจร ทั้งหมดนี้ไม่ใช่เรื่องใหม่ แต่ควรเป็นมาตรฐาน
เมื่อคุณเลือกแพลตฟอร์ม agent คำถามว่า "ปลอดภัยไหม?" ไม่มีประโยชน์ ทุกเจ้าตอบว่าใช่ คำถามที่ดีกว่า: แสดงโบรกเกอร์ของคุณ แล้วอธิบายให้ดูว่าเกิดอะไรขึ้นเมื่อ agent ขอ scope ที่ไม่มี
โบรกเกอร์อยู่หน้าทุก agent บน Zero โดยอัตโนมัติ รายการ connector, mapping scope, นโยบาย permission และตรรกะโบรกเกอร์ทั้งหมดอยู่ใน ซอร์สโค้ดของ Zero เจอ connector ที่เรายังไม่รองรับ? แจ้ง issue ได้เลย
อ้างอิง
พื้นฐาน
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (ต้นกำเนิด capability-system)
- Mark Miller et al., Caja: ความปลอดภัยแบบ capability สำหรับเว็บ, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
เหตุการณ์จริงที่อ้างถึง
- PromptArmor, Google Antigravity Exfiltrates Data, พฤศจิกายน 2025
- Simon Willison, การรายงานและวิเคราะห์, 25 พฤศจิกายน 2025
