Keamanan agen AI dimulai dari satu aturan: agen AI Anda tidak boleh pernah memegang kredensial Anda. Inilah pola broker berusia 38 tahun yang menegakkannya.
Agen AI adalah deputi yang bingung. Itu adalah pola keamanan berusia 38 tahun, dan jawabannya pun sama tuanya: tempatkan sebuah broker — lapisan tengah yang tepercaya, dapat diamati, deterministik, dapat diaudit, tidak dapat dipalsukan, dipersempit cakupannya, digerakkan kebijakan, dan bukan AI — di antara agen dan API SaaS yang perlu dipanggilnya, yang memegang kredensial yang seharusnya tidak dimiliki agen Anda.
Pada 1988, Norm Hardy menerbitkan sebuah makalah singkat yang menggambarkan sebuah insiden nyata dari masa kerjanya di Tymshare. Sebuah compiler Fortran bernama FORT berada di direktori sistem bernama SYSX. Untuk mengumpulkan statistik penggunaan, compiler itu perlu menulis ke (SYSX)STAT, sehingga sistem operasi memberi FORT sebuah "home files license," yang mengizinkannya menulis file apa pun di dalam SYSX. File penagihan sistem, (SYSX)BILL, juga berada di sana. Seorang pengguna yang memanggil compiler dapat memberikan nama file untuk menerima output debug opsional. Suatu hari seorang pengguna memberikan (SYSX)BILL. Compiler meminta OS membuka file itu untuk ditulis; OS, yang melihat home files license, mengizinkannya. Data penagihan tertimpa. Compiler melakukan persis seperti yang dirancang untuknya. Cacatnya bersifat arsitektural.
Hardy menamainya confused deputy problem: sebuah program berhak istimewa (sang deputi) memegang otoritasnya sendiri; seorang pemanggil dengan hak lebih rendah memintanya melakukan sesuatu; sang deputi menjadi bingung tentang otoritas siapa yang sedang ia jalankan, dan menggunakan otoritasnya sendiri. Perbaikannya adalah mencabut otoritas itu sepenuhnya dari sang deputi dan menempatkannya di balik lapisan terpisah yang memediasi panggilan sesuai permintaan. Lapisan itulah broker.
Tiga puluh delapan tahun kemudian, setiap agen AI yang dijalankan perusahaan Anda adalah deputi yang bingung. Dan sebagian besar dari mereka berjalan tanpa broker.
Mengapa agen AI memperburuk masalah keamanan
FORT milik Hardy punya satu saluran input: baris perintah. Agen AI modern punya puluhan: badan email, halaman web yang diambil, PDF yang diunggah, output tool dari server MCP, pesan dari agen rekan dalam sistem multi-agen. Apa pun yang masuk ke dalam context window dapat memberi instruksi, dan secara desain agen memperlakukan semuanya sebagai sah.
Itu mematahkan asumsi yang menjadi sandaran kontrol akses tradisional: pemanggil mengendalikan input. Dalam aplikasi web, pemanggil (sesi yang terotentikasi) dan input (badan permintaan HTTP) berasal dari tempat yang sama. Untuk sebuah agen, pemanggil adalah siapa pun yang membentuk prompt, yang berarti seorang penyerang yang dapat menulis email atau menanam hasil pencarian juga adalah seorang pemanggil.
Pada November 2025, para peneliti keamanan di PromptArmor menunjukkan seperti apa hal itu di produksi. Mereka menyembunyikan instruksi berbahaya dalam font 1 piksel pada sebuah panduan integrasi. Ketika seorang developer mengarahkan IDE Antigravity milik Google ke sana, agen tersebut melewati perlindungan file berbasis .gitignore-nya sendiri dengan menjalankan cat lewat shell. Lalu ia membocorkan isi file .env ke URL webhook.site yang dikendalikan penyerang melalui subagen browser milik Antigravity sendiri. Pengguna telah menyiapkan segalanya dengan benar. Sandbox tetap aman. Agen itu sekadar tidak dapat membedakan apa yang diminta pengguna dari apa yang diperintahkan oleh input.
Bentuk yang sama dengan FORT milik Hardy, beberapa dekade kemudian: otoritas yang luas, input yang tidak tepercaya, tanpa cara memisahkan keduanya.
Komunitas punya jawabannya. Jawaban itu hanya tersebar.
Ini bukan masalah baru. Komunitas keamanan telah menulis jawabannya selama beberapa dekade:
Capability-based security (Dennis & Van Horn, 1966; kemudian bahasa E dan karya Caja Mark Miller di Google). Prinsipnya: jangan memberikan otoritas ambien berdasarkan identitas atau lokasi; berikan capability yang eksplisit dan tidak dapat dipalsukan untuk setiap sumber daya yang boleh disentuh program. Sebuah capability menggabungkan apa yang dapat Anda lakukan dengan terhadap apa Anda dapat melakukannya, dan tidak dapat dikacaukan dengan apa pun.
Brokered Credentials (dikodifikasi oleh OWASP LLM Top 10). Jangan menaruh token API di dalam context LLM. Lapisan tengah yang tepercaya melakukan panggilan atas nama agen; model memutuskan apa yang dilakukan, broker menangani bagaimana-nya. Prompt injection yang meminta model mencetak kredensialnya tidak mendapatkan apa pun yang berguna. Kredensialnya tidak ada di sana.
Phantom Token Pattern (Curity, awalnya untuk OAuth di microservices). Agen memegang handle sesi yang opaque, bukan bearer token yang sebenarnya. Sebuah proxy memvalidasi handle itu, menukarkannya dengan kredensial asli di tepi jaringan, lalu meneruskannya ke hulu. Jika agen membocorkan environment-nya, penyerang mendapatkan sebuah string yang kedaluwarsa saat sesi berakhir.
Just-in-time credential injection (sistem identitas workload seperti Aembit). Cetak kredensial berumur pendek dan dipersempit cakupannya per panggilan alih-alih menerbitkan token berumur panjang.
Tidak ada satu pun dari ini yang absen dari literatur. Yang absen adalah dari default-nya. Sebagian besar platform agen masih menyerahkan token OAuth kepada model, tanpa broker di tengah, dan berharap yang terbaik.
Cara kerja broker Zero
Kami tidak menciptakan satu pun pola di atas. Kami merangkainya menjadi satu broker yang berjalan secara default untuk setiap agen di Zero. Inilah lapisan tengah tepercaya yang digambarkan pola-pola itu, dibangun untuk sebuah platform agen AI. Setiap panggilan yang dilakukan agen ke sebuah connector melewatinya. Setiap connector adalah satu SaaS eksternal (Slack, GitHub, Notion, dan seterusnya).
Broker berada di antara setiap agen dan setiap connector. Kredensial asli hanya hidup di sisi broker dari garis putus-putus.
Anggaplah ini sebagai tiga lapisan.
1. Isolasi kredensial
Sandbox agen tidak pernah memegang kredensial connector yang asli. Ketika Anda menghubungkan sebuah SaaS ke Zero, token OAuth atau API key-nya hidup di sisi broker. Sandbox mendapatkan sebuah string placeholder yang cukup mirip dengan rahasia environment agar tool yang ada tetap berfungsi, tetapi tidak ada SaaS hulu yang akan menerimanya.
Ketika agen membuat permintaan ke host connector yang terdaftar, broker mencocokkan permintaan itu, menyelesaikan template auth connector, dan menyuntikkan kredensial asli di tepi jaringan. Permintaan menuju hulu dengan auth yang valid; agen tidak pernah memegang apa pun yang berguna. Agen yang terkena prompt injection lalu membuang variabel environment-nya hanya menyerahkan placeholder kepada penyerang, bukan token SaaS.
Inilah phantom token pattern, diterapkan pada agen AI.
2. Gerbang kebijakan connector
Sebuah connector di Zero seharusnya lebih dari sekadar saklar on/off. Setiap connector menggambarkan API base yang dicakupnya dan bagaimana auth seharusnya disuntikkan. Ketika layanan hulu menerbitkan pemetaan scope-ke-endpoint yang stabil, ia juga dapat menggambarkan izin bernama mana yang mencakup setiap method dan path. slack-api-ref milik Slack adalah contoh yang baik.
Jadi ketika sebuah agen yang terhubung ke Slack memanggil chat.postMessage, broker dapat memetakan permintaan itu ke chat:write. Ketika ia membaca audit log, itu adalah admin.analytics:read. Untuk setiap agen, permission_policies mendefinisikan bagaimana izin-izin bernama itu berperilaku: allow, deny, atau ask. Kebijakan ditegakkan di broker sebelum penyuntikan auth, bukan sebagai petunjuk bagi model. Jika agen mencoba membuat panggilan yang dicakup oleh izin yang ditolak, mungkin karena ia terkena prompt injection, panggilan itu tidak pernah mencapai jaringan hulu.
Tidak setiap connector mendapatkan resolusi itu hari ini. Beberapa API hulu tidak menerbitkan pemetaan scope-ke-endpoint yang stabil. Permukaan GraphQL milik GitHub adalah kasus kanonis: sisi REST dapat dipetakan, tetapi sisi GraphQL belum bisa. Untuk connector tersebut, broker tetap mengontrol penyuntikan kredensial dan jalur jaringan, sementara gerbang izin kembali ke kebijakan tingkat connector atau host yang lebih kasar yang benar-benar dapat ditegakkan platform. Kami melengkapi ini seiring data hulu tersedia. Kami tidak mengklaim cakupan yang belum kami bangun.
Token tidak membawa otoritas ambien. Otoritas dibroker per agen, pada resolusi apa pun yang didukung hulu. Itulah separuh jawaban yang berbasis capability.
3. Loop operasional dan audit
Least privilege hanya berhasil jika failure mode-nya dapat digunakan. Agen bertumbuh. Setelah enam minggu, sebuah agen riset yang mulai dengan membaca dari Notion mungkin perlu menulis ringkasan kembali. Failure mode yang umum di tempat lain: agen diam-diam berjalan tanpa izin baru lalu rusak, atau operator memberi terlalu banyak izin karena panik dan tidak pernah menariknya kembali.
Permintaan connector yang ditolak mengembalikan 403 yang terstruktur: connector, method, path, base URL, dan nama izin yang cocok ketika broker dapat mengidentifikasinya. System prompt agen memberi tahu cara mendiagnosis penolakan itu dan cara meminta tepat izin yang baru saja ditemuinya, menghasilkan URL pemberian izin satu klik bagi pengguna atau admin. Itu menjaga jalur eskalasi tetap terikat pada izin persis yang diminta alih-alih berubah menjadi "berikan saja semuanya."
Permintaan perubahan izin berada dalam antrean. Owner dan admin dapat menyetujui atau menolaknya dari dashboard; permintaan yang disetujui memperbarui kebijakan agen, dan percobaan ulang berikutnya akan lolos. Sebagian besar platform melewatkan loop ini. Tanpanya, "least privilege" tetap di slide deck alih-alih berjalan di produksi.
Jalur broker yang sama memberi makan audit. Log jaringan per-run mencatat aktivitas jaringan sandbox di seluruh HTTP, TCP, DNS, dan observasi paket tingkat lebih rendah untuk lalu lintas non-TCP. Permintaan yang cocok dengan connector menyertakan metadata broker terstruktur: connector, izin yang cocok bila tersedia, hasil allow/deny, metadata resolusi auth, dan flag billable. Jika nanti seseorang bertanya "apa yang dilakukan agen ini pada Selasa pukul 3 sore?", Anda merekonstruksi jawabannya dari catatan-catatan itu. Pencegahan melewatkan beberapa hal. Jejak audit adalah cara Anda mengetahui apa yang terjadi.
Apa yang belum kami pecahkan
Bahkan dengan semua hal di atas, sebuah agen dengan chat:write yang sah masih bisa dibujuk untuk memposting pesan memalukan ke channel yang sudah dapat diaksesnya. Broker mempersempit radius ledakan; ia tidak menghilangkannya.
Separuh jawaban lainnya adalah persetujuan tindakan berisiko tinggi, validasi output, dan memperlakukan hasil tool sebagai tidak tepercaya secara default. Pekerjaan itu ada di roadmap, belum ada di produk. Siapa pun yang mengklaim telah memecahkan confused deputy secara menyeluruh sedang menjual sesuatu kepada Anda.
Ini seharusnya menjadi lantai dasar, bukan sebuah fitur
Capability-based security telah ada sejak 1970-an. Brokered credentials ada di OWASP LLM Top 10. Phantom token mendahului era LLM. Tidak satu pun dari ini absen karena tak seorang pun tahu jawabannya. Ini absen karena platform agen generasi awal mengoptimalkan untuk "membuat demo berjalan" dan menunda keamanan ke rilis berikutnya, yang sering kali tidak pernah datang.
Generasi platform berikutnya seharusnya menargetkan lebih tinggi. Token tidak boleh masuk ke context model. Otoritas harus dienumerasi per agen. Eskalasi hak istimewa harus melewati seorang manusia. Setiap tindakan harus dapat diaudit dari ujung ke ujung. Tidak satu pun dari itu baru. Semua itu seharusnya menjadi baseline.
Ketika Anda memilih platform agen, "apakah ini aman?" tidak membawa Anda ke mana-mana. Setiap vendor menjawab ya. Pertanyaan yang lebih baik: tunjukkan broker Anda, dan jelaskan apa yang terjadi ketika sebuah agen meminta scope yang tidak dimilikinya.
Broker berada di depan setiap agen di Zero secara default. Inventaris connector, pemetaan scope, kebijakan izin, dan logika broker semuanya hidup di repositori sumber Zero. Menemukan connector yang belum kami cakup? Buat sebuah issue.
Referensi
Fondasi
- 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 (makalah pendiri sistem capability)
- Mark Miller dkk., Caja: capability-based security untuk web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Insiden dunia nyata yang dikutip
- PromptArmor, Google Antigravity Exfiltrates Data, November 2025
- Simon Willison, liputan dan analisis, 25 November 2025
