ถ้า AI agent ช่วยตรวจ log ของ Worker ตัวหนึ่ง ควรไหมที่มันจะเห็น source code หรือ deploy ได้ทุก Worker ในบัญชีเดียวกันด้วย? ตั้งแต่วันที่ 15 กันยายน 2026 Cloudflare เปิดสิทธิ์ Workers แบบกำหนด role และขอบเขตแยกถึง Worker รายตัวได้ เพื่อให้ทีมเลือกสิทธิ์ตามงานของคน, ระบบ CI/CD หรือ agent แทนการแจกกุญแจชุดเดียวให้ทุกคน ประกาศจาก Cloudflare
แนวคิดนี้มีประโยชน์กับทีมที่เริ่มใช้ agent ทำงานกับระบบจริง คำว่า “ให้ AI ช่วย” ยังไม่บอกว่า AI เห็นข้อมูลอะไรและทำอะไรต่อได้ หากระบุว่า agent อ่าน log ของ Worker ใด หรือ pipeline deploy ได้เฉพาะแอปไหน ทีมจะคุยเรื่องขอบเขตได้ชัดขึ้น และกำหนดคนรับผิดชอบสิทธิ์นั้นได้
สี่ระดับสำหรับงานคนละแบบ
Cloudflare จับคู่ role กับ scope: role ระบุว่าทำอะไรได้ ส่วน scope ระบุว่าทำกับทรัพยากรใด ขอบเขตมีระดับ Developer Platform, product เช่น Workers หรือ resource รายตัว เช่น Worker ที่เลือกไว้ API token รองรับ product และ resource scope แต่ไม่รองรับ platform scope เอกสาร Roles and permissions
- Metadata Read-Only ดูรายการ Worker, การตั้งค่า และข้อมูลสังเกตการณ์ เช่น metrics, logs และ traces ได้ แต่ไม่เห็น source code หรือค่า secret
- Content Read-Only อ่าน source code ได้ แต่แก้หรือ deploy ไม่ได้
- Editor อ่านและแก้เนื้อหา Worker, ปรับ settings และ deploy Worker ที่มีอยู่ได้ แต่สร้างหรือลบ Worker ไม่ได้
- Admin จัดการ Worker ได้เต็มที่ รวมถึงสร้างและลบ เมื่อให้สิทธิ์ระดับ product; หากกำหนดกับ Worker รายตัว ขอบเขตจะจำกัดอยู่ที่ตัวนั้น
สิทธิ์รายตัวใช้ได้กับ Worker ที่มีอยู่แล้ว การสร้าง Worker ใหม่ยังต้องใช้ Admin ที่ scope ระดับ Workers product ถ้าการ deploy จะเพิ่มหรือแก้ route หรือ custom domain ต้องมีสิทธิ์ Workers Routes เพิ่มใน zone ที่เกี่ยวข้องด้วย ส่วนเอกสารระบุว่า custom domains ยังไม่มี per-Worker roles โดยตรง จึงควรตรวจ scope ที่ต้องให้จริงก่อนผูกงานอัตโนมัติ รายละเอียด role และข้อจำกัดของ Workers
แบ่งงานให้คนและ agent เห็นหน้าที่ตรงกัน
ตัวอย่างการออกแบบสิทธิ์สำหรับระบบหนึ่ง ไม่ใช่การตั้งค่าที่ Cloudflare บังคับหรือคำแนะนำที่เหมาะกับทุกองค์กร:
- agent ที่ช่วยวิเคราะห์เหตุขัดข้องได้ Metadata Read-Only เฉพาะ Worker นั้น เพื่อดู logs และ traces โดยไม่เปิด source code
- agent ที่ช่วย review โค้ดได้ Content Read-Only เฉพาะ Worker ที่ส่งตรวจ
- CI/CD ใช้ API token บัญชีที่มี Editor เฉพาะ Worker ที่ pipeline นั้น deploy
- Admin ให้ผู้ดูแลที่รับผิดชอบจริง และแยกการอนุมัติการสร้างหรือลบ Worker ออกจากงานประจำ
ถ้า deploy ต้องเปลี่ยน route หรือ custom domain ให้เพิ่มสิทธิ์ zone เฉพาะเมื่อขั้นตอนนั้นจำเป็น อย่าใส่ไว้ใน token ของทุก pipeline ตั้งแต่แรก การเพิ่มสิทธิ์ให้ผ่านงานหนึ่งครั้งอาจทำให้ token ใช้ทำอย่างอื่นได้ต่อไป จึงควรบันทึกว่าใครเป็นเจ้าของ token ใช้กับงานใด ใครอนุมัติ และจะทบทวนหรือเพิกถอนเมื่อไร
มีข้อจำกัดที่ควรรู้ก่อนเริ่ม: wrangler login แบบ OAuth ยังไม่รองรับ granular authorization หากต้องใช้สิทธิ์แบบเจาะจงกับ Wrangler ต้องยืนยันด้วย account-owned API token และจัดการ token ใน secret store ของระบบ CI/CD หรือเครื่องมือ agent ตามแนวทางขององค์กร เอกสาร Wrangler authentication
ผลต่อวัฒนธรรมทีม และต้นทุนที่ควรลงบัญชี
สิทธิ์แคบลงช่วยให้คุยเรื่องมอบหมายงานได้เป็นรูปธรรม เช่น agent อ่าน log ได้แต่แก้ระบบไม่ได้ หรือ pipeline ปล่อยรุ่นใหม่ได้แต่ลบแอปไม่ได้ ทีมจึงแยก “คนหรือ agent ที่เสนอการเปลี่ยนแปลง” ออกจาก “ผู้อนุมัติและเจ้าของระบบ” ได้ชัดขึ้น นี่เป็นแนวทางจัดการงาน ไม่ใช่หลักประกันว่าระบบจะปลอดภัยจากความผิดพลาดหรือการรั่วไหลทั้งหมด
ในการวางงบ อย่าคิดเฉพาะค่า API หรือค่าโมเดล เวลาของคนในการสร้าง token, ตรวจ scope, ทบทวนสมาชิกและกลุ่ม, เปลี่ยน credential เมื่อทีมเปลี่ยน และเพิกถอนสิทธิ์เมื่อยกเลิก agent ก็เป็นต้นทุนการดำเนินงาน ควรระบุเจ้าของงานและบันทึกเวลาหรือค่าใช้จ่ายที่เกิดขึ้นจริงตามวิธีบัญชีขององค์กร แทนการสมมติว่าระบบอัตโนมัติทำให้ต้นทุนลดลงทันที
Cloudflare ระบุว่าความสามารถนี้เปิดให้ลูกค้าทุกคนตั้งค่าได้ และเริ่มจาก Workers ส่วน role ชุดเดียวกันกับ D1, R2 และ KV เป็นแผนขยายในอนาคตตามประกาศ ไม่ควรนำไปสรุปว่าทุกผลิตภัณฑ์รองรับการกำหนดสิทธิ์ราย resource แล้ว สถานะและแผนผลิตภัณฑ์
ก่อนเชื่อม agent เข้ากับ production ให้เริ่มจาก Worker ที่มีความเสี่ยงต่ำ กำหนด role และ scope ทีละงาน ทดสอบว่าการกระทำที่ไม่อนุญาตถูกปฏิเสธจริง แล้วกำหนดผู้ดูแลและวันทบทวน token การแบ่งสิทธิ์เป็นจุดเริ่มของความรับผิดชอบที่ชัดขึ้น งานตรวจสอบและเพิกถอนยังต้องมีคนทำ
ภาพประกอบสร้างด้วย AI แสดงสถานการณ์จำลองของทีมทบทวนสิทธิ์ ไม่ใช่ภาพบุคลากรหรือระบบจริงของ Cloudflare, Enersys หรือลูกค้า
คุยกับทีม Enersys เรื่องการวางระบบและ workflow ของทีม
