Beri agen AI akses ke terminal, dan kesalahannya bisa berdampak di luar percakapan. Jawaban yang salah dapat dikoreksi. Perintah yang salah bisa menimpa berkas, membocorkan kredensial, atau menyentuh sistem yang tidak berkaitan dengan tugasnya.

Pada 28 September 2026, NVIDIA mengumumkan Open Agent Safety Platform. Platform ini menggabungkan perangkat lunak pembatas agen saat berjalan dengan desain referensi pemantauan pada tingkat infrastruktur. Dua komponen utamanya adalah OpenShell, runtime sumber terbuka yang membatasi akses agen, dan Sentry, pengawas terpisah yang berjalan pada DPU BlueField-4.

Pengumuman ini relevan bagi tim yang memberi agen waktu kerja lebih panjang dan akses ke lebih banyak layanan. Instruksi seperti “jangan ubah produksi” tetap berguna. Namun, lingkungan eksekusi juga harus mampu menolak perubahan tersebut jika agen tetap mencobanya.

Ilustrasi sampul dibuat untuk Linmas guna menggambarkan batas akses agen. Gambar ini merupakan ilustrasi editorial, bukan diagram arsitektur resmi NVIDIA.

Apa yang diumumkan NVIDIA

Dalam penjelasan arsitektur yang terbit pada hari yang sama, NVIDIA membagi perlindungan agen menjadi tiga lapisan: aplikasi, runtime, dan infrastruktur. Model, alat, dan data berada di lapisan aplikasi. Runtime mengatur tempat agen bekerja dan menegakkan izin. Infrastruktur menyediakan sumber daya komputasi serta kontrol tambahan.

OpenShell menjalankan agen dalam sandbox. Operator menentukan akses yang diperlukan tugas, sementara kontrol di luar workload agen membatasi berkas, proses, jaringan, dan kredensial. Agen boleh memutuskan untuk mencoba suatu tindakan, tetapi tindakan itu tetap harus melewati aturan lingkungan.

Sentry menambahkan pemantauan melalui perangkat keras BlueField-4, terpisah dari host yang menjalankan agen. Menurut NVIDIA, susunan ini memungkinkan pengamatan dan penegakan kebijakan dari wilayah kepercayaan di luar jangkauan agen. NVIDIA juga mengklaim Sentry dapat mengarantina agen dalam hitungan milidetik. Angka tersebut merupakan klaim vendor, bukan hasil pengujian independen untuk artikel ini.

Perbedaan ini penting saat memilih komponen. OpenShell adalah perangkat lunak sumber terbuka. Lapisan Sentry dalam desain referensi menggunakan BlueField-4. Memasang OpenShell saja tidak menghadirkan seluruh perlindungan perangkat keras yang dibahas dalam pengumuman.

Saat instruksi tidak tepercaya berubah menjadi tindakan

Bayangkan agen diminta merangkum issue repository. Salah satu komentar menyuruhnya membaca berkas kredensial dan mengirim isinya ke layanan eksternal. Ini contoh indirect prompt injection: instruksi berbahaya masuk melalui materi yang seharusnya diperlakukan sebagai data. Skenario ini menjelaskan risiko, bukan insiden yang dilaporkan.

Model mungkin mengenali dan mengabaikan instruksi itu. Pertanyaan operasional muncul ketika model gagal: apakah agen bisa membaca berkas kredensial? Apakah tujuan pengiriman diizinkan? Apakah proses anak mewarisi pembatasan yang sama?

Kontrol runtime menjawab pertanyaan tersebut dengan memeriksa tindakan yang dicoba. Berkas sensitif dapat ditempatkan di luar workspace yang boleh dibaca agen. Permintaan jaringan dapat ditolak. Percobaan itu juga dapat dicatat agar operator bisa menyelidikinya.

Prompt injection tetap menjadi masalah. Kontrol ini membatasi tindakan yang tersedia bagi agen dan kerusakan yang bisa terjadi setelah agen mengikuti instruksi yang salah.

OpenShell memeriksa lebih dari tujuan koneksi

Panduan teknis OpenShell 0.1.0 menjelaskan supervisor yang dapat memeriksa lalu lintas HTTP, GraphQL, dan Model Context Protocol sesuai konfigurasi. Dengan kebijakan yang tepat, supervisor dapat mengizinkan pembacaan dari layanan sambil menolak penulisan.

Mengizinkan koneksi ke layanan repository belum menjawab pertanyaan penting: apakah agen boleh membaca issue, mengubah berkas, atau menghapus sesuatu? Satu tujuan koneksi dapat menyediakan operasi dengan konsekuensi yang sangat berbeda.

NVIDIA juga menjelaskan mekanisme yang menyimpan kredensial asli di luar workload agen. Kredensial disisipkan melalui jalur permintaan yang diizinkan, sehingga agen tidak perlu menerima rahasianya. Layanan tujuan tetap menegakkan izin kredensial tersebut; OpenShell menambahkan pembatasan atas cara agen menggunakan akses itu.

Perubahan izin memiliki jalur tinjauan sendiri. Jika policy advisor diaktifkan, agen dapat mengusulkan perubahan dengan cakupan sempit. Menurut panduan, usulan secara bawaan menunggu tinjauan manusia, dan agen tidak dapat menyetujui permintaannya sendiri. Perubahan akses jaringan bisa berlaku saat sandbox berjalan. Perubahan pembatasan sistem berkas dan proses memerlukan sandbox baru.

Hal yang tetap perlu diuji

OpenShell menyediakan policy prover yang memakai logika formal untuk memeriksa izin dalam kebijakan. Alat ini dapat menunjukkan apakah izin yang dimodelkan tetap berada dalam batas yang ditentukan operator, atau mengidentifikasi tindakan yang melampauinya.

Kata “dimodelkan” membatasi kesimpulan tersebut. Pembuktian kebijakan tidak membuktikan seluruh aplikasi, dependency, dan konfigurasi deployment bebas kerentanan. Aturan juga bisa konsisten secara logis tetapi memberikan akses lebih luas daripada kebutuhan bisnis.

NVIDIA melaporkan eksperimen adversarial hingga dua jam, ketika agen mencoba memperoleh izin untuk mengubah repository yang dilindungi. Dalam pengujian itu, gabungan tinjauan dan kontrol runtime mencegah penulisan ke repository tersebut. Hasilnya menjadi bukti untuk skenario itu. Hasil tersebut belum menjawab perilaku konfigurasi Anda dengan alat, identitas, atau jalur akses yang berbeda.

Lima pemeriksaan sebelum memperluas akses agen

Bagi tim pengembang, pengumuman ini menjadi alasan untuk meninjau kembali alur agen yang sudah digunakan. Pilih tugas nyata, lalu periksa:

  1. Akses minimum yang diperlukan. Agen peringkas issue biasanya tidak membutuhkan izin menulis repository atau kredensial deployment. Mulai dari kebutuhan itu saat memberikan izin.
  2. Semua jalur menuju tindakan yang sama. Memblokir satu alat belum cukup jika shell, kode yang dihasilkan, atau proses anak masih dapat menjalankan operasi melalui cara lain.
  3. Pihak yang meminta dan menyetujui akses. Permintaan harus menyebutkan tujuan serta cakupan izin tambahan. Hindari persetujuan luas hanya agar tugas segera berjalan.
  4. Catatan yang mendukung penyelidikan. Rekam identitas agen, tindakan yang dicoba, keputusan kebijakan, dan hasilnya. Jangan masukkan token atau konten sensitif yang tidak diperlukan.
  5. Cara memutus akses. Uji pencabutan kredensial, penghentian sesi, dan penonaktifan workload dengan data uji. Operator membutuhkan respons yang jelas ketika agen melampaui tugasnya.

Lakukan pemeriksaan di lingkungan yang disiapkan untuk pengujian. Catat operasi yang berhasil, yang ditolak, dan apakah pekerjaan sah tetap dapat diselesaikan. Kebijakan yang memblokir semuanya sulit dipertahankan dalam pekerjaan sehari-hari.

Peran tinjauan keamanan

Kontrol runtime dan tinjauan kode menangani bagian pekerjaan yang berbeda. Sandbox dapat membatasi akses agen, tetapi kode yang dihasilkannya masih bisa memiliki kesalahan otorisasi atau asumsi bisnis yang keliru. Kode itu tetap harus ditinjau sebelum menjadi bagian dari aplikasi.

Di Linmas, tinjauan keamanan kode buatan AI dimulai dari perubahan yang jelas, bukti risiko, perbaikan, dan verifikasi. Alur ini membantu tim menilai batas yang hendak ditegakkan. Linmas adalah kumpulan skill tinjauan defensif; Linmas tidak menyediakan sandbox runtime atau menggantikan OpenShell maupun Sentry.

Sebelum memberi agen berikutnya akses lebih luas, pilih satu tindakan yang harus dilarang dan buktikan bahwa lingkungan eksekusi menolaknya. Simpan bukti bersama konfigurasi yang diuji. Ulangi pemeriksaan ketika model, alat, atau tugas berubah.

Sumber dan catatan editorial

Artikel ini ditulis pada 29 September 2026 berdasarkan pengumuman dan dokumentasi resmi NVIDIA yang diakses pada hari tersebut. Kemampuan produk diatribusikan kepada vendor. Contoh risiko dan saran pemeriksaan merupakan analisis editorial Linmas; artikel ini tidak melaporkan pengujian langsung atas OpenShell atau Sentry.