Dari copilot ke rekan kerja: apa artinya ketika AI beroperasi secara otonom

Tinjauan berbasis riset tentang pergeseran dari mesin saran ke rekan tim otonom. Mengapa ini terjadi sekarang, apa yang patah dalam transisinya, dan cara menerapkannya tanpa menyerahkan kunci ke seluruh kerajaan.

Era copilot mulai mendatar

Pada 15 April 2026, Sam Altman memposting di X bahwa OpenAI sedang merilis "pembaruan Codex pekan ini yang berfokus pada tim dan perusahaan besar."

Balasannya mengungkap banyak hal. Untuk setiap developer yang bertanya soal roadmap, ada developer lain yang mengajukan pertanyaan yang lebih sulit: mengapa Codex masih butuh saya untuk mengawasinya? Enam bulan sebelumnya, para peneliti BeyondTrust telah menerbitkan proof-of-concept yang menunjukkan bahwa nama branch Git yang dirancang khusus bisa mengelabui Codex agar mengekstraksi token GitHub pengguna. Sebuah copilot yang bisa dikelabui untuk membocorkan token melalui nama branch bukanlah rekan kerja. Itu adalah senjata bermuatan dengan pengaman.

Ketegangan itu mendasari setiap percakapan AI enterprise pada 2026. Copilot telah mencapai langit-langitnya, dan angka-angka membuktikannya:

Inisiatif NANDA dari MIT melaporkan pada 2025 bahwa 95% pilot AI generatif gagal memberikan nilai bisnis yang terukur.
Sebuah studi RAND yang berulang kali dikutip di r/ArtificialIntelligence Reddit pada awal 2026 menemukan bahwa 80 hingga 90% proyek agen AI gagal di lingkungan produksi.
Tingkat penerimaan developer untuk GitHub Copilot telah mendatar di sekitar 35 hingga 40%, sementara Cursor berada di 42 hingga 45% dan Claude Code meraih rating 46% "paling disukai" dalam survei coding AI 2026. Sebuah pembalikan menakjubkan untuk tool yang baru diluncurkan pada Mei 2025.
Satya Nadella dilaporkan menyebut peluncuran Copilot internal Microsoft "nyaris tak bisa dipakai" pada akhir 2025, dan perusahaan mengumumkan apa yang secara internal digambarkan para eksekutif sebagai "reset berisiko tinggi" terhadap produk tersebut.
Sebuah studi arXiv yang diterbitkan pada akhir 2025 menemukan bahwa autocomplete bergaya Copilot justru meningkatkan frustrasi di kalangan developer ahli, karena ia mengganggu alur kerja mereka dengan saran yang masuk akal tetapi keliru secara halus.

Plateau ini bukan kegagalan model yang mendasarinya. Ini kegagalan pola interaksinya. Sebuah copilot beroperasi di level ketukan tombol atau pertanyaan individual. Sebuah rekan kerja beroperasi di level alur kerja. Bits&Chips mengemasnya dengan baik dalam esai April 2026-nya "From copilot to colleague": "Sebuah copilot beroperasi di level interaksi individual, sementara sebuah agen beroperasi di level alur kerja. Yang mana penting, karena di sebagian besar organisasi hambatannya bukan tugas individual. Tapi koordinasi antar tugas."

Itulah pergeseran yang sedang coba dilakukan perusahaan-perusahaan sekarang. Tidak merata, tidak sempurna, dan dalam skala yang berarti.

Spektrum otonomi

"Agen" telah menjadi kata pemasaran, jadi mari kita konkret. Ada empat level otonomi AI yang berbeda, dan sebagian besar kekecewaan pada 2025 dan 2026 berasal dari salah mengira yang satu sebagai yang lain.

Level 1: copilot

Menyarankan. Meminta izin. Tetap di layar Anda. Autocomplete GitHub Copilot adalah arketipenya. Nilai diukur dalam ketukan tombol yang dihemat.

Level 2: asisten

Menjawab pertanyaan dan menyusun artefak atas permintaan. ChatGPT, Claude di browser, panel chat Microsoft 365 Copilot. Nilai diukur dalam kualitas draf dan sintesis konteks.

Level 3: agen

Menerima sebuah tujuan, merencanakan rangkaian langkah, mengeksekusi lintas tools, melaporkan kembali. Claude Code memindai repo dan membuka PR. Deep Research ChatGPT menjalankan pencarian selama 20 menit dan mengembalikan laporan bersitasi. Anthropic mendokumentasikan sebuah instance Claude menyelesaikan tugas rekayasa otonom selama 7 jam untuk Rakuten. Nilai diukur dalam alur kerja yang diselesaikan per jam manusia yang dihabiskan.

Level 4: rekan kerja

Sebuah agen yang beroperasi di dalam model izin Anda yang sudah ada, ikut serta dalam channel komunikasi tim Anda, menyimpan konteks lintas hari dan pekan, dan bertanggung jawab pada jejak audit yang sama dengan karyawan manusia. Inilah perbatasannya.

Komunitas r/ChatGPT Reddit memunculkan sebuah uji pragmatis untuk membedakan level-level ini, diparafrasekan: apakah benda itu berinisiatif, atau ia menunggu setiap instruksi? Apakah ia menangani situasi tak terduga, atau ia crash dan memaksa Anda memprompt ulang? Apakah ia mengingat konteks lintas tugas multi-langkah, atau Anda harus mengulang-ulang? Sebagian besar produk yang dipasarkan sebagai "agen AI" pada 2025 gagal di setiap pertanyaan itu. Yang lolos adalah apa yang orang maksud sekarang ketika mereka bilang "rekan kerja".

Computer use vs skill: mengapa pipa-pipanya penting

Sebuah AI setingkat rekan kerja perlu bertindak di dunia. Ada dua pendekatan arsitektural untuk itu, dan keduanya membawa profil risiko yang sangat berbeda.

Computer use

AI mengendalikan mouse dan keyboard simulasi. Ia secara harfiah melihat sebuah layar dan mengeklik tombol. Anthropic merilis Computer Use pada akhir 2024, dan Operator dari OpenAI menyusul. Daya tariknya adalah universalitas: setiap software dengan GUI menjadi dapat dijangkau.

Biayanya adalah radius ledakannya. Sebuah agen pengguna-komputer mewarisi setiap izin yang dimiliki pengguna yang sedang login. Pada Oktober 2025, tim keamanan BeyondTrust mendemonstrasikan bahwa agen Codex dari OpenAI bisa dikelabui, melalui nama branch Git berbahaya yang disisipi perintah shell, untuk membaca dan mengekstraksi GITHUB_TOKEN pengguna. Agen itu melakukan persis apa yang akan dilakukan developer manusia (men-checkout sebuah branch), tetapi ia tidak punya intuisi bahwa nama branch itu sendiri adalah input bermusuhan. Dalam insiden itu model otoritasnya bersifat semua-atau-tidak-sama-sekali. Itulah mode kegagalan default dari computer use.

Skill

AI memanggil skill-skill diskret. Setiap skill adalah fungsi eksplisit dan bertipe dengan kontrak yang sempit: "cari pesan Slack yang cocok dengan q", "buat issue Linear dengan title dan body", "baca file GitHub ini." Tidak seperti computer use, sebuah skill punya bentuk yang sudah disetujui sebelumnya. Agen hanya bisa memanggilnya dengan parameter yang cocok dengan kontraknya, dan platform bisa mengizinkan, menolak, atau bertanya pada panggilan itu sebelum ia meninggalkan sandbox.

Perbedaannya, dalam istilah keamanan, bermuara pada Prinsip Hak Akses Paling Minimal. Ini gagasan fundamental dalam keamanan informasi: sebuah proses seharusnya hanya punya akses ke sumber daya yang ia butuhkan untuk menjalankan fungsinya, tidak lebih. Skill membiarkan Anda menegakkan hak akses paling minimal per panggilan. Computer use tidak.

Penerapan setingkat rekan kerja menggunakan skill untuk aksi terstruktur (menulis ke CRM, membuka tiket), dan menyimpan computer use untuk ekor sempit aplikasi yang menolak mengekspos API. Rasionya penting. Jika setiap aksi dalam penerapan agen Anda melewati mouse simulasi, Anda punya demo produktivitas, bukan sistem produksi.

Arsitektur kepercayaan yang sebenarnya dibutuhkan enterprise

Pergeseran dari copilot ke rekan kerja bukanlah peningkatan model. Ini peningkatan infrastruktur. Tiga elemen memisahkan rekan kerja yang dapat diterapkan dari sebuah liabilitas.

1. Isolasi izin

Setiap agen beroperasi di dalam batas izinnya sendiri, dengan kredensial yang tidak bisa diangkat keluar oleh agen itu sendiri dari sandbox-nya. Eksperimen autoresearch viral Andrej Karpathy pada Maret 2026, ketika ia membiarkan sebuah agen menjalankan 700 eksperimen training tanpa pengawasan selama dua hari, instruktif justru karena apa yang tidak ia lakukan. Repo Karpathy sendiri menginstruksikan pengguna untuk "menonaktifkan semua izin" dalam mode otonom. Itu baik-baik saja untuk laptop riset pribadi. Itu adalah pelanggaran yang bisa membuat Anda dipecat di dalam enterprise yang teregulasi.

Contoh tandingannya adalah Moltbook, jejaring sosial khusus-AI yang sempat viral pada akhir Januari 2026 dengan 1,5 juta agen otonom. Karpathy memujinya sebagai "hal paling luar biasa mirip-lepas-landas-sci-fi yang saya lihat akhir-akhir ini." Lalu para peneliti keamanan di Wiz menemukan API key database yang terekspos di front end, memberi akses baca/tulis penuh ke seluruh database produksi, termasuk token autentikasi untuk semua 1,5 juta agen. Karpathy berbalik arah dalam 24 jam: "Ini kebakaran tempat sampah. Saya jelas tidak merekomendasikan orang menjalankan hal-hal ini di komputer mereka." Pelajarannya bukan "agen itu berbahaya." Pelajarannya adalah bahwa agen yang diterapkan tanpa isolasi izin per-identitas runtuh menjadi satu radius ledakan bersama.

2. Jejak audit

Setiap aksi tercatat, setiap keputusan dapat dilacak. Kerangka IMDA Singapura, dirilis di Davos pada Januari 2026, mengkodifikasi ini dengan matriks risiko dua-sumbu yang memetakan ruang-aksi sebuah agen (baca vs tulis, dapat dibalik vs tak dapat dibalik) terhadap otonominya (seberapa independen ia memutuskan). Semakin tinggi salah satu sumbu, semakin kaya kebutuhan auditnya. Kerangka ini sedang dipelajari secara saksama oleh regulator Eropa dan AS karena ia adalah salah satu yang pertama menerjemahkan tata kelola dari prinsip abstrak menjadi alat kalibrasi operasional.

Simon Willison berargumen secara paralel untuk logging terpadu agar agen bisa memantau operasinya sendiri dan pulih dari kesalahan: "Agen dengan akses sistem penuh itu kuat, dan berbahaya." Poin praktisnya: jika penerapan agen Anda tidak punya log terpadu yang bisa dibaca petugas kepatuhan secara berurutan, Anda persis berjarak satu insiden dari kehilangan hak istimewa untuk menerapkan.

3. Akses skill yang terlingkup

Bukan "akses ke email." Tapi akses ke cari inbox dengan from:@customer.com AND dalam 7 hari terakhir. Platform agen modern bergerak menuju lingkup berparameter, di mana izin sebuah agen untuk memanggil skill dibatasi oleh argumen yang disetujui admin terlebih dahulu, bukan oleh lingkup OAuth tumpul yang akan dipakai manusia.

Satukan ketiga bagian itu dan mereka menjawab pertanyaan yang sedang ditanyakan setiap CISO sekarang: apa yang dilakukan agen ini ketika ia salah, dan bagaimana saya akan tahu? Survei State of AI McKinsey 2026 menemukan bahwa 72% responden enterprise menyebut keamanan siber sebagai kekhawatiran terhadap AI generatif, dan keamanan disebut sebagai penghalang #1 untuk menskalakan alur kerja agen oleh kira-kira dua pertiga responden. Isolasi izin, jejak audit, dan akses skill terlingkup bukanlah teater kepatuhan. Mereka adalah infrastruktur pembuka gerbang.

Mengapa ini penting sekarang: tiga kekuatan yang berkonvergensi

Pergeseran dari copilot ke rekan kerja pada 2026 tidak didorong oleh satu terobosan tunggal. Ini adalah hasil dari tiga kurva yang berpotongan.

Kekuatan 1: integrasi berhenti menjadi bespoke

Pada 2024, menyambungkan sebuah agen ke stack SaaS korporat berarti menulis konektor kustom per tool. Pada awal 2026, kontrak skill bertipe dan konektor prakemas telah meruntuhkan pekerjaan itu. Sebuah agen yang butuh enam pekan integrasi pada 2024 butuh satu sore pada 2026. Area permukaan sebuah perusahaan mid-market tipikal (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, kalender) kini tercakup oleh pustaka konektor open-source yang matang yang dikirim dengan izin bertipe yang sudah tertanam.

Kekuatan 2: multi-agen menjadi nyata

Gartner menamai Sistem Multi-Agen sebagai tren teknologi strategis teratas untuk 2026. VP Analis Terkemuka Gene Alvarez menawarkan metafora yang kini diulang di setiap slide AI enterprise: "Bayangkan kru pit Formula 1. Setiap anggota punya peran khusus (pengganti ban, pengisi bahan bakar, operator dongkrak) tetapi mereka dikoreografikan di sekitar satu tujuan tunggal. Itulah bentuk penerapan agen enterprise pada 2026." Sistem agen-tunggal mencapai langit-langit penalaran pada tugas berdurasi panjang. Sistem multi-agen, dengan peran khusus dan serah terima eksplisit, adalah cara tim menyiasati langit-langit itu hari ini.

Kekuatan 3: anggaran enterprise terbuka

G2 melaporkan dalam riset State of Software 2026-nya bahwa 57% perusahaan punya agen AI di produksi (naik dari sekitar 20% setahun sebelumnya).
McKinsey menemukan 23% enterprise sedang aktif menskalakan AI agen, dengan 62% dalam tahap eksperimentasi. Itu menyisakan hanya sekitar 15% organisasi besar yang masih di pinggir lapangan.
Survei Deloitte 2026 atas 3.235 pemimpin enterprise mengidentifikasi jasa keuangan sebagai pengadopsi terdepan, dengan studi kasus terdokumentasi tentang sebuah agen AI yang menangkap dan menindaklanjuti hasil rapat di seluruh pipeline kesepakatan yang sebelumnya membutuhkan tiga analis.
Enterprise AI Playbook Stanford, diterbitkan pada awal 2026, mengkatalogkan 51 penerapan produksi, dengan kasus migrasi ETL fintech menjadi implementasi rujukan bagi tim industri teregulasi.
Investasi infrastruktur AI enterprise yang dilaporkan melampaui $600 miliar dalam siklus 2025.
Dario Amodei dari Anthropic, berbicara di konferensi Code with Claude, memberi probabilitas 70 hingga 80% munculnya perusahaan satu-orang bernilai miliaran dolar pertama pada 2026, ditenagai oleh tenaga kerja agen.

Uangnya ada, protokolnya ada, dan arsiteksturnya ada. Yang sedang dinegosiasikan di setiap ruang rapat dewan sekarang adalah seberapa banyak otonomi, di bawah tata kelola apa, dan untuk alur kerja yang mana.

Argumen skeptis: apa kata Reddit, arXiv, dan laporan insiden

Tinjauan yang bertanggung jawab atas pergeseran ini harus serius merangkul orang-orang yang menganggap seluruhnya terlalu dibesar-besarkan.

Di Reddit, konsensus di seluruh r/LocalLLaMA, r/ClaudeCode, dan r/ChatGPT bersifat pragmatis: agen pemrograman telah tiba dan berguna. Sebagian besar "agen" lain adalah alur kerja otomatisasi yang mengenakan kostum chatbot. Kalimat yang dikutip di puluhan utas 2026, "Pakai Copilot ketika Anda ingin saran. Pakai Claude Code atau Cursor ketika Anda ingin ia benar-benar melakukan sesuatu," menangkap pemisahan yang produktif. Komunitas yang sama tidak segan-segan soal benchmark. Bahkan agen terbaik mencetak kira-kira 60% secara keseluruhan di Terminal-Bench dan turun ke 16% pada tugas sulit. Claude Opus 4.5 memimpin SWE-bench di 80,9%, yang tetap berarti satu dari lima tugas gagal.

Skeptisisme akademis lebih sulit dikesampingkan. Vishal Sikka (mantan CTO SAP, murid John McCarthy) dan kolaboratornya menerbitkan Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, berargumen secara matematis bahwa LLM transformer pada dasarnya terbatas dalam kemampuannya mengeksekusi tugas komputasional dan agen di luar langit-langit kompleksitas tertentu. Kesimpulan Sikka, "Tidak ada cara mereka bisa diandalkan" untuk operasi yang sangat kritis, sedang beredar di setiap Slack CISO sekarang. Makalah itu tidak mengeklaim agen tidak berguna. Ia mengeklaim ada sekelas masalah di mana Anda tidak bisa mengeluarkan manusia dari loop, sebagus apa pun modelnya.

Insiden nyata mendukung skeptisisme itu. Seorang pemimpin CX ritel yang dikutip dalam survei Yellow.ai 2026: "Kami harus menarik dukungan AI kami setelah hanya dua pekan, karena ia mulai mengutip kebijakan retur yang salah dan mengarang penawaran diskon di sekitar 1,35% tiket. Biaya untuk menghormati kesalahan-kesalahan itu jauh lebih besar daripada yang kami harap bisa hemat." Dalam skala besar, bahkan tingkat error di bawah 2% cepat menjadi mahal.

Sintesisnya: AI setingkat rekan kerja itu nyata dalam pemrograman, riset, ops terstruktur, dan alur kerja support yang sempit. Ia belum nyata dalam interaksi terbuka yang menghadap pelanggan tanpa peninjau manusia. Perusahaan yang memetik nilai pada 2026 adalah yang jujur tentang ke ember mana sebuah alur kerja termasuk.

Implikasi praktis: lima pertanyaan sebelum Anda menerapkan

Jika tim Anda sedang mengevaluasi rekan tim AI (dibangun internal atau pihak ketiga), inilah pertanyaan-pertanyaan yang memisahkan penerapan produksi dari nyaris-celaka.

Berapa radius ledakan dari aksi tunggal terburuk yang bisa diambil agen ini? Petakan secara harfiah. Jika kasus terburuknya adalah "mengirim email draf ke orang yang salah," palang tata kelolanya rendah. Jika itu "memodifikasi data produksi" atau "mengirim instruksi transfer dana," palangnya lebih tinggi satu orde besaran. Petakan sebelum Anda menerapkan, bukan setelah insiden pertama.
Bagaimana agen mendapatkan kredensialnya, dan bisakah ia membaca token mentahnya sama sekali? Ada tiga jawaban, dan hanya satu yang aman. Jika agen punya salinan token OAuth pengguna di lingkungannya, Anda secara efektif memberi LLM dompet Anda. Jika agen punya identitas "miliknya sendiri" melalui OAuth akun-layanan terpisah, Anda perlu melacak dan mencabutnya sebagai prinsipal sungguhan. Jawaban ketiga, yang sebenarnya Anda inginkan: token tidak pernah mencapai agen. Ia tinggal di platform, terenkripsi, dan diinjeksikan di lapisan proxy-jaringan tepat waktu, hanya untuk panggilan yang lolos pemeriksaan kebijakan, hanya sampai panggilan itu kembali.
Apakah setiap aksi tercatat di suatu tempat yang bisa dibaca petugas kepatuhan secara berurutan? Terpadu, dapat dikueri, dan tahan-rusak. Jika jawaban Anda adalah "kami punya beberapa log di suatu tempat di CloudWatch," Anda belum siap.
Bisakah Anda melingkupi akses skill ke parameter spesifik yang dibutuhkan alur kerja ini? Per panggilan, bukan per integrasi. Baca vs tulis. Per ID sumber daya. Per jendela waktu. Izin agen seharusnya menjadi sebuah persegi panjang yang digambar rapat di sekitar pekerjaannya, bukan seluruh gudang.
Bagaimana cerita rollback-nya jika sesuatu salah? Bagaimana Anda membalik sebuah aksi? Seberapa cepat? Siapa yang dihubungi? Aksi yang tak dapat dibalik (transfer uang, email yang menghadap pelanggan, deploy produksi) butuh langkah konfirmasi atau jendela penundaan. Yang dapat dibalik bisa berjalan secara otonom.

Kerjakan kelima itu. Jika Anda bisa menjawab semuanya, Anda sudah melewati era copilot dan masuk ke bagian yang benar-benar mengubah cara tim Anda mengirim. Jika Anda bisa menjawab dua atau tiga, di situlah fokus berikutnya, bukan alasan untuk menunggu. Rekan tim setingkat rekan kerja yang sedang diraih roadmap Anda sudah berjalan di produksi di suatu tempat hari ini. Jarak antara Anda dan ia adalah jarak infrastruktur, bukan jarak AI-perbatasan. Dan jarak infrastruktur menutup dengan cepat.

Anda tidak perlu menunggu rilis model berikutnya. Anda perlu memilih platform yang sudah menjawab kelima ini untuk Anda, dan mulai memberi agen Anda pekerjaan nyata.

Pertanyaan yang sering diajukan

Apa perbedaan nyata antara copilot dan rekan kerja AI?

Sebuah copilot menyarankan, meminta izin, dan tinggal di dalam satu tool. Sebuah rekan kerja menerima tujuan, merencanakan lintas sistem, mengeksekusi dengan izin terlingkup, dan bertanggung jawab pada jejak audit yang sama dengan manusia. Bits&Chips mengatakannya dengan rapi: copilot beroperasi di level interaksi, rekan kerja beroperasi di level alur kerja.

Bagaimana agen seharusnya menangani kredensial pengguna?

Tidak satu pun dari opsi yang jelas itu benar. Menyalin token OAuth pengguna ke lingkungan agen menempatkan kredensial hidup di dalam konteks LLM. Mencetak identitas terpisah per agen mengubah setiap agen menjadi prinsipal yang harus Anda lacak, cabut, dan audit layaknya manusia. Pola yang berhasil dalam praktik adalah akses terbroker: token tinggal di platform, terenkripsi; proxy jaringan keluar sandbox memanggil balik ke platform pada saat permintaan; platform mendekripsi token dan hanya mengembalikan header auth terselesaikan untuk panggilan yang lolos pemeriksaan kebijakan; agen itu sendiri tidak pernah membaca, mencatat, atau bertanya pada token mentah.

Computer use atau skill, mana yang harus kami pilih?

Skill secara default, untuk apa pun yang punya API. Computer use hanya ketika sistem target tidak punya antarmuka yang dapat diprogram. Insiden Codex BeyondTrust adalah kisah peringatannya: computer use mewarisi izin penuh pengguna, dan input berbahaya di mana pun dalam bidang pandang agen bisa menjadi eksploitasi.

Seberapa otonom kami sebenarnya boleh membiarkan agen berjalan?

Gunakan bingkai dua-sumbu IMDA Singapura: ruang-aksi × otonomi. Ruang-aksi yang sempit (read-only, dapat dibalik) menoleransi otonomi tinggi. Ruang-aksi yang luas (tulis, tak dapat dibalik, menghadap pelanggan) menuntut konfirmasi manusia, atau jendela tertunda untuk campur tangan. Konfigurasi terburuk adalah otonomi tinggi pada aksi berisiko tinggi tanpa jejak audit.

Bagaimana kami mengukur ROI?

Berhenti mengukur ketukan tombol yang dihemat. Ukur alur kerja yang diselesaikan per jam manusia yang dihabiskan, waktu-sampai-resolusi pada insiden ops, dan escape rate (tugas yang diserahkan agen kembali ke manusia). Temuan Deloitte 2026 menunjukkan para pengadopsi terdepan melacak tiga metrik: tingkat penyelesaian alur kerja, tingkat error, dan tingkat intervensi manusia, serta mengoptimalkan rasio di antara ketiganya.

Apa yang kami lakukan soal tingkat kegagalan pilot 95%?

Baca uraian MIT NANDA dengan saksama. Pilot yang gagal sebagian besar berjalan di atas "RAG Bodoh" (membuang segalanya ke dalam konteks), "Konektor Rapuh" (integrasi API yang rusak), dan tanpa arsitektur berbasis-event. Pilot yang berhasil punya lapisan operasi di sekitar LLM: memori, I/O, dan izin. Kernel LLM bukanlah hambatannya. Infrastruktur di sekelilingnyalah.

Di mana VM0 cocok

Kami membangun Zero di sekitar satu taruhan arsitektural: agen seharusnya tidak pernah memegang kredensialnya. Tidak di lingkungannya, tidak di prompt-nya, tidak di memorinya. Token tinggal di platform. Setiap panggilan keluar yang dilakukan agen dibroker melalui proxy jaringan yang memutuskan, per panggilan, apakah akan menginjeksikan header auth atau memblokir permintaan.

Itu pilihan yang tidak biasa. Pola umum pada 2026 adalah memberi agen identitas OAuth-nya sendiri (kini Anda punya prinsipal kedua untuk diaudit dan dicabut) atau menyerahkan kepadanya salinan token pengguna dalam sebuah env var (kini LLM bisa membaca dompet Anda). Kami tidak melakukan keduanya. Inilah cara kerjanya yang sebenarnya.

Token tidak pernah mencapai agen. Ketika Anda menyambungkan sebuah konektor ke Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot, dan seterusnya), token OAuth disimpan terenkripsi di platform. Refresh token tinggal di database dan tidak pernah meninggalkannya. Di dalam sandbox, tidak ada variabel lingkungan GITHUB_TOKEN untuk dibaca, tidak ada file rahasia untuk dibuka, tidak ada tool yang mengembalikan token.

Sebuah proxy jaringan membroker setiap panggilan. Setiap permintaan HTTP yang meninggalkan sandbox melewati addon berbasis mitmproxy. Proxy mengidentifikasi konektor dari hostname permintaan, mencari kebijakan firewall untuk agen itu, dan memeriksa apakah method-dan-path-nya diizinkan. Jika ya, proxy memanggil balik ke webhook platform. Platform mendekripsi token, menyegarkannya jika kedaluwarsa, menyelesaikan templat header apa pun (${{ secrets.GITHUB_TOKEN }} menjadi nilai sebenarnya), dan hanya mengembalikan header auth terselesaikan ke proxy. Proxy menginjeksikan header-header itu ke permintaan keluar. Ketika panggilan selesai, header-header itu hilang dari memori proxy. Agen tidak pernah melihatnya.

Izin bersifat per-agen, per-konektor, dan bertipe di level endpoint. Setiap agen membawa objek kebijakan yang memetakan setiap konektor ke sekumpulan grup izin bernama. github:repo-read bukan lingkup yang samar. Ia adalah bundel aturan method-dan-path spesifik, misalnya GET /repos/{owner}/{repo}/pulls. Memberi akses GitHub tidak memberi GitHub. Ia memberi sebuah bentuk niat di dalam GitHub.

Tiga status kebijakan, bukan dua. Setiap izin terselesaikan menjadi allow, deny, atau ask. Yang terakhir meminta manusia sebelum aksinya dieksekusi. Apa pun yang tidak dicocokkan firewall secara eksplisit jatuh ke unknownPolicy per-konektor, yang default-nya deny. Hak akses paling minimal adalah default, bukan opsi-pilih.

Satu sandbox per run. Setiap eksekusi agen berjalan di dalam microVM Firecracker-nya sendiri dengan namespace jaringan terisolasi. Ketika run berakhir, namespace dirobohkan. Dua run dari agen yang sama adalah dua sandbox terpisah dengan dua jejak audit terpisah.

Jejak audit per-permintaan. Proxy yang sama yang memutuskan allow/deny juga menulis log JSONL per-run dengan metadata firewall terlampir pada setiap permintaan: konektor, grup izin yang cocok, aturan spesifik yang cocok, keputusannya, timestamp-nya. Log-log itu dikirim balik ke platform. Jika seorang CISO perlu tahu apa yang dilakukan agen pada 14 April antara pukul 3 sore dan 5 sore CST, itu cukup satu kueri.

Sebuah CLI yang menjelaskan penolakannya sendiri. Ketika sebuah izin memblokir panggilan, agen (atau manusia yang duduk di sebelahnya) bisa menjalankan zero doctor permission-deny <connector> --method <M> --path <P> dan mendapat kembali grup izin persis yang memblokir permintaan, plus tautan remediasi. zero doctor permission-change membiarkan admin menyetel sebuah izin secara langsung, atau membiarkan seorang anggota mengajukan permintaan tertulis (dibatasi 500 karakter, agar alasannya benar-benar terbaca) yang dirutekan ke admin. Izin berisiko tinggi seperti slack:chat:write atau gmail.send memicu peringatan ekstra yang menunjuk ke alternatif yang lebih aman dan terlingkup-bot.

Dua peran, satu alur persetujuan. Owner dan admin mengubah izin secara langsung. Anggota mengajukan permintaan dengan alasan, yang dirutekan ke admin. Tidak ada tingkatan ketiga "agak-admin". Alurnya cukup kecil sehingga orang benar-benar memakainya, dan itulah seluruh intinya.

Kami menyimpan computer use untuk himpunan sempit sistem warisan yang menolak mengekspos API. Segala hal lainnya melewati skill. Setiap aksi diperiksa kebijakannya. Setiap kredensial tinggal di platform. Setiap keputusan dicatat.

Jika Anda sudah melewati "satu lagi autocomplete AI" dan ingin mencoba rekan tim AI yang akan disetujui tim keamanan Anda, lihat bagaimana Zero menangani alur kerja terjadwal, men-triage insiden produksi, atau menjalankan briefing produk pagi hari.

Era copilot tidak berakhir. Ia sedang diserap ke dalam sesuatu yang lebih besar. Tim yang akan memenangkan siklus berikutnya adalah mereka yang memahami perbedaannya.