Cloudflare Workers 2026: Otorisasi Granular untuk Agen

Pada 2026-09-15 Cloudflare merilis perubahan kontrol akses terbesar di Developer Platform dalam bertahun-tahun: empat peran dengan cakupan per Worker, tiga tingkat cakupan, dan cara mengunci salah satunya ke satu Worker. Post peluncuran adalah "Give every teammate and agent the right level of access to your Workers", bertanggal 2026-09-15, dan fitur ini sudah live untuk semua pelanggan hari ini.

Kalimat itu lebih penting dari kedengarannya. Selama satu dekade API Cloudflare memperlakukan Workers sebagai sumber daya akun yang datar: token dengan Workers Scripts:Edit bisa deploy, rename, atau hapus setiap Worker di akun Anda. Jika Anda menjalankan Worker yang menggerakkan endpoint arsip sosial di Cloudflare, tidak ada cara bersih untuk memberikan agen AI atau token CI akses yang cukup untuk memublikasikan kode tanpa juga menyerahkan kunci ke seluruh akun Anda. Peran baru memperbaiki itu — dan dirancang, dalam kata-kata Cloudflare sendiri, agar "sebuah agen bisa menggunakan API Cloudflare untuk menyelidiki masalah tanpa melihat data dari Worker lain di akun".

Empat Peran Baru, Dalam Satu Tabel

Cloudflare mengelompokkan puluhan mikro-permissions menjadi tepat empat peran, masing-masing mencerminkan tingkat yang sebenarnya ingin Anda berikan:

Setiap peran dapat diatur pada salah satu dari tiga cakupan. Dari paling permisif ke paling sempit: Account (berlaku untuk semua Worker di akun), Zone (berlaku untuk Worker yang terkait dengan satu zone), dan Individual Worker (berlaku untuk satu Worker bernama). Cloudflare menyatakan empat peran yang sama akan diperluas ke D1, R2, dan KV, dengan prinsip yang sama — Metadata Read-Only akan memeriksa skema D1 atau metadata bucket R2 tanpa memperlihatkan baris atau objek.

Mengapa "Editor Cakupan Satu Worker" Adalah Default yang Tepat untuk Agen

Peran paling berguna untuk agen AI adalah Editor, dengan cakupan satu Worker individual. Contoh Cloudflare sendiri adalah workflow CI/CD yang seharusnya hanya bisa deploy aplikasi yang dimilikinya: "Jika workflow salah konfigurasi atau token-nya terekspos, dampaknya tetap terbatas: ia bisa deploy perubahan ke Worker itu, tapi tidak bisa menghapusnya atau menyentuh aplikasi lain di akun Anda."

Untuk Worker arsip sosial yang mengambil posting dari X, Bluesky, atau LinkedIn dan menulisnya ke R2, ini adalah aturan yang sebenarnya Anda inginkan. Di model lama, token CI yang bocor bisa menulis ulang Worker untuk mengeksfiltrasi bucket R2 Anda, mengarahkannya ke namespace KV lain, atau sekadar menghapus Worker dan mematikan API. Di model baru, Editor dengan cakupan satu Worker bisa deploy kode yang menyentuh satu Worker itu dan hanya Worker itu.

Perhatikan satu detail halus tapi penting: Editor tidak bisa menghapus Worker itu sendiri. Itulah sifat yang membuat Editor aman diberikan ke agen. Kemampuan menghapus Worker dicadangkan untuk Admin. Jadi bahkan jika prompt injection agen menyebabkannya melakukan sesuatu yang merusak, kasus terburuk adalah deploy yang buruk, bukan aplikasi yang hilang.

Cara Membuat Token API dengan Cakupan di Dashboard Cloudflare

Post peluncuran memandu resepnya. Versi singkat, untuk Worker arsip sosial bernama social-archive-api:

1. Buka dashboard Cloudflare dan pergi ke Profil Saya → API Tokens → Buat Token.
2. Pilih template Edit Cloudflare Workers, lalu sesuaikan.
3. Di bawah Sumber Daya Akun, pilih Worker yang ingin Anda terapkan. Atur cakupan ke Worker dan pilih social-archive-api.
4. Di bawah Permissions, pilih peran Worker: Editor untuk agen atau token CI, Metadata Read-Only untuk token khusus debug.
5. Simpan token sekali dan salin. Cloudflare menampilkan nilai token hanya pada saat pembuatan.

# Deploy CI untuk Worker arsip sosial menggunakan token Editor dengan cakupan
# Token ini HANYA bisa deploy Worker ini; tidak bisa menghapus atau menyentuh apapun yang lain.

CLOUDFLARE_API_TOKEN=<an...n
# Perintah deploy sendiri tidak berubah.
npx wrangler deploy \
  --name social-archive-api \
  --compatibility-date 2026-09-01

# Jika token ini bocor, kasus terburuk adalah:
#   - seseorang bisa mendorong kode baru ke Worker ini
#   - TIDAK bisa menghapus Worker
#   - TIDAK bisa membaca kode sumber Anda (Editor menulis; tidak termasuk kebocoran source via API)
#   - TIDAK bisa deploy ke Worker lain di akun

Bagaimana Rute dan Custom Domain Berinteraksi dengan Cakupan Worker

Satu tempat model baru menjadi bernuansa adalah routing. Rute atau Custom Domain Worker dikonfigurasi di zone, bukan di Worker. Blok rute contoh Cloudflare di wrangler.jsonc terlihat seperti ini:

{
  "route": {
    "pattern": "example.com/*",
    "zone_name": "example.com"
  }
}

Karena mengubah rute bisa mengalihkan lalu lintas produksi atau mematikan Worker, menambah, menghapus, atau mengubah rute membutuhkan Editor pada Worker DAN izin Workers Routes untuk zone. Alasan Cloudflare: seseorang yang mengelola bagaimana lalu lintas mencapai Worker seharusnya tidak juga bisa mengubah pengaturan domain yang tidak terkait.

Setelah rute diatur, deployment yang tidak mengubah rute tidak lagi memerlukan izin zone. Artinya token CI bisa terus mempublikasikan Worker tanpa juga memegang akses ke domain, database, atau storage Anda. Itulah huruf kecil yang membuat Editor dengan cakupan Worker benar-benar berguna.

Durable Objects Mengikuti Peran Worker

Jika Worker arsip sosial Anda mengekspos Durable Object (misalnya, store sesi per-pengguna yang melacak posting mana yang sudah diambil sehingga tidak mengarsipkan duplikat), Durable Object tidak punya peran sendiri. Akses ditentukan sepenuhnya oleh peran pada Worker yang mengimplementasikannya.

Konsekuensi konkret: Metadata Read-Only pada Worker memungkinkan agen melihat metrik, log, dan trace Durable Object — tapi tidak data yang disimpan dalam objek. Untuk mengkueri atau mengubah data itu, agen membutuhkan Editor pada Worker. Cloudflare eksplisit bahwa pemisahan ini akan berlaku saat peran yang sama dibawa ke D1, R2, dan KV: Metadata Read-Only akan memeriksa skema atau metadata bucket tanpa memperlihatkan baris atau objek.

Apa yang Berubah Ketika Token Tidak Punya Peran yang Tepat

Peluncuran ini juga membawa peningkatan kecil tapi berdampak tinggi pada pesan kesalahan API: alih-alih mengembalikan 403 Forbidden generik ketika token tidak punya peran yang tepat, API Cloudflare sekarang menyertakan tautan ke dokumentasi relevan yang menjelaskan izin mana yang diperlukan.

Alasan ini penting dalam praktik adalah debug. Mode kegagalan lama untuk agen yang diberi token salah adalah 403 senyap dan manusia bingung mencari tahu dari puluhan izin warisan Cloudflare mana yang harus diberikan. Dalam model baru, pesan kesalahan itu sendiri menunjukkan peran yang dibutuhkan agen — dan Anda bisa mempromosikannya dari sana tanpa memberikan akses yang lebih luas dari yang dibutuhkan pekerjaan.

Bagaimana ThreadGrab Menggunakan Ini dalam Praktik

Worker ThreadGrab yang menggerakkan API arsip sosial di /functions/api/ cocok dengan pola yang sama. Sebuah Worker mengambil posting dari X, Bluesky, dan LinkedIn, menulisnya ke bucket R2 Cloudflare, dan melayani endpoint JSON kecil. Worker itu adalah seluruh radius ledakan untuk token CI atau agen apapun yang menyentuhnya. Sampai 2026-09-15 satu-satunya pilihan aman adalah token cakupan akun, dengan pemilik manusia sebagai satu-satunya Editor — yang membuat mustahil memberikan agen AI kemampuan memublikasikan hotfix.

Dengan peran baru kami bisa membagi itu dengan bersih:

• Editor dengan cakupan social-archive-api — diberikan ke agen dan pipeline CI. Bisa deploy, tidak bisa hapus, tidak bisa sentuh Worker lain.
• Metadata Read-Only — diberikan ke token khusus debug terpisah yang digunakan oleh dashboard observabilitas yang perlu menarik log dan metrik.
• Admin — dipegang hanya oleh pemilik manusia, digunakan saat Worker perlu di-rename atau dipensiunkan.

Hasilnya adalah pola yang secara eksplisit direkomendasikan Cloudflare — dan pola yang seharusnya menjadi default untuk Worker apapun yang disentuh agen AI atau token CI.

FAQ

Kesimpulan

Peluncuran Otorisasi Granular Workers 2026-09-15 bukan pembaruan "menu pengaturan"; ini adalah pertama kalinya Cloudflare merilis model hak paling kecil yang cocok dengan bagaimana Worker benar-benar digunakan hari ini — oleh agen AI dan token CI, bukan oleh manusia yang mengklik dashboard. Untuk siapa saja yang menjalankan Worker yang disentuh agen, migrasinya sama: pilih Editor dengan cakupan Worker untuk agen, pegang Admin untuk diri sendiri, dan pensiunkan token Scripts:Edit cakupan akun. Perubahan pesan kesalahan membuat sisanya gratis.