Cloudflare OS คืออะไร? การออกแบบสิทธิ์ของ AI Agent ภายในองค์กรและกลไกของ Gatekeeper

Cloudflare OS คือแพลตฟอร์มโอเพนซอร์สที่ช่วยให้พนักงานทุกคนในองค์กรสามารถใช้งาน AI Agent และพื้นที่ทำงาน (Workspace) สำหรับการทำงาน โดยสามารถเชื่อมต่อกับระบบหลัก (Core Systems) เพื่อมอบหมายงานให้ทำได้โดยยังคงยึดตามคำศัพท์และขั้นตอนการทำงานของบริษัท Cloudflare ได้ปรับปรุงโครงสร้างพื้นฐานภายในที่ตนเองใช้งานอยู่ และเปิดตัวบน GitHub ภายใต้สัญญาอนุญาต Apache License 2.0 เมื่อวันที่ 5 สิงหาคม 2026 (Cloudflare Official Blog เข้าถึงเมื่อวันที่ 26 สิงหาคม 2026)

สรุปใจความสำคัญของผลิตภัณฑ์นี้คือ "การที่แพลตฟอร์มเป็นผู้รับผิดชอบการออกแบบสิทธิ์ (Permission Design) ในการให้ Agent เข้าถึงระบบภายใน แทนที่จะปล่อยให้เป็นหน้าที่ของผู้พัฒนาแอปพลิเคชันแต่ละตัว" อย่างไรก็ตาม เนื่องจากทางผู้พัฒนาได้ระบุเองว่าสถานะปัจจุบันเทียบเท่ากับ "early access" การทดสอบในวงจำกัดจึงเป็นแนวทางที่สมเหตุสมผลมากกว่าการนำไปใช้งานจริงทั่วทั้งองค์กรในขณะนี้

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

Cloudflare OS ไม่ใช่แค่เครื่องมือ AI แชทแบบเดี่ยว แต่เป็นแพลตฟอร์มที่รวมเอา Agent, Security และ App เข้าไว้ด้วยกัน โดยจะอธิบายตั้งแต่ส่วนประกอบ ความแตกต่างจาก AI แชทภายในองค์กรที่มีอยู่เดิม ไปจนถึงวิธีการใช้งานจริงภายในบริษัท Cloudflare

บล็อกอย่างเป็นทางการอธิบาย Cloudflare OS ว่าเป็นการรวมกันของ 3 ส่วนประกอบต่อไปนี้ ซึ่งการแบ่งส่วนนี้จะเป็นโครงสร้างหลักของเนื้อหาหลังจากนี้

ประเด็นสำคัญอยู่ที่คอลัมน์ที่ 3 โดยเฉพาะการออกแบบในบรรทัดที่ 2 ที่ว่า "แพลตฟอร์มจะเป็นผู้รับผิดชอบ" ซึ่งจะเชื่อมโยงไปสู่ Gatekeeper และบันทึกการสังเกตการณ์ (Observability) ที่จะกล่าวถึงในภายหลัง ตัว Workspace เองนั้นเป็นการรวมเอาบทสนทนา, สถานะที่บันทึกไว้, ผลลัพธ์ที่ได้, สิทธิ์การเข้าถึงปลายทาง และสภาพแวดล้อมแบบแยกส่วน (Isolated environment) ที่สามารถเขียนและรันโค้ดได้เข้าไว้ด้วยกัน

สำหรับบริษัทที่แจกจ่าย AI Chat ให้พนักงานทั้งองค์กรใช้งานอยู่แล้ว ตำแหน่งของ Cloudflare OS อาจดูเข้าใจยาก โดยมีความแตกต่างอยู่ 3 ประการ ดังนี้:

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

ประการที่สอง มีเส้นทางในการเข้าถึงระบบหลัก (Core System) เตรียมไว้ให้ตั้งแต่ต้น โดยมาพร้อมกับ Gatekeeper (ผู้เฝ้าประตูสำหรับแต่ละบริการ ซึ่งจะกล่าวถึงในภายหลัง) เพื่อควบคุมการเข้าถึงผ่านเส้นทางที่ถูกกำกับดูแล และยังสามารถเชื่อมต่อกับ MCP (Model Context Protocol) Server ที่มีอยู่เดิมผ่าน MCP Server Portals ได้อีกด้วย

ประการสุดท้าย มีช่องทางที่ไม่จำเป็นต้องเรียกใช้โมเดลทุกครั้ง งานประจำส่วนใหญ่มักมีจุดที่ต้องใช้การตัดสินใจเพียง 1-2 จุด ส่วนที่เหลือเป็นขั้นตอนที่ตายตัว Cloudflare OS สามารถเปลี่ยนงานเหล่านั้นให้เป็น "เวิร์กโฟลว์แบบเกือบกำหนดได้" (nearly deterministic workflow) ซึ่งจะประมวลผลส่วนที่คาดการณ์ได้ด้วยโค้ด โดยสามารถเลือกการเริ่มต้นทำงานได้ทั้งแบบกำหนดเอง (Manual), ตามตารางเวลา (Schedule) หรือจากเหตุการณ์ (Event) ของระบบที่เชื่อมต่ออยู่

สิ่งที่ใช้เป็นเกณฑ์ในการตัดสินคือตัวเลขการดำเนินงานภายในที่ Cloudflare เปิดเผยด้วยตนเอง ตามคำกล่าวของ Sam Rhea ซึ่งเป็น CIO ระบุว่าพนักงานหลายพันคนใช้แพลตฟอร์มนี้ทุกสัปดาห์ และจำนวนผู้ใช้งานต่อวันก็เพิ่มขึ้นในทุกวันทำการ บริษัทประเมินว่าในช่วง 1 เดือนที่ผ่านมา เฉพาะทีมขายเพียงทีมเดียวสามารถลดเวลาการทำงานด้วยมือไปได้มากกว่า 10,000 ชั่วโมง และในช่วง 30 วันเดียวกันนั้น ผู้ใช้งานได้สร้างแอปพลิเคชันและเครื่องมือไปมากกว่า 4,000 รายการ (Cloudflare CIO Blog, วันที่อ้างอิง 26 สิงหาคม 2026) อย่างไรก็ตาม 10,000 ชั่วโมงเป็นค่าที่บริษัทระบุชัดเจนว่าเป็น "การประมาณการ" และวิธีการคำนวณไม่ได้ถูกเปิดเผยต่อสาธารณะ

วิธีการใช้งานจะแตกต่างกันไปตามประเภทของงาน ในส่วนของฝ่ายขายจะเน้นไปที่การวางแผนพื้นที่การขายและการจัดทำข้อเสนอ ส่วนตัวอย่างของฝ่าย IT Helpdesk นั้นมีความเฉพาะเจาะจงมากกว่า Rhea เขียนไว้ว่าตัวเขาเองเคยต้องดาวน์โหลดไฟล์ CSV ทุกเช้าเพื่อนำมาสร้างกราฟในโปรแกรมตารางคำนวณ และต้องเปิดอ่านตั๋วที่เข้ามาในช่วงกลางคืนทีละรายการด้วยตนเอง แต่ปัจจุบันได้เปลี่ยนมาใช้แดชบอร์ดที่สร้างโดยเอเจนต์และร่างคำตอบด้วย AI แทน ในส่วนของการจัดซื้อ การวินิจฉัยปัญหาคอขวดที่เคยต้องใช้เวลาหลายวันในการไล่ดูตารางคำนวณ ปัจจุบันสามารถทำได้เสร็จสิ้นด้วยรายงานเพียงฉบับเดียว

นอกจากนี้ยังมีตัวเลขจากฝั่งวิศวกรรมด้วย ในช่วง 4 เดือนที่ผ่านมา กลุ่มเอเจนต์ได้ชี้ให้เห็นปัญหาที่อาจเกิดขึ้นประมาณ 250,000 รายการ ปิดกั้นการรวมโค้ด (Merge) ไป 16,000 รายการ และตรวจพบปัญหาเชิงโครงสร้างในการออกแบบประมาณ 600 รายการก่อนที่จะมีการเขียนโค้ดจริง

Cloudflare OS ไม่ใช่ผลิตภัณฑ์ที่เกิดจากการออกแบบบนโต๊ะทำงาน แต่เป็นผลลัพธ์จากการนำไปใช้งานจริงภายในบริษัทก่อน แล้วจึงนำส่วนที่เสียหายมาปรับปรุงใหม่ ซึ่งในบทความของ Rhea ที่เผยแพร่พร้อมกันนั้น ได้ระบุถึงที่มาดังกล่าวไว้อย่างชัดเจน

Rhea ได้บันทึกช่วงเวลาที่ปัญหาเริ่มชัดเจนขึ้นไว้ โดยประมาณ 6 เดือนก่อนการเผยแพร่บทความ สมาชิกในทีมขายได้เข้ามาขอว่า "ขอ API key หน่อยครับ เอาหลายอันเลย" โดยอ้างว่ากำลังสร้าง "SuperApp" เพื่อพลิกโฉมทีมบุกเบิกตลาดด้วย AI และสิ่งที่ต้องการมีเพียงสิทธิ์การเข้าถึงระบบหลักและการปรับใช้ (deployment) กับระบบงานหลักกว่าสิบระบบเท่านั้น

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

โครงสร้างปัญหาเดียวกันนี้ยังถูกระบุไว้ในเอกสารสาธารณะด้วย ใน OWASP Top 10 สำหรับแอปพลิเคชัน LLM (ฉบับปี 2025) หัวข้อ LLM06 "Excessive Agency" ได้ยกตัวอย่างสถานการณ์ที่ส่วนขยาย (extension) ซึ่งมีจุดประสงค์เพียงเพื่อการอ่านข้อมูล กลับเชื่อมต่อด้วย ID ที่สามารถดำเนินการ UPDATE หรือ DELETE ได้ โดยระบุว่าการกำหนดสิทธิ์ควรดำเนินการที่ฝั่งระบบปลายทาง (downstream system) ไม่ใช่ที่ฝั่ง LLM (OWASP Top 10 for LLM Applications 2025 เข้าถึงเมื่อวันที่ 26 สิงหาคม 2026) ทั้งนี้ "แนวทางปฏิบัติเกี่ยวกับมาตรการทางเทคนิคเพื่อความปลอดภัยของ AI" (มีนาคม ปีเรวะที่ 8) ของกระทรวงกิจการภายในและการสื่อสารของญี่ปุ่น ได้ระบุไว้อย่างชัดเจนว่าไม่ครอบคลุมถึง AI Agent ทำให้ในปัจจุบันยังไม่มีมาตรฐานสาธารณะที่ต้องปฏิบัติตามในประเทศญี่ปุ่น

ฉบับที่ 1 ถูกแจกจ่ายให้กับพนักงานทุกคนในเดือนพฤษภาคม 2026 อย่างไรก็ตาม ที่ต้องสร้างขึ้นใหม่เป็นเพราะเราพบข้อจำกัดระหว่างการใช้งานจริง

ข้อจำกัดทางเทคนิคมี 3 ประการ ประการแรกคือ แอปพลิเคชันเป็นเพียงผลลัพธ์แบบคงที่ ไม่ใช่ "ซอฟต์แวร์ที่ทำงานได้" ซึ่งเชื่อมต่อกับระบบภายในบริษัท ประการที่สองคือ การอนุมาน (inference) ทำงานทุกครั้งแม้กระทั่งกับงานที่เป็นแบบกำหนดนิยม (deterministic) ทำให้สิ้นเปลืองโทเค็นหลายพันโทเค็นทุกเช้าเพื่อสร้างรายงานประจำวันที่แทบจะเหมือนเดิมซ้ำๆ และประการที่สามซึ่งสำคัญที่สุดคือ ปัญหาที่เปิดเผยออกมาเมื่อมีการแชร์ข้อมูล สิทธิ์การเข้าถึง MCP server บอกเราว่า "สามารถเรียกใช้เครื่องมือใดได้บ้าง" แต่ไม่ได้บอกว่า "ได้ดูทรัพยากรใดไปจริงบ้าง" ข้อกำหนดของ MCP ระบุไว้อย่างชัดเจนว่าไม่จำเป็นต้องมีการอนุญาต และไม่ได้บังคับใช้สิทธิ์ในระดับโปรโตคอล (MCP Official Specification อ้างอิงเมื่อวันที่ 26 สิงหาคม 2026) อีกทั้งยังไม่มีกรอบการทำงานสำหรับติดตามทรัพยากรที่ถูกตรวจสอบโดยเชื่อมโยงกับผลลัพธ์ ทันทีที่เริ่มแชร์พื้นที่ทำงานหรือผลลัพธ์ ก็จะเกิดช่องทางที่ข้อมูลซึ่งไม่ควรเปิดเผยสามารถหลุดรอดไปได้ผ่านทางผลลัพธ์เหล่านั้น

ความล้มเหลวในระดับองค์กรก็ชัดเจนเช่นกัน Rhea สรุปว่าความผิดพลาดในระยะแรกคือการนำเครื่องมือสำหรับวิศวกรมาปรับเพียงแค่ UI ให้ใช้งานง่ายขึ้นแล้วแจกจ่ายให้กับพนักงานที่ไม่ใช่สายวิศวกร เพราะการแจกเครื่องมือที่เก่งด้านการสร้างโค้ดให้กับทุกคนมีแต่จะทำให้เกิดโค้ดที่ไม่จำเป็นออกมา ดังนั้นบริษัทจึงเปลี่ยนไปใช้ "AI อีเมลบอทวิเศษที่ส่งงานที่ไม่ต้องการทำไปแล้วจะได้ผลลัพธ์กลับมา" โดยเบื้องหลังใช้คนจำนวนน้อยจัดการด้วย AI แบบแมนนวล แม้เจ้าตัวจะย้อนความหลังว่า "รู้สึกแย่มาก" แต่พวกเขาก็สามารถระบุงานประจำที่ควรทำระบบอัตโนมัติได้ผ่านเซสชันหลายร้อยถึงหลายพันครั้ง ทั้งนี้ บทความอย่างเป็นทางการไม่ได้ระบุว่ามีการรั่วไหลของข้อมูลเกิดขึ้นจริงในฉบับที่ 1

หัวใจสำคัญของ Cloudflare OS ไม่ใช่ประสบการณ์การแชท แต่คือการออกแบบการให้สิทธิ์ (Authorization) โดยเป็นการบังคับใช้แนวคิดที่กล่าวถึงใน คู่มือการใช้งานการให้สิทธิ์เครื่องมือสำหรับ AI Agent ด้วยหลักการ Least Privilege ในระดับโครงสร้างพื้นฐาน

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

ทรัพยากรที่ได้รับอนุญาตจะถูกส่งไปยังโค้ดที่สร้างขึ้นในรูปแบบของ Typed Binding ต่อไปนี้คือตัวอย่างจากบล็อกทางการ สิ่งที่อยากให้สังเกตคือไม่มีข้อมูลรับรอง (Credentials) ปรากฏอยู่ในส่วนใดของโค้ดเลย

env.PROJECT คือ "Capability" (ขีดความสามารถ) ที่แสดงถึงสิทธิ์ในการใช้ทรัพยากรเฉพาะภายใต้นโยบายที่กำหนดไว้ ทางผู้ให้บริการอธิบายว่าข้อมูลรับรองจะถูกแยกออกจากทั้งตัวเอเจนต์และโค้ดที่สร้างขึ้น

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

Gatekeeper คือโปรแกรมขนาดเล็กที่ออกแบบมาเพื่อบริการนั้นๆ โดยเฉพาะ ซึ่งทำหน้าที่เป็นตัวกลางระหว่าง Cloudflare OS กับบริการภายนอก โดยจะทำหน้าที่ส่งต่อคำขอหลังจากตรวจสอบ API ของบริการเป้าหมาย ทรัพยากรที่สามารถจัดการได้ และการดำเนินการที่สามารถทำได้แล้ว

การให้สิทธิ์เข้าถึงบัญชี GitHub ทั้งหมดนั้นกว้างเกินไปสำหรับกรณีการใช้งานส่วนใหญ่ แต่หากใช้ Gatekeeper คั่นกลาง คุณจะสามารถจำกัดขอบเขตให้เหลือเพียงรีโพสิทอรีเดียว, ตั้งค่าให้อ่านได้เฉพาะ issue โดยไม่สามารถอ่านซอร์สโค้ดได้, ปิดบังฟิลด์ข้อมูลบางอย่าง, กำหนดอัตราการใช้งาน (rate limit) และกำหนดให้ต้องมีการอนุมัติจากมนุษย์ก่อนการรวม (merge) พูลรีเควสต์ สิ่งที่ฝั่งเอเจนต์มองเห็นจะมีเพียง TypeScript API ขนาดเล็กเท่านั้น ส่วนการจัดการ OAuth, การจัดเก็บข้อมูลรับรอง (credential) และการบังคับใช้นโยบาย ทั้งหมดจะเสร็จสิ้นที่ฝั่ง Gatekeeper

นี่ไม่ใช่เรื่องของทฤษฎีที่จับต้องไม่ได้ ในรีโพสิทอรี core มี Gatekeeper รวมอยู่ด้วยกัน 16 รายการ ได้แก่ GitHub, Google, Slack, Notion, Supabase, Linear, อีเมล, MCP และอื่นๆ (cloudflare/cloudflare-os อ้างอิงเมื่อวันที่ 26 สิงหาคม 2026)

จุดเด่นในการใช้งานจริงคือ การอนุมัติจากมนุษย์นั้นเป็นแบบอะซิงโครนัส (asynchronous) เมื่อถึงขั้นตอนการดำเนินการที่ต้องได้รับการอนุมัติ Gatekeeper จะส่งผลลัพธ์จำลองกลับไปที่ฝั่งเอเจนต์เพื่อให้เอเจนต์ทำงานต่อไปได้ และเก็บรายการที่รอการอนุมัติไว้ ซึ่งเป็นการออกแบบเพื่อหลีกเลี่ยงปัญหาคอขวดที่ทำให้การทำงานทั้งหมดต้องหยุดชะงักทุกครั้งที่มีการรออนุมัติหนึ่งรายการ

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

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

ประเด็นสำคัญอยู่ที่ 2 บรรทัดล่างสุด คือการมีหรือไม่มีการควบคุมที่ทำงาน "หลังจากแชร์ไปแล้ว"

สำหรับตำแหน่งของ MCP โปรดดูที่ MCP และ A2A ต่างกันอย่างไร? การเปรียบเทียบและการเลือกใช้โปรโตคอล AI Agent

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

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

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

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

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

เวิร์กโฟลว์แบบกำหนดทิศทางได้ (Deterministic workflow) ก็อยู่ในแนวทางเดียวกัน เนื่องจากจะใช้โมเดลเฉพาะในส่วนที่จำเป็นต้องมีการตัดสินใจเท่านั้น จึงไม่สิ้นเปลืองโทเค็นในทุกครั้งที่เรียกใช้งาน Rhea ได้เขียนถึงแดชบอร์ดสำหรับจัดการตั๋วที่สร้างขึ้นเองในเวอร์ชันที่ 2 ว่า "จำนวนโทเค็นที่ใช้ทุกครั้งที่โหลดรายงานฉบับแรกนั้นเท่ากับศูนย์พอดี"

Cloudflare OS เผยแพร่ภายใต้ Apache License 2.0 โดยคุณสามารถนำไปปรับใช้ (deploy) ในบัญชี Cloudflare ของคุณเอง เพื่อใช้งานร่วมกับ Access policy, การตั้งค่า AI Gateway, ข้อมูล และการเชื่อมต่อต่างๆ ของคุณได้ อย่างไรก็ตาม เนื่องจากมีข้อกำหนดเบื้องต้นและข้อจำกัดด้านความพร้อมใช้งาน เราจะเริ่มตรวจสอบจากจุดนั้นก่อน

README ของ starter repository ระบุว่าฟีเจอร์บัญชีที่จำเป็นประกอบด้วย Workers, KV, R2, Browser Rendering และ Dynamic Worker Loaders และหากใช้ model catalog ตามค่าเริ่มต้น ก็จำเป็นต้องใช้ Workers AI และ AI Gateway ด้วยเช่นกัน ขั้นตอนการปรับใช้จริง (Production deployment) ได้ถูกรวมไว้ใน README ฉบับเดียว (cloudflare/cloudflare-os-starter, วันที่อ้างอิง 26 สิงหาคม 2026)

ควรระมัดระวังเรื่องระดับความพร้อมใช้งาน (Maturity) โดย README ของ core ระบุไว้อย่างชัดเจนว่า v2 ยังอยู่ในสถานะ "early access" ซึ่งยังมีจุดที่ยังไม่สมบูรณ์อยู่มาก และยังไม่เปิดรับการสนับสนุนจากภายนอกอย่างจริงจัง (รับเฉพาะการแก้ไขบั๊กที่ชัดเจนซึ่งมีความยาวไม่เกินสิบกว่าบรรทัดเท่านั้น)

เกณฑ์ในการตัดสินใจมี 4 ข้อดังนี้:

Cloudflare OS ไม่ได้ผูกติดอยู่กับโมเดลใดโมเดลหนึ่ง เนื่องจากการเรียกใช้งานการอนุมาน (inference) ทั้งหมดจะผ่าน Cloudflare AI Gateway คุณจึงสามารถตัดสินใจได้จากจุดเดียวว่าจะให้ใช้โมเดลใดได้บ้าง และจะมอบหมายงานใดให้โมเดลไหน AI Gateway รองรับผู้ให้บริการหลายราย เช่น Workers AI, Amazon Bedrock, Anthropic, Azure OpenAI, Google Vertex AI และ OpenAI คำขอจะถูกบันทึกโดยเชื่อมโยงกับบุคคล ทีม หรือพื้นที่ทำงานที่ดำเนินการ ทำให้ผู้ดูแลระบบสามารถติดตามแหล่งที่มาของค่าใช้จ่าย และกำหนดงบประมาณรวมถึงขีดจำกัดอัตรา (rate limit) ได้

ความจำเป็นในเรื่องนี้ถูกอธิบายไว้ผ่านคำเปรียบเทียบโดย Rhea ว่า "เราไม่สามารถปล่อยให้การสรุปกล่องจดหมายอีเมลทุกๆ 1 ชั่วโมงต้องเสียค่าใช้จ่ายถึง 20 ดอลลาร์ได้" ดังนั้น จึงต้องมีการจำกัดโมเดลที่สามารถใช้ได้ตามบทบาท และนำการใช้งานที่มีความเป็นอิสระสูง เช่น การตั้งเวลาทำงาน ไปใช้กับโมเดลที่มีประสิทธิภาพมากกว่า โครงสร้างที่ทำให้คาดการณ์ค่าใช้จ่ายได้ยากนั้น ได้รับการสรุปไว้ในบทความ Token Trap คืออะไร? แนวทางปฏิบัติในการจัดการการใช้งานเพื่อป้องกันค่าใช้จ่ายที่พุ่งสูงขึ้นอย่างคาดไม่ถึงของ AI Agent ด้วยเช่นกัน

หากต้องการเพียงแค่ทดลองใช้งาน การรันบนเครื่องตัวเอง (Local) คือวิธีที่เร็วที่สุด เพียงติดตั้ง pnpm แล้วรันคำสั่ง pnpm run-local จากนั้นเปิด http://localhost:8787 ก็สามารถใช้งานได้ทันที (ไม่เหมาะสำหรับการใช้งานจริงในระดับโปรดักชัน)

สำหรับการทดสอบภายในองค์กร การจำกัดขอบเขตให้แคบลงเป็นวิธีที่สมเหตุสมผลที่สุด โดยแบ่งเป็น 3 ขั้นตอนตาม【ตัวอย่างที่คาดการณ์ไว้】ดังนี้: ขั้นแรก ให้เลือกงานแบบอ่านอย่างเดียว (Read-only) ที่ไม่มีการเขียนข้อมูล 1 อย่าง เช่น "อ่านเฉพาะ Issue ใน Repository ที่กำหนดเพื่อสรุปผลรายสัปดาห์" ขั้นต่อมา ให้เปิดใช้งานเฉพาะ Gatekeeper ที่จำเป็นสำหรับงานนั้นๆ เพื่อตรวจสอบว่าการจำกัดทรัพยากรเป้าหมาย, ฟิลด์ที่อ่านได้ และการจำกัดอัตรา (Rate limit) ทำงานได้ตามที่ตั้งใจไว้หรือไม่ และขั้นตอนสุดท้าย คือการแชร์ผลลัพธ์ให้กับบุคคลที่สามที่มีสิทธิ์เข้าถึงแตกต่างกัน เพื่อทดสอบว่าระบบจะบล็อกการเข้าถึงตามสิทธิ์ของผู้อ่านคนนั้นๆ หรือไม่

ขั้นตอนที่ 3 สำคัญที่สุด ปัจจัยที่สร้างความแตกต่างคือการตรวจสอบซ้ำในขณะแชร์ ซึ่งจะเป็นจุดตัดสินว่าระบบเข้ากับโครงสร้างสิทธิ์ของบริษัทคุณได้หรือไม่

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

ขอตอบ 3 ประเด็น ได้แก่ ความเป็นไปได้ในการใช้งานนอกเหนือจากบัญชี Cloudflare, การจัดการสินทรัพย์ MCP ที่มีอยู่เดิม และช่วงเวลาในการนำไปใช้งาน

แม้จะมีการระบุไว้อย่างเป็นทางการว่า "ทำได้" แต่ขั้นตอนการดำเนินงานยังไม่พร้อมใช้งาน โดย README ได้ระบุว่าเนื่องจาก workerd ซึ่งเป็น Workers runtime นั้นเป็นโอเพนซอร์ส จึงไม่ได้หมายความว่าจะสามารถรันได้เฉพาะบน Cloudflare เท่านั้น อย่างไรก็ตาม ในส่วนดังกล่าวยังคงแสดงข้อความว่า "COMING SOON" และทั้งเอกสารประกอบรวมถึงเครื่องมือต่างๆ ยังไม่ได้รับการจัดเตรียมไว้ นอกจากนี้ยังมีความจำเป็นต้องพึ่งพาฟังก์ชันต่างๆ ที่ระบุไว้ในส่วนเงื่อนไขเบื้องต้น ดังนั้นในขณะนี้ แนวทางที่แน่นอนที่สุดคือการปรับใช้ (deploy) ไปยังบัญชี Cloudflare ของบริษัทเอง

สามารถใช้งานได้ โดยมี 2 เส้นทางหลัก ในรูปแบบที่ผู้ใช้เป็นผู้กำหนด (User-led) คุณสามารถวาง URL ของ MCP server ใดก็ได้ แล้ว Gatekeeper จะดำเนินการ OAuth discovery และแปลงเครื่องมือแต่ละตัวให้เป็น Typed methods ภายในเซสชันนั้น ส่วนในรูปแบบที่องค์กรเป็นผู้กำหนด (Organization-led) ผู้ดูแลระบบจะตั้งค่า Portal URL ไว้เพียงหนึ่งเดียว ซึ่งทุกคนจะสามารถเข้าถึง MCP server ทั้งหมดที่องค์กรอนุมัติได้จากจุดนั้น สำหรับรูปแบบหลังนี้มีเป้าหมายการใช้งานบน Cloudflare MCP Server Portals โดยที่ Access จะทำหน้าที่ตัดสินใจเรื่องการอนุญาตการเชื่อมต่อ และ Gateway จะทำหน้าที่บันทึกและตรวจสอบการสื่อสาร หากคุณต้องการรวมศูนย์การเชื่อมต่อ MCP ที่กระจัดกระจายอยู่ภายในบริษัทให้มาอยู่ที่จุดตรวจสอบเดียว รูปแบบหลังนี้จะตรงกับวัตถุประสงค์ของการออกแบบครับ

คำตอบในขณะนี้คือ มีเหตุผลที่ควร "รอ" ครับ โดย Cloudflare ได้ระบุถึงแผนการในอนาคตว่าจะมีการให้บริการในรูปแบบผลิตภัณฑ์แบบจัดการเต็มรูปแบบ (Full-managed) บน Cloudflare Dashboard, การเพิ่มคอนเทนเนอร์สำหรับเวิร์กโฟลว์การพัฒนา และการรวมเข้ากับพื้นที่ทำงานอย่าง Slack เป็นต้น โดยเฉพาะอย่างยิ่งเวอร์ชัน Full-managed จะเปลี่ยนสมมติฐานของบริษัทที่ "ไม่เหมาะ" กับการใช้งานในปัจจุบันไป

ในทางกลับกัน หากบริษัทของคุณใช้งาน Cloudflare ในการดำเนินงานจริงอยู่แล้ว และการนำ AI มาใช้ภายในองค์กรกำลังติดปัญหาเรื่อง "วิธีการมอบสิทธิ์การเชื่อมต่อระบบ" ก็ถือว่าคุ้มค่าที่จะทดสอบในตอนนี้ครับ เนื่องจาก ณ เวลาที่ทำการสำรวจ ยังมีตัวอย่างการนำไปใช้งานที่เปิดเผยรายละเอียดรวมถึงการออกแบบสิทธิ์ (Permission design) อยู่ไม่มากนัก

สิ่งที่ Cloudflare OS กำลังแก้ไขไม่ใช่เรื่องของ "การทำให้ AI ฉลาดขึ้นอย่างไร" แต่เป็นปัญหาด้านการปฏิบัติงานที่ว่า "เมื่อให้เอเจนต์เข้าถึงระบบภายในบริษัท เราจะรับประกันได้อย่างไรว่าใครสามารถดูข้อมูลอะไรได้บ้าง" โดยมีประเด็นสำคัญ 4 ประการดังนี้:

• เอเจนต์และแอปพลิเคชันเริ่มต้นด้วยสิทธิ์การเข้าถึงเป็นศูนย์โดยค่าเริ่มต้น และข้อมูลรับรอง (credentials) จะถูกแยกออกจากโค้ด
• Gatekeeper จะจำกัดสิทธิ์ลงไปถึงระดับทรัพยากร การดำเนินการ และฟิลด์ข้อมูล พร้อมทั้งสามารถแทรกกระบวนการอนุมัติแบบอะซิงโครนัสได้
• บันทึกทรัพยากรที่เอเจนต์เข้าถึง และเมื่อมีการแชร์ข้อมูล จะทำการตรวจสอบซ้ำตามสิทธิ์ของผู้ดูข้อมูลนั้นๆ
• เผยแพร่ภายใต้ Apache License 2.0 และสามารถรันบนบัญชี Cloudflare ของบริษัทตนเองได้ แต่สถานะอย่างเป็นทางการเทียบเท่ากับ early access

การไม่มอบหมายการออกแบบสิทธิ์ให้เป็นหน้าที่ของผู้พัฒนาแอปพลิเคชันแต่ละตัว แต่รับผิดชอบในฐานะโครงสร้างพื้นฐาน แนวคิดนี้จะเป็นเกณฑ์ในการประเมินโครงสร้างพื้นฐาน AI ภายในองค์กร ไม่ว่าจะเลือกใช้เทคโนโลยีใดก็ตาม ขั้นแรกขอให้ลองตรวจสอบภายในบริษัทของคุณว่า "ข้อมูลที่เอเจนต์เห็น สามารถนำมาตรวจสอบซ้ำที่ฝั่งผู้รับการแชร์ได้หรือไม่"

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