Cloudflare ประกาศเมื่อ 15 กันยายน 2569 ว่าผู้ใช้ Cloudflare Workers กำหนดสิทธิ์ได้ถึง Worker รายตัว หากทีมให้ AI agent ช่วยตรวจ log ของแอปหนึ่ง ก็ไม่จำเป็นต้องเปิดทางให้ agent อ่านโค้ดหรือแก้ Worker ตัวอื่นในบัญชีเดียวกัน
สิทธิ์ใหม่นี้กำหนดสองอย่างคู่กัน คือระดับสิทธิ์ที่บอกว่าทำอะไรได้ และขอบเขตที่บอกว่าทำกับ Worker ตัวใด ทีมมอบสิทธิ์ให้สมาชิก กลุ่ม หรือ API token ที่ใช้กับ agent และระบบ CI/CD ได้ตาม เอกสาร Cloudflare
เลือกสิทธิ์ให้ตรงกับงาน
ถ้า agent มีหน้าที่ไล่เหตุขัดข้อง สิทธิ์ Metadata Read-Only ให้ดูการตั้งค่า metrics, log และ trace ของ Worker ที่เลือก โดยไม่เห็นโค้ดต้นฉบับหรือค่า secret ถ้าต้องตรวจโค้ด ให้ใช้ Content Read-Only ซึ่งอ่านโค้ดได้ แต่แก้ไขหรือ deploy ไม่ได้
ระบบ CI/CD ที่ deploy โค้ดให้ Worker ที่มีอยู่แล้วใช้ Editor เฉพาะตัวที่รับผิดชอบได้ สิทธิ์นี้แก้ไขและ deploy ได้ แต่ลบ Worker ไม่ได้
ผู้ดูแลที่ต้องลบ Worker ตัวใดใช้ Admin เฉพาะตัวนั้น ส่วนการสร้าง Worker ใหม่ต้องใช้ Admin ระดับผลิตภัณฑ์ Workers เพราะยังไม่มี Worker รายตัวให้ผูกสิทธิ์ตั้งแต่ต้น เอกสารสิทธิ์ Workers แยกสองกรณีนี้ไว้
การ deploy ที่เพิ่ม แก้ หรือลบ route หรือ Custom Domain ต้องมีสิทธิ์ Workers Routes Write ใน zone ที่เกี่ยวข้องด้วย ส่วนการปล่อย Worker รุ่นใหม่โดยไม่เปลี่ยนการเชื่อมต่อดังกล่าว ใช้ Editor ของ Worker ตัวนั้นได้
ถ้าใช้ Wrangler การล็อกอินผ่าน wrangler login แบบ OAuth ยังไม่รองรับสิทธิ์แบบแยกราย Worker Cloudflare ระบุ ให้ใช้ API token ที่บัญชีเป็นเจ้าของและกำหนดขอบเขตไว้สำหรับงานลักษณะนี้
สำหรับองค์กรที่เริ่มให้ agent แตะระบบจริง การแบ่งสิทธิ์ช่วยระบุได้ตรงขึ้นว่า agent ตัวใดอ่านข้อมูลหรือเปลี่ยนแอปตัวไหนได้ ก่อนออก token ให้ระบบอัตโนมัติ ทีมควรทดสอบว่าคำสั่งนอกขอบเขตถูกปฏิเสธจริง และระบุว่าใครจะทบทวนหรือเพิกถอน token เมื่อเลิกใช้
ภาพประกอบสร้างด้วย AI แสดงสถานการณ์จำลองของทีมทบทวนสิทธิ์ ไม่ใช่ภาพบุคลากรหรือระบบจริงของ Cloudflare, Enersys หรือลูกค้า
