Privasi AI Coding Agent: 5 Mitos yang Terbantahkan

Puluhan email penipuan sehari, dipersonalisasi dengan nama depan dan belakang asli Anda, dan kebocorannya bukan dari database yang diretas atau daftar pemasaran yang bocor. Itu adalah User-Agent header yang dilampirkan AI coding agent Anda pada request web yang tidak pernah benar-benar Anda setujui. Itulah yang ditemukan para developer ketika mereka melacak gelombang spam ke Claude Code, yang ternyata menempelkan alamat email akun pengguna ke request HTTP keluar saat melakukan web fetch dan pencarian. Penjelasan Anthropic sendiri hampir lebih buruk daripada bug-nya: mereka memasukkan email akun ke dalam konteks model agar bisa menulis tag @author yang masuk akal, dan model, sebagai bot yang suka membantu, mulai menyerahkannya ke situs mana pun yang meminta kontak. Saya sudah bertahun-tahun mengaudit perilaku jaringan tool yang berjalan di mesin developer, dan insiden ini adalah contoh pembelajaran yang nyaris sempurna. Jadi mari kita bahas lima keyakinan yang paling sering saya dengar tentang privasi agentic tool, lalu uji masing-masing terhadap apa yang benar-benar terjadi.

Mitos 1: "Coding agent saya hanya berbicara dengan API penyedia model"

Ini adalah model mental yang hampir semua orang mulai dengan: agent adalah pipa canggih antara terminal Anda dan server Anthropic (atau OpenAI, atau siapa pun). Kode Anda masuk, token keluar, dan satu-satunya endpoint jaringan yang penting adalah api.anthropic.com.

Ini keliru. CLI agentic modern adalah HTTP client serba guna yang kebetulan dikendalikan oleh language model. Ia punya tool WebFetch yang mengambil URL arbitrer. Ia punya tool WebSearch yang mengakses infrastruktur mesin pencari. Ia punya tool Bash, yang artinya curl, wget, pip install, npm install, git clone, dan setiap binary lain di sistem Anda yang bisa mengakses jaringan. Ketika ia memutuskan butuh dokumentasi, package, changelog, atau dokumen SEC, ia akan mengambilnya dari mana pun ia pikir benda itu berada. Setiap request tersebut berasal dari alamat IP Anda, di jaringan kantor Anda, dan membawa header apa pun yang ditulis model pagi itu.

Dan model ini bisa sangat kreatif. Setelah cerita email tersebut mencuat, seorang engineer memeriksa log web server miliknya sendiri dan menemukan request dari subagent dengan string User-Agent seperti company-helm-research/1.0 (Claude Code agent run by [name], [company] platform team; docs lookup), lengkap dengan nama perusahaan dan repositori GitHub tempat mereka bekerja. Agent itu bukan sekadar membocorkan nilai konfigurasi; ia menyusun header identifikasi dari konteks, seperti seorang intern yang membubuhkan nama lengkap, tim, dan proyeknya di setiap cold email. Jika Anda ingin melihat lebih dalam mengapa arsitekturnya memudahkan hal ini, kami pernah menulis tentang cara CLI coding agentic dibangun. Intinya, loop, konteks, dan set tool-nya sama kuatnya dengan yang dibutuhkan untuk menimbulkan masalah.

Model mental yang benar: agent Anda adalah karyawan junior dengan laptop kantor, koneksi jaringan perusahaan, dan setumpuk kartu nama Anda. Apa pun yang ada di konteksnya bisa keluar dari gedung lewat tool mana pun yang dimilikinya.

Mitos 2: "Mencantumkan email kontak di User-Agent hanyalah etika bot yang baik"

Mitos ini punya sedikit kebenaran, dan itulah yang membuatnya berbahaya. Memang ada konvensi yang sah bahwa crawler yang baik mengidentifikasi dirinya dan menyediakan kontak. Beberapa layanan menegakkannya dengan ketat. API EDGAR milik SEC, misalnya, menolak mentah-mentah request dengan User-Agent curl generik dan menuntut kontak yang dideklarasikan. Anda bisa memverifikasinya sendiri dalam sepuluh detik:

U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w '%{http_code}  default UA\n' "$U"
# 403  default UA
curl -s -o /dev/null -w '%{http_code}  declared contact\n' \
-A 'Acme Research admin@acme-research.example' "$U"
# 200  declared contact

Jadi model yang telah belajar bahwa "sebagian API menginginkan alamat kontak di User-Agent" tidak sedang berhalusinasi. Ia sedang mencocokkan pola dengan etika internet yang nyata. Dan jika model itu kebetulan memiliki email akun Anda di konteksnya, ia hanya punya satu alamat kontak yang bisa diserahkan. Engineer Anthropic yang menjelaskan insiden ini mengatakan hal yang sama: beberapa situs meminta kontak dari agent, dan Claude kadang memberikan email yang ia punya.

Di sinilah mitos itu runtuh. Konvensinya adalah operator bot menyediakan kontak miliknya sendiri, yaitu entitas yang menjalankan crawler, sehingga sysadmin yang kesal bisa menghubungi pihak yang bertanggung jawab. Crawler Anthropic mengidentifikasi dirinya sebagai Anthropic. Crawler Google sebagai Google. Tetapi ketika agent Anda mengambil sebuah halaman, kontak operatornya seharusnya URL dukungan vendor tool atau alamat yang Anda konfigurasi secara sengaja, bukan email akun pribadi yang Anda pakai untuk membayar langganan. Panduan RFC 9110 tentang User-Agent secara eksplisit tidak menganjurkan informasi identifikasi yang berlebihan, dan setiap privacy engineer yang saya kenal memperlakukan PII yang tidak diminta di header request sebagai cacat, titik. Etika untuk bot tidak pernah dimaksudkan untuk membongkar identitas manusia di balik bot tersebut.

Dan dampaknya nyata, bukan teoretis. Situs pihak ketiga yang sembarangan, termasuk sudut-sudut web yang penuh penipuan yang pasti disentuh agent pencari, kini memegang alamat email terverifikasi yang terikat nama untuk seorang software engineer aktif. Itu adalah benih spear-phishing yang dikirim siap pakai. Beberapa developer melacak lonjakan spam personal langsung ke perilaku ini. "Etika bot yang baik" yang membuat Anda di-doxxing ke spammer bukanlah etika, dan bukan pula kewarganegaraan yang baik.

Mitos 3: "Prompt izin dan sandbox menjaga identitas saya tetap aman"

Setiap agentic tool dilengkapi semacam UX persetujuan: agent bertanya sebelum menjalankan perintah, menunjukkan file mana yang dibaca, atau mungkin membatasi akses web dengan persetujuan per domain. Ini menciptakan kesan kuat. Seorang developer menggambarkannya sebagai perasaan bahwa "LLM hanya punya akses ke hal-hal yang secara eksplisit ditambahkan ke proyek." Kesan itu keliru, dan insiden email ini membuktikannya dua kali.

Pertama, sistem izin mengatur tool mana yang berjalan, bukan apa yang ditulis model di dalam request yang dibuat tool tersebut. Menyetujui "ya, ambil URL ini" tidak memberi tahu Anda apa pun tentang header yang disusun model untuk fetch itu. Menyetujui panggilan Bash yang menjalankan curl memberi tahu Anda lebih sedikit lagi, karena string perintahnya lewat begitu saja dan tidak ada yang membaca flag -A. Kedua, UI izin bekerja per aksi, sementara kebocoran adalah properti dari konteks. Begitu email akun Anda disuntikkan ke konteks sistem, yang tidak pernah dilihat pengguna dan tidak bisa mereka tolak, email itu tersedia untuk setiap panggilan tool, setiap subagent, dan setiap one-liner curl selama sesi berlangsung. Perimeter sandbox digambar mengelilingi filesystem, sementara jalur eksfiltrasinya adalah hasil generasi teks model itu sendiri.

Ini bagian yang ingin saya sampaikan terus terang, karena berlaku jauh melampaui bug satu vendor: apa pun di dalam konteks agent hanya berjarak satu instruksi yang terdengar masuk akal dari meninggalkan mesin Anda. API key, hostname internal, isi file, nama Anda, perusahaan Anda, email Anda. Containment di lapisan tool tidak membantu ketika model itu sendiri adalah saluran eksfiltrasinya. Itulah sebabnya saya pernah berargumen bahwa containment dan monitoring memecahkan masalah yang berbeda untuk AI agent, dan Anda perlu tahu mana yang sebenarnya Anda dapatkan. Dialog izin adalah monitoring yang berpura-pura jadi kontrol. Ia menunjukkan aksinya; ia tidak bisa menunjukkan niat yang tersirat dalam parameter aksi tersebut.

Kesimpulannya: sandbox, sebagaimana dikirim, melindungi file Anda. Ia tidak berbuat apa-apa untuk identitas Anda, karena identitas Anda sudah diserahkan ke model sebagai bahan mentah.

Mitos 4: "Ini cuma pengaturan, nyalakan saklarnya dan Anda aman"

Ketika masalah ini meledak, tuntutan dari pelapor awal sangat spesifik: ini seharusnya bukan pengaturan opt-out, tapi harus dihapus sepenuhnya dari harness. Naluri itu benar, dan cara perbaikannya akhirnya dirilis menunjukkan mengapa pengaturan adalah primitif yang salah untuk kelas masalah seperti ini.

Perbaikannya datang dalam dua bagian. Pertama, plugin bawaan (cc-plugin-privacy, diaktifkan secara default sejak v2.1.317) yang secara deterministik memblokir perilaku tersebut. Ini pemeriksaan keras, bukan saran kepada model. Kedua, dan yang lebih penting, Anthropic menghapus email akun dari konteks model sepenuhnya. Perhatikan urutan pentingnya. Plugin adalah filter pada output; menghapus email dari konteks berarti menghilangkan kemampuannya. Filter bisa terlewat. Model yang tidak pernah tahu email Anda tidak bisa membocorkannya, seberapa kreatif pun ia menyusun header.

Anda tidak bisa "prompt" keluar dari paparan data. Jika model bisa melihatnya, model bisa mengeluarkannya. Satu-satunya redaksi yang andal adalah pengurangan.

Ini pola yang terus saya lihat di tooling agent, dan sejalan dengan yang pernah kami bahas dalam audit API client yang sekaligus berfungsi sebagai credential vault: materi sensitif dijejalkan ke tempat yang paling praktis (konteks, environment, file konfigurasi) karena suatu fitur pernah membutuhkannya sekali, lalu ia ikut ke mana-mana. Toggle telemetri dan pengaturan privasi menangani apa yang diputuskan vendor untuk dikumpulkan. Keduanya tidak berkata apa-apa tentang apa yang mungkin dilakukan model dengan materi yang diberikan kepadanya. Pengaturan itu untuk preferensi. Kontrol deterministik dan minimisasi data itu untuk privasi. Jika vendor menawarkan yang pertama sebagai solusi untuk yang kedua, dorong balik.

Mitos 5: "Vendor sudah menambalnya, jadi saya tidak perlu khawatir lagi"

Perlu diakui: penanganannya cepat, penjelasan teknisnya jujur, dan perbaikannya menyerang akar masalah, bukan gejalanya. Tapi "sudah ditambal" adalah klaim tentang satu perilaku spesifik di satu versi spesifik. Kelas masalahnya, yaitu agentic tool yang memancarkan materi identifikasi ke endpoint arbitrer, bersifat struktural, dan akan muncul lagi di tool ini atau tool lain. Beberapa pengguna menunjukkan bahwa ini bahkan bukan pertama kalinya identitas akun muncul tanpa diundang di konteks Claude Code; setidaknya ini yang kedua.

Ada juga kebenaran yang lebih sulit di baliknya: Anda tidak bisa sepenuhnya memverifikasi ketiadaan kebocoran dari sisi klien. Seorang pengguna yang teliti menjalankan proxy man-in-the-middle terhadap versi yang sudah diperbaiki dan memastikan tidak ada yang mengidentifikasi keluar dari mesinnya lewat tool WebFetch. Kerja bagus, dan naluri yang tepat. Tapi seperti yang ia catat, identifikasi juga bisa terjadi di sisi server: klien Anda mengirim request anonim ke API vendor, dan infrastruktur di sisi vendor menyebarkannya ke pihak ketiga dengan detail Anda terlampir. Pada titik itu, tidak ada inspeksi paket lokal yang bisa melihatnya. Anda kembali harus mempercayai vendor, dan itulah posisi yang terbukti tidak nyaman dalam insiden ini.

Jadi postur yang tahan lama bukanlah "patch sudah diterapkan, kasus ditutup." Melainkan memperlakukan setiap agentic tool sebagai klien jaringan yang selalu patut dicurigai dan diaudit secara berkala, sama seperti Anda memperlakukan perangkat lunak pihak ketiga dengan izin luas di laptop engineer. Dan itu membawa kita ke bagian praktisnya.

Cara mengaudit lalu lintas jaringan agent Anda sendiri

Tidak ada yang membutuhkan tim keamanan. Sehari kerja dan beberapa tool standar akan memberi tahu Anda lebih banyak tentang perilaku agent Anda daripada kebijakan privasi mana pun.

1. Sadap lalu lintasnya. Arahkan agent ke mitmproxy dan biarkan ia berjalan dalam sesi kerja nyata. CLI berbasis Node umumnya menghormati environment variable proxy setelah mereka mempercayai CA Anda:

mitmdump --listen-port 8080 -w agent-flows.mitm &
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
# Now run your agent and do normal work.
# Afterwards, search every captured request for your identifiers:
mitmdump -nr agent-flows.mitm \
--flows \
| grep -iE 'you@company\.com|YourName|your-org'

Cari lebih dari sekadar email Anda: nama Anda, perusahaan Anda, slug GitHub organisasi Anda, hostname internal, nama repositori. Ingat log subagent tadi. Model menyusun identifier, bukan sekadar mengulang, jadi cari fragmennya.

2. Periksa log infrastruktur Anda sendiri. Jika Anda mengoperasikan layanan web, cari string User-Agent agent di access log-nya. Begitulah header yang disusun pada Mitos 1 ditemukan. Ini tidak memakan biaya apa pun dan sering kali memunculkan lalu lintas subagent yang luput dari penangkapan lokal.

3. Batasi egress. Kontrol terkuat adalah membuat seluruh kategori kebocoran menjadi mustahil. Jalankan agent di dalam container atau VM yang kebijakan jaringannya hanya mengizinkan endpoint yang memang dibutuhkan, seperti API model, registry package Anda, dan mungkin GitHub. Dengan Docker, itu berarti network kustom plus firewall egress. Di Mac, Little Snitch atau Lulu memberi aturan per proses. Jika agent tidak bisa menjangkau situs web sembarangan dari sandbox-nya, ia juga tidak bisa menyerahkan identitas Anda ke situs web sembarangan. Ia harus meminta Anda yang mengambil sesuatu. Memang merepotkan, tapi kerepotan itulah intinya.

4. Minimalkan apa yang diketahui tool. Gunakan email khusus bernilai rendah untuk akun tool, bukan alamat kerja utama Anda. Hapus detail identifikasi dari file konfigurasi global yang dibaca agent (~/.gitconfig adalah contoh umum yang sering diambil agent). Jika tool mendukungnya, jalankan di bawah user OS terpisah dengan home directory sendiri. Pengurangan selalu mengalahkan penyaringan.

5. Di level organisasi, arahkan lewat proxy terkelola. Jika perusahaan Anda menyediakan agentic tool untuk engineer, paksa lalu lintas mereka melewati egress proxy dengan logging, dan tambahkan inspeksi header ke pipeline. Log query DNS saja sudah bisa menangkap pola agent yang menyebar ke ratusan domain tidak biasa. Ini postur yang sama seperti yang Anda terapkan pada CI runner atau build machine, dan itu kerangka yang tepat: agent adalah infrastruktur build yang punya opini.

Bug email-di-User-Agent ini akan terlupakan dalam sebulan, tenggelam dalam hiruk-pikuk release notes. Pelajarannya tidak boleh ikut terlupakan. Agentic coding tool adalah perangkat lunak paling istimewa, paling aktif di jaringan, dan paling sedikit diaudit yang kebanyakan dari kita jalankan, dan ia berimprovisasi. Perlakukan mereka sebagaimana mestinya: anggap apa pun di dalam konteksnya bersifat publik, verifikasi apa yang benar-benar ada di jaringan, dan bangun kandangnya sebelum Anda membutuhkannya, bukan setelah spam datang dengan nama Anda tertera.