Data yang dihantar oleh ejen pengekodan AI

Perkara yang sebenarnya diliputi oleh telemetri ejen pengekodan

Telemetri ejen pengekodan terdiri daripada empat aliran data berasingan yang berkongsi satu istilah, dan setiap aliran mempunyai kawalan tersendiri. Inferens model membawa prompt dan kod anda kepada pihak yang menyediakan model tersebut, dan tiada tetapan yang boleh mematikannya. Analitis produk dan laporan ranap dihantar kepada vendor, dan selalunya kepada syarikat pembalakan (logging) yang dibayar oleh vendor. Pengekalan data untuk latihan adalah isu kontrak dan bukannya isu rangkaian. Aliran keempat adalah perkara yang sering terlepas pandang: setiap integrasi yang anda tambah boleh membuka sambungan ke hos yang tidak pernah anda pilih.

Senarai tetapan lalai vendor semasa adalah bahagian dalam subjek ini yang paling cepat berubah. Sesuatu release boleh mengubah tetapan lalai, dan ciri baharu boleh menambah destinasi yang tidak diliputi oleh mana-mana suis sedia ada. Oleh itu, kemahiran yang tahan lama ialah audit yang boleh anda ulangi terhadap mana-mana ejen: baca dokumentasi vendor, semak konfigurasi yang sebenarnya digunakan pada mesin ini, pantau proses daripada mesin itu sendiri, kemudian pilih kawalan yang anda sanggup bayar. Setiap arahan di bawah adalah arahan yang anda jalankan pada mesin anda sendiri, terhadap trafik anda sendiri.

Empat kategori, dan sebab ia memerlukan kawalan berbeza

Trafik inferens model tidak dapat dielakkan. Ejen menghantar prompt anda, fail yang dibacanya, output arahan yang dijalankan, serta teks yang dijana sendiri ke titik akhir (endpoint) model. Inilah cara produk tersebut berfungsi. Satu-satunya keputusan sebenar ialah siapa yang menerimanya: API yang dikendalikan oleh pihak lain, atau model yang anda jalankan sendiri. Akaun awan syarikat (Bedrock, Vertex, Foundry) hanya menukar penerima, ia tidak menghapuskan aliran tersebut. Tiada apa-apa dalam bahagian lain catatan ini yang akan mengurangkan trafik inferens, jadi asingkan perkara ini dalam fikiran anda daripada tiga kategori yang lain.

Analitis produk dan pelaporan ranap (crash reporting) adalah aliran berbeza ke hos berbeza. Pembilang penggunaan, angka kependaman (latency), carian flag ciri dan stack trace biasanya dihantar ke nama hos yang tiada kaitan dengan API model, dan sering kali dihantar kepada penjejak ralat pihak ketiga. Vendor biasanya mendokumentasikan perkara ini sebagai "metrik" dan "laporan ralat" serta biasanya memberikan anda satu pemboleh ubah persekitaran (environment variable) bagi setiap kategori. Isipadunya sangat kecil, jadi kiraan bait tidak akan membantu anda mencarinya. Anda sedang memburu nama hos, bukan lebar jalur.

Pengekalan (retention) dan latihan adalah polisi, bukan paket. Sama ada vendor menyimpan prompt anda, berapa lama ia disimpan, dan sama ada mereka melatih model masa depan menggunakan data tersebut, semuanya tertulis dalam terma yang dilampirkan pada pelan anda. Pelan pengguna dan pelan komersial biasanya berbeza, dan aturan sifar-pengekalan biasanya merupakan perjanjian yang berasingan. Anda tidak boleh mengesahkan perkara ini dengan tcpdump, kerana paket tersebut kelihatan sama dalam kedua-dua keadaan. Baca terma tersebut, dan jika ia penting bagi majikan anda, dapatkan pengesahan secara bertulis.

Integrasi menambah satu hop secara senyap. Pelayan MCP (model context protocol), pasaran pemalam, semakan kemas kini automatik, alat carian web, semakan keselamatan yang menyelesaikan URL sebelum mengambilnya: setiap satu adalah permintaan ke hos yang bukan merupakan titik akhir model. Di sinilah kejutan berlaku, kerana perisian sokongan (harness) boleh menghalakan kerja yang anda sangka setempat melalui perkhidmatan mereka sendiri, dan sesuatu release boleh mula melakukan perkara itu tanpa mengubah satu baris pun konfigurasi anda. Anggap setiap alat yang anda tambah sebagai destinasi baharu sehingga anda telah memantaunya pada rangkaian.

Langkah 1: apakah yang didokumentasikan oleh vendor?

Buka rujukan tetapan dan halaman penggunaan data untuk ejen anda, kemudian bacanya dengan senarai istilah di tangan: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. Setiap istilah tersebut biasanya merupakan suis yang berasingan. Catatkan nama pemboleh ubah yang tepat, kerana langkah 2 akan menggunakan grep untuk mencarinya.

Satu istilah mungkin mengelirukan anda. Dalam beberapa ejen, "telemetry" dalam dokumentasi bermaksud eksport OpenTelemetry yang anda konfigurasikan untuk menghantar metrik ke pengumpul (collector) yang anda jalankan, iaitu bertentangan dengan data yang dihantar kepada vendor. Claude Code adalah salah satu daripadanya: menetapkan CLAUDE_CODE_ENABLE_TELEMETRY=1 akan memulakan eksport ke titik akhir (endpoint) yang anda namakan dalam OTEL_EXPORTER_OTLP_ENDPOINT, dan ia tidak berkaitan dengan analitik vendor itu sendiri, yang mempunyai kaedah opt-out yang berbeza. Tentukan arah aliran data sebelum anda menetapkan apa-apa.

Jangkakan adanya suis induk, dan jangkakan ia mempunyai kelompangan. Setakat Ogos 2026, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC dalam Claude Code mematikan metrik, laporan ralat, arahan maklum balas dan tinjauan sesi secara serentak, dan dokumentasi yang sama menyatakan bahawa ia tidak meliputi pemeriksaan keselamatan domain WebFetch, yang menghantar nama hos yang bakal anda ambil ke API vendor dan mempunyai tetapan berasingannya sendiri. Ini bukan aduan terhadap satu produk. Ini adalah bentuk masalah yang wujud di mana-mana: suis induk hanya meliputi kategori yang wujud semasa ia ditulis.

Jangkakan juga bahawa opt-out akan menyebabkan anda kehilangan sesuatu. Dokumentasi yang sama menyatakan bahawa melumpuhkan telemetri juga melumpuhkan penilaian bendera ciri (feature-flag) yang diperlukan oleh sesetengah ciri, jadi suis yang diaktifkan untuk privasi boleh mematikan ciri yang anda gunakan, tanpa mesej ralat yang menghubungkan kedua-duanya. Baca ayat di sebelah bendera tersebut, bukan sekadar nama bendera itu sahaja.

Langkah 2: konfigurasi manakah yang sebenarnya digunakan?

Tetapan yang anda tulis bukanlah tetapan yang digunakan. Ejen menggabungkan konfigurasi daripada beberapa fail, dan salah satunya berada di dalam repositori yang baru anda klon daripada orang lain. Mulakan dengan persekitaran shell anda sendiri.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Kemudian, cetak setiap fail tetapan yang dibaca oleh alat tersebut, mengikut urutan yang diberikan dalam dokumentasi. Bagi Claude Code, setakat Ogos 2026, ia adalah fail pengguna, dua fail projek, dan direktori polisi terurus pada Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Fail projek yang disertakan dengan git clone merupakan konfigurasi yang ditulis oleh orang lain, dan ia boleh mengaktifkan semula apa yang telah dimatikan oleh fail pengguna anda. Jika ejen mempunyai arahan status yang menyenaraikan sumber yang dimuatkan, itulah kebenaran mutlak yang paling pantas: Claude Code mencetak sumber tetapan yang dimuatkan dalam /status.

Semakan paling kukuh adalah dengan membaca proses yang sedang berjalan dan bukannya mana-mana fail. Berikan ejen akaun pengguna Linuxnya sendiri terlebih dahulu, yang menjadikan setiap arahan dalam catatan ini lebih pendek, kemudian baca persekitaran yang digunakan semasa proses itu dimulakan.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ menunjukkan pemboleh ubah yang dimiliki oleh proses semasa masa pelaksanaan (exec time), jadi ia dapat mengesan kes di mana eksport .bashrc anda tidak pernah sampai ke servis yang dimulakan oleh systemd. Jika pemboleh ubah yang anda tetapkan tiada di sini, ia tidak pernah berkuat kuasa, tidak kira apa yang dinyatakan oleh dotfiles anda.

Langkah 3: ke hos manakah ia bersambung?

Mulakan dengan soket terbuka, ditapis mengikut akaun yang menjalankan ejen tersebut.

sudo ss -tnpe state established

-e menambah medan uid: pada setiap baris, supaya anda boleh memisahkan sambungan ejen daripada sambungan pelayar anda tanpa perlu membaca nama proses. Catatkan alamat jauh, kemudian dapatkan nama di sebalik alamat tersebut. Sumber nama yang paling tepat ialah jabat tangan TLS (transport layer security), kerana setiap sambungan baharu bermula dengan ClientHello yang membawa medan SNI (server name indication), iaitu nama hos yang diminta oleh klien.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Anda mendapat satu baris bagi setiap sambungan baharu, yang merupakan inventori tepat yang anda perlukan: API model, pelayan kemas kini, hos analitik, penjejak ralat, dan apa-apa sahaja yang ditambah oleh integrasi. Lajur nama yang kosong bermakna klien tersebut menggunakan ECH (encrypted client hello), jadi nama hos tidak kelihatan pada talian, dan anda perlu bergantung pada alamat IP destinasi, carian terbalik (reverse lookup), atau proksi dalam langkah 4.

Pandangan DNS (domain name system) ialah semakan silang yang berguna, kerana ia menunjukkan nama yang dicari oleh ejen walaupun untuk sambungan yang tidak diselesaikan.

sudo tcpdump -ni any -l 'udp port 53'

Setiap baris pertanyaan berakhir dengan jenis rekod dan nama, dalam bentuk A? host.example.net. (39). Lakukan tangkapan pada any dan bukannya pada antara muka luaran, kerana dengan systemd-resolved aplikasi berkomunikasi dengan pendengar stub tempatan pada 127.0.0.53 dan hanya stub tersebut yang berkomunikasi dengan pihak luar. Jika anda tidak melihat sebarang trafik DNS langsung semasa ejen sedang berfungsi, runtime tersebut melakukan DNS over HTTPS sendiri, dan hanya langkah 4 yang akan memberikan anda nama-nama tersebut.

Lakukan tangkapan semasa ejen sedang melakukan kerja sebenar. Mulakan sesi, arahkan ia membaca fail, arahkan ia menjalankan arahan, arahkan ia melakukan sesuatu yang gagal. Trafik yang tercetus sekali sahaja semasa permulaan, atau hanya apabila pengecualian (exception) dilemparkan, tidak akan muncul dalam tangkapan semasa melahu, dan tangkapan semasa melahu ialah cara paling lazim yang menyebabkan audit mencapai kesimpulan salah yang meyakinkan.

Langkah 4: apakah kandungan permintaan tersebut?

Hostname memberitahu anda siapa. Untuk melihat apa, letakkan proksi yang anda kawal di hadapan ejen dan percayai pihak berkuasa sijil (CA) untuk runtime tersebut sahaja. mitmproxy ialah alat yang biasa digunakan. Projek ini mengesyorkan binari kendiri daripada mitmproxy.org, dan mendokumentasikan uv tool install mitmproxy sebagai laluan pakej Python.

mitmdump -w /tmp/agent-flows.mitm

Jalankan kali pertama akan menulis CA ke dalam ~/.mitmproxy/, di mana mitmproxy-ca-cert.pem ialah sijil itu sendiri. Dalam shell yang anda akan gunakan untuk melancarkan ejen, halakan klien kepada proksi dan sijil tersebut.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Banyak CLI ejen merupakan program Node, dan Node membaca NODE_EXTRA_CA_CERTS apabila proses bermula, jadi eksport pemboleh ubah tersebut sebelum anda melancarkan ejen dan bukannya dalam terminal lain selepas itu. Klien Python membaca REQUESTS_CA_BUNDLE atau SSL_CERT_FILE, dan binari Go yang menggunakan pustaka standard membaca SSL_CERT_FILE pada Linux. Buktikan laluan tersebut berfungsi dengan curl sebelum anda menyalahkan ejen.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Proksi yang berfungsi akan mencetak 200 dan permintaan tersebut akan muncul dalam output mitmdump. CA yang tidak dipercayai akan memberikan curl: (60) SSL certificate problem: self-signed certificate in certificate chain, dan perkara yang setara daripada ejen Node ialah ralat yang membawa kod SELF_SIGNED_CERT_IN_CHAIN. Baca aliran (flows) yang disimpan selepas itu dengan pemapar konsol, di mana anda boleh membuka satu permintaan dan membaca header serta badannya.

mitmproxy -r /tmp/agent-flows.mitm

Empat hasil perlu dinyatakan. Anda melihat permintaan tersebut, dalam kes ini baca dan buat keputusan. Ejen enggan bermula dengan ralat sijil, yang merupakan masalah kepercayaan dalam runtime tersebut dan bukan penemuan tentang vendor. Anda hanya melihat API model, yang bermaksud kategori lain dimatikan, atau ia dicetuskan pada acara yang anda tidak picu. Atau anda tidak melihat apa-apa langsung sedangkan ejen jelas berfungsi, yang bermaksud klien mengabaikan pemboleh ubah persekitaran proksi atau menyemat (pin) sijilnya, dan tiada tetapan aplikasi boleh dipercayai untuk memberitahu anda perkara sebenar. Hasil terakhir itulah yang paling penting, dan ia menghantar anda kembali ke langkah 3, kerana tangkapan paket (packet capture) tidak boleh dinafikan apabila melihat sambungan.

Kawalan, daripada paling lemah kepada paling kuat

Tetapan opt-out. Paling murah dan paling lemah, kerana ia bergantung kepada vendor yang mematuhinya dan hanya meliputi kategori yang sedia ada. Tetapkan ia supaya ia kekal selepas but semula dan sesi terminal baharu, sama ada dalam fail tetapan pengguna atau profil shell anda. Tambahkan DO_NOT_TRACK=1 semasa anda melakukannya: ia merupakan konvensyen yang dihormati oleh banyak alat baris perintah, termasuk beberapa ejen, dan ia tidak memerlukan sebarang kos. Kemudian, jalankan semula langkah 3 selepas kemas kini seterusnya, kerana pada masa itulah liputan berubah.

Sekatan egress. Di sini anda berhenti meminta dan mula menguatkuasakan. Jalankan ejen sebagai pengguna miliknya sendiri, kemudian benarkan pengguna tersebut menggunakan loopback dan DNS, dan sekat trafik yang lain. Ini menambah jadualnya sendiri, jadi ia tidak mengganggu peraturan firewall sedia ada.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Gunakan ia dengan sudo nft -f /etc/nftables.d/agent.nft, pantau pembilang dengan sudo nft list table inet agentegress, dan baca sekatan dengan sudo journalctl -k -g agent-egress-drop. Pembilang sekatan yang meningkat dengan nama hos yang tidak dijangka adalah tujuan utama latihan ini. Dua had yang jujur. meta skuid memadankan pengguna yang memiliki soket tersebut, jadi ia hanya berkesan selagi akaun itu tidak boleh bertukar menjadi pengguna lain: sudo tanpa kata laluan untuk ejen akan menjadikan peraturan ini sekadar cadangan. Selain itu, membiarkan UDP 53 terbuka kepada mana-mana pelayan akan meninggalkan saluran yang boleh membawa data keluar melalui nama pertanyaan (query names), jadi tutup juga saluran tersebut jika model ancaman anda memerlukannya, dengan menghalakan resolver ejen kepada hos yang anda kendalikan. Senarai putih nama hos lebih sesuai diletakkan dalam proksi berbanding dalam nftables, kerana titik akhir API berada di belakang rangkaian penghantaran kandungan (CDN) yang alamat IP-nya sentiasa berubah. Kos kawalan ini ialah gangguan dan penyelenggaraan: pemasangan pakej, git melalui SSH, dan semakan kemas kini ejen itu sendiri akan gagal sehingga anda membenarkannya, dan senarai itu kini menjadi tanggungjawab anda untuk diselenggara. Jika anda menyediakan ini pada pelayan dan bukannya komputer riba, akaun dan susun atur firewall yang sama adalah asas kepada menjalankan Claude Code dengan selamat pada VPS.

Mesin pakai buang. Berikan ejen mesin maya (VM) yang tidak menyimpan sebarang kelayakan yang penting dan dimusnahkan pada akhir tugasan. Ini tidak mengurangkan apa yang dihantar oleh ejen, ia mengurangkan apa yang ejen boleh akses untuk dihantar, yang biasanya merupakan risiko yang sebenarnya anda ambil berat. Gabungkan ia dengan peraturan egress di atas, kerana VM baharu dengan akses internet tanpa had masih boleh mencapai setiap hos dalam tangkapan anda. Kaedah ini, dan keadaan yang perlu anda bina semula setiap kali, dibincangkan dalam menjalankan ejen pengekodan dalam VM pakai buang, dan soalan mengenai saiz dalam menjalankan ejen pengekodan pada VPS.

Self-hosting model. Satu-satunya kawalan yang menghapuskan aliran inferens, kerana prompt tidak pernah meninggalkan perkakasan anda. Kosnya adalah nyata: anda tidak boleh melakukan self-host pada model tertutup, jadi ini bermakna memilih pemberat terbuka (open weights) dan menerima jurang keupayaan pada tugasan yang sukar, ditambah dengan perkakasan untuk menghidangkannya. Pertukaran ini dibincangkan dalam sama ada anda boleh melakukan self-host Claude, dan perbezaan keupayaan antara ejen utama dalam bagaimana Claude Code, Cursor, Codex dan Copilot berbeza.

Tiada satu pun daripada empat kawalan ini mengubah apa yang ejen dibenarkan untuk baca pada cakera, dan trafik inferens membawa apa sahaja yang dibacanya. Jika fail .env berada dalam direktori kerja, ia akan dihantar kepada model sebaik sahaja ejen melakukan grep untuk mencari nama pemboleh ubah. Menjauhkan bahan tersebut daripada capaian ejen adalah tugas berasingan, yang dibincangkan dalam menjauhkan rahsia daripada konteks ejen AI.

Perkara yang perlu diperiksa selepas setiap kemas kini

1. Bandingkan tetapan vendor dan halaman penggunaan data dengan apa yang anda rekodkan kali terakhir, cari suis baharu dan servis dinamakan yang baharu.
2. Baca semula persekitaran proses daripada /proc/<pid>/environ untuk mengesahkan bahawa pilihan keluar (opt-out) anda masih digunakan pada proses yang sedang berjalan.
3. Cetak semula fail tetapan projek, kerana git pull boleh membawa masuk fail konfigurasi yang telah diubah oleh rakan sekerja.
4. Jalankan tangkapan SNI untuk satu sesi penuh kerja sebenar dan bandingkan senarai nama hos dengan senarai terakhir anda.
5. Periksa pembilang drop firewall, kerana destinasi baharu biasanya muncul di situ sebelum anda menyedarinya di tempat lain.

Proses ini mengambil masa kira-kira sepuluh minit dan ia merupakan satu-satunya bahagian dalam proses yang tidak menjadi lapuk. Nilai lalai yang anda sahkan pada Ogos 2026 adalah fakta mengenai Ogos 2026. Tangkapan tersebut adalah fakta mengenai hari ini.

FAQ

Bolehkah saya menghalang ejen pengekodan saya daripada menghantar kod saya kepada model?

Tidak, dan sebarang tetapan yang mendakwa sedemikian sebenarnya merujuk kepada perkara lain. Menghantar prompt anda, fail yang dibaca oleh ejen, dan output arahan yang dijalankannya ke titik akhir model adalah cara inferens berfungsi, jadi satu-satunya pemboleh ubah ialah siapa yang menerimanya. Anda boleh menukar penerima dengan menghalakan ejen ke akaun awan syarikat atau ke model yang anda hoskan sendiri, dan anda boleh mengurangkan apa yang dihantarnya dengan mengehadkan perkara yang dibenarkan untuk dibaca. Mematikan analitik dan pelaporan ralat tidak menjejaskan aliran ini sama sekali.

Bagaimanakah cara saya melihat hos yang disambungkan oleh ejen pengekodan saya?

Jalankan ejen sebagai pengguna Linuxnya sendiri, kemudian tangkap TLS ClientHello bagi setiap sambungan baharu semasa anda menggunakannya: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Satu baris muncul bagi setiap sambungan, dengan alamat destinasi dan nama hos yang diminta. Semak silang nama tersebut dengan sudo tcpdump -ni any 'udp port 53', menangkap pada any kerana stub penyelesai tempatan pada 127.0.0.53 mengendalikan pertanyaan tersebut terlebih dahulu. Lakukan penangkapan semasa ejen melakukan kerja sebenar, kerana ping permulaan dan laporan ranap tidak akan muncul dalam tangkapan semasa melahu.

Proksi saya tidak menunjukkan trafik semasa ejen berfungsi. Apa yang tidak kena?

Sama ada klien mengabaikan HTTP_PROXY dan HTTPS_PROXY, atau ia menyematkan (pin) sijilnya dan menolak CA anda. Uji laluan tersebut dengan curl terlebih dahulu: jika curl mencapai internet melalui proksi dan ejen tidak muncul dalam senarai aliran, ejen tersebut tidak menggunakan pemboleh ubah persekitaran proksi. Sesetengah runtime memerlukan CA dibekalkan dengan cara tertentu, dan Node khususnya hanya membaca NODE_EXTRA_CA_CERTS pada permulaan proses, jadi mengeksportnya selepas melancarkan ejen tidak memberikan kesan. Apabila proksi tidak dapat melihat trafik, gunakan penangkapan paket, yang tidak boleh dipintas oleh mana-mana tetapan aplikasi.

Adakah mematikan telemetri menghalang kod saya daripada digunakan untuk latihan?

Tidak. Analitik dan pelaporan ranap adalah aliran yang berbeza daripada inferens, jadi melumpuhkannya hanya membuang pembilang penggunaan dan surih tindanan (stack traces), dan membiarkan setiap prompt pergi ke model seperti sebelumnya. Sama ada prompt tersebut disimpan, dan sama ada ia melatih model masa depan, ditetapkan oleh terma pelan anda, dan pelan pengguna serta pelan komersial biasanya berbeza. Itu adalah kontrak untuk dibaca dan bukannya paket untuk ditangkap, jadi semak halaman penggunaan data untuk pelan anda dan, jika perlu, aturkan perjanjian komersial atau tanpa-pengekalan (zero-retention) sebelum sesi pertama.