Keselamatan Agen DeepSeek V4 Pro Bergantung pada Harness, Bukan Model Semata-mata

Organisasi yang mahu menggunakan agen DeepSeek V4 Pro perlu menilai konfigurasi lengkap model–harness–tugasan–persekitaran, bukannya model secara berasingan. Ketersediaan melalui pelbagai antara muka mungkin membuktikan bahawa sesuatu runtime boleh berkomunikasi dengan model, tetapi ia tidak membuktikan prompt, alat, keizinan, memori, percubaan semula atau kesan sampingan akan berfungsi dengan cara yang sama pada setiap runtime.

Peraturan operasinya mudah: luluskan hanya konfigurasi khusus yang telah dipasak dan melepasi penilaian keselamatannya sendiri.

Mengapa harness mengubah sifat sebenar agen

Agen bukan sekadar model asas. Harness menentukan cara model menerima arahan, memilih alat, mengakses data, mengendalikan kegagalan dan mempengaruhi sistem luaran. Perbezaan penting boleh merangkumi:

• prompt sistem dan penyesuai;
• definisi serta pelaksanaan alat;
• skop keizinan dan pintu kelulusan;
• akar sistem fail dan akses rangkaian;
• sumber kelayakan serta identiti;
• tingkah laku proses anak dan kod yang dijana;
• logik percubaan semula, tamat masa dan keserentakan;
• keadaan sesi, ringkasan, cache dan memori berterusan.

Oleh itu, backend DeepSeek V4 Pro yang sama boleh mempunyai profil risiko berbeza apabila disalurkan melalui harness atau persekitaran pelaksanaan yang berlainan. Skema API yang serasi ialah ciri integrasi—bukan pensijilan keselamatan.

Apa yang ditunjukkan oleh keputusan AgentS4D—dan apa yang tidak

AgentS4D menilai konfigurasi runtime lengkap, bukan respons model secara terasing. Penanda aras itu menggunakan 328 kes yang disuntik risiko merentasi empat harness dan lima backend model, lalu menghasilkan 6,560 larian dalam sandbox. Ia melaporkan 4,461 larian tidak selamat, atau 68.0%, serta 4,344 larian, atau 66.22%, yang kedua-duanya tidak selamat dan dinilai selesai. 13

Penemuan utamanya ialah tugasan yang berjaya diselesaikan boleh berlaku serentak dengan pelaksanaan yang tidak selamat. Agen mungkin menghasilkan artifak yang diminta sambil membuat perubahan terlarang, mengendalikan data sensitif secara salah, memintas kawalan yang sepatutnya, atau mencetuskan kesan sampingan berbahaya yang lain.

Angka ini tidak boleh dianggap sebagai kadar insiden produksi DeepSeek V4 Pro. Penilaian tersebut menggunakan kes yang sengaja disuntik risiko dalam sandbox terkawal dan menggabungkan keputusan daripada pelbagai kombinasi model–harness. Jenis tugasan produksi, kawalan, pendedahan kepada kandungan adversarial, aset dan takrifan bahaya akan berbeza. Penanda aras ini membuktikan bahawa keselamatan runtime perlu diukur secara langsung—bukan meramalkan perkara yang akan dialami oleh setiap deployment. 135

Hadkan kesan maksimum setiap tindakan agen

Kawalan keselamatan perlu mengehadkan akibat kesilapan walaupun model atau alat bertindak di luar jangkaan.

Gunakan identiti khusus dengan keistimewaan minimum

Cipta identiti berasingan untuk agen, persekitaran dan penyewa. Elakkan kelayakan pekerja yang tersedia secara automatik, akses pentadbir produksi dan rahsia yang boleh digunakan semula secara meluas. Hadkan setiap identiti kepada sumber dan operasi yang diperlukan untuk satu tugasan.

Hadkan sistem fail dan rangkaian

• Lekapkan hanya akar ruang kerja khusus.
• Jadikan laluan yang tidak berkaitan benar-benar tidak boleh diakses, bukan sekadar disembunyikan.
• Senaraikan destinasi rangkaian, kaedah, port dan—jika berkaitan—jumlah trafik keluar yang dibenarkan.
• Asingkan keupayaan membaca, menyediakan draf, menulis ke persekitaran staging dan menulis ke produksi.
• Simpan rahsia dalam broker atau sistem token jangka pendek.
• Jangan sekali-kali meletakkan kelayakan jangka panjang dalam prompt, fail ruang kerja, pemboleh ubah persekitaran atau output alat.

Tindakan berimpak tinggi—seperti memadam data, menerbitkan kandungan, membuat bayaran, mengubah akses, melakukan deployment atau berkomunikasi dengan pihak luar—perlu melalui semakan dasar pada lapisan pelaksanaan atau memerlukan kelulusan jelas.

Semak seluruh rantaian pelaksanaan

Alat pihak pertama hanyalah sebahagian daripada permukaan serangan. Proses anak, arahan shell, kod yang dijana, pemasangan pakej, pelayan alat jauh, plugin dan kod kemahiran semuanya boleh menghasilkan kesan sampingan.

Dasar yang sama mesti terpakai pada semua laluan ini. Secara khususnya, halang pelaksanaan shell atau kod yang dijana daripada memintas kawalan sistem fail, rangkaian, kebenaran, pengelogan atau kelulusan.

Jadikan alat boleh dikuatkuasakan di luar model

Panggilan alat yang dijana model ialah permintaan yang tidak dipercayai. Pelayan alat—bukan model—mesti menguatkuasakan peraturan kebenaran dan keselamatan.

Gunakan skema yang sempit dengan kawalan seperti:

• nilai enum dan had panjang yang ditetapkan;
• laluan yang dinormalkan serta pengecam sumber yang jelas;
• senarai destinasi yang dibenarkan;
• had halaman dan saiz keputusan;
• pengesahan argumen di luar model;
• kebenaran di pihak pelayan untuk pemanggil, penyewa, sasaran dan operasi yang khusus.

Asingkan alat perancangan atau pratonton daripada alat yang menghasilkan kesan. Untuk operasi yang merosakkan atau sukar dipulihkan:

• wajibkan pratonton dan pengesahan atau token kelulusan;
• utamakan aliran kerja soft-delete, kuarantin atau boleh dipulihkan;
• wajibkan kunci idempotensi;
• tetapkan perkara yang berlaku apabila permintaan sama dicuba semula;
• pulangkan resit kekal supaya percubaan semula tidak mengulangi kesan.

Kawalan ini penting kerana panggilan alat dalam format JSON yang kelihatan sah masih boleh mengandungi sasaran tanpa kebenaran, laluan berbahaya, skop berlebihan atau operasi yang sepatutnya memerlukan semakan manusia.

Tetapkan tingkah laku keadaan dan memori sebelum deployment

Keadaan boleh membawa risiko merentasi giliran, tugasan, pengguna dan persekitaran. Organisasi perlu mendokumenkan serta menguatkuasakan peraturan kitar hayat bagi mesej, fail yang dimuat naik, fail ruang kerja, ringkasan, hasil alat, cache dan memori berterusan.

Sekurang-kurangnya, tetapkan perkara berikut:

• Pengasingan: asingkan keadaan mengikut pengguna, penyewa, tugasan dan persekitaran; jangan benarkan perkongsian merentas sesi secara tersirat.
• Pengekalan: tetapkan tempoh simpanan, penyulitan, kawalan akses dan peraturan pemadaman.
• Set semula: sediakan cara yang didokumenkan untuk mengosongkan konteks, memori, keadaan ruang kerja, kelayakan dan cache antara larian.
• Percubaan semula dan tamat masa: tetapkan bilangan serta belanjawan yang terhad; percubaan semula mesti mengekalkan idempotensi dan tidak meluaskan keistimewaan secara senyap.
• Keserentakan: tetapkan penguncian dan pengendalian konflik bagi fail dikongsi, kelulusan dan operasi luaran.

Anggap tingkah laku set semula keadaan sebagai sebahagian daripada sempadan keselamatan. Jika arahan lama, kelayakan atau hasil alat boleh muncul semula secara tidak dijangka dalam tugasan baharu, peningkatan model atau perubahan prompt boleh mengubah risiko dengan cara yang tidak dikesan oleh ujian respons semata-mata.

Anggap setiap pembawa risiko sebagai input yang tidak dipercayai

Suntikan prompt tidak semestinya datang daripada mesej langsung pengguna. Arahan berisiko boleh disembunyikan dalam:

• dokumen yang dimuat naik dan fail repositori;
• laman web yang diambil semula;
• kemahiran serta plugin luaran;
• respons daripada perkhidmatan alat;
• memori yang disimpan;
• ringkasan dan konteks cache;
• teks yang diberikan pengguna.

Huraikan, labelkan dan petik bahan ini sebagai data. Ia tidak boleh dibenarkan mengubah kuasa agen, dasar, pemilihan alat, penggunaan kelayakan atau keperluan kelulusan. Runtime perlu menguatkuasakan pemisahan itu, bukan bergantung sepenuhnya pada model untuk mengenal pasti arahan berniat jahat.

Senarai semak pelepasan khusus harness

Sebelum deployment diluluskan, bekukan dan rekod konfigurasi tepat berikut:

1. Model dan penghalaan: pengecam serta versi model, laluan penyedia, tetapan inferens atau tahap usaha, dan penyesuai keserasian.
2. Tingkah laku harness: versi harness, prompt sistem, logik sesi, peraturan percubaan semula dan tamat masa, dasar proses anak serta pelaksanaan memori.
3. Alat dan dasar: definisi serta versi alat, versi dasar, ambang kelulusan, logik kebenaran dan sempadan kepercayaan pelayan alat.
4. Keizinan: identiti, skop, akar sistem fail, destinasi rangkaian, sumber kelayakan dan laluan penulisan ke produksi.
5. Semantik keadaan: pengasingan, pengekal­an, set semula, tingkah laku cache, keserentakan dan sempadan merentas sesi.
6. Liputan adversarial: suntikan prompt melalui setiap pembawa risiko, cubaan confused deputy, pendedahan kelayakan, traversal laluan, penyalahgunaan SSRF atau trafik keluar, respons alat berniat jahat, penduaan percubaan semula, keracunan memori dan pintasan kelulusan.
7. Bukti: versi prompt dan dasar, panggilan serta hasil alat, kelulusan, keputusan dasar, perbezaan ruang kerja, permintaan keluar, identiti yang digunakan, artifak akhir, hasil penyelesaian dan hasil keselamatan di bawah ID larian yang stabil.

Nilai penyelesaian tugasan dan keselamatan secara berasingan. Artifak akhir yang betul tidak boleh mengimbangi kesan sampingan yang tidak selamat—itulah pengajaran utama daripada keputusan AgentS4D. 12

Ulang uji setiap kali konfigurasi berubah

Sasaran ujian yang diluluskan ialah konfigurasi yang dipasak, bukan label kekal seperti “agen DeepSeek V4 Pro”. Jalankan semula suite khusus konfigurasi selepas sebarang perubahan penting pada:

• model atau laluan penyedia;
• tetapan inferens atau tahap usaha;
• prompt sistem atau penyesuai;
• logik harness atau sesi;
• alat atau pelayan alat jauh;
• dasar keizinan dan kelulusan;
• penghalaan kelayakan;
• tingkah laku memori, percubaan semula, tamat masa atau keserentakan;
• sempadan rangkaian atau sistem fail.

Pendekatan ini menjadikan keselamatan runtime sebagai keputusan pelepasan yang boleh diukur, terikat pada persekitaran tepat yang mampu menghasilkan kesan di dunia sebenar—bukan andaian umum tentang kualiti model.