Agen AI yang bertindak di akun terhubung dapat mengubah data atau memicu proses bisnis. Sebelum memilih penyedia, pemilik bisnis dan peninjau keamanan dapat membandingkan kendali untuk satu alur kerja usulan dengan persyaratan tertulis organisasi. Hasilnya berupa catatan bukti bertanggal. Jawaban yang belum ada tetap terbuka; klaim produk saja tidak menunjukkan bahwa suatu tindakan akan dihentikan. Metode ini merujuk pada NIST AI Risk Management Framework Playbook dan AI Agent Security Cheat Sheet dari OWASP; keduanya tidak menilai calon penyedia tersebut.

Perubahan utama

  • Apa yang berubah: Pembelian agen dapat mencakup tindakan yang didelegasikan dalam sistem bisnis. Pembeli perlu tahu siapa yang bisa membuat agen bertindak, terhadap apa, dan dengan persetujuan siapa.
  • Mengapa penting: Pembeli dapat mengaitkan setiap tindakan usulan dengan kendali bernama dan buktinya. Ini memberi pemilik bisnis dan peninjau keamanan dasar konkret untuk membatasi akses atau menahan pembelian.
  • Yang perlu diperhatikan: Keputusan bergantung pada bukti untuk versi produk dan alur kerja yang tepat. Kendali dalam dokumentasi mungkin masih memerlukan demonstrasi terawasi sebelum diterima peninjau untuk penggunaan yang dimaksud.

Kumpulkan empat masukan

Gunakan profil risiko tertulis yang sudah ada dan disetujui organisasi. Profil harus menyebut pemilik bisnis, hasil yang dituju, data dan tujuan yang diizinkan, tindakan yang boleh dilakukan, kewenangan persetujuan, konsekuensi yang tidak dapat diterima, serta kondisi penghentian. Jika belum ada, minta pihak bertanggung jawab menyusunnya sebelum menilai pemasok. Panduan ini tidak dapat menetapkan toleransi risiko organisasi untuk mereka.

Panduan MANAGE 3.1 dari NIST meminta penerapan toleransi risiko organisasi pada sistem AI pihak ketiga dan pendokumentasian kendalinya. Playbook menawarkan saran sukarela, bukan daftar pengadaan universal. Pertanyaan kendali tindakan di bawah juga merujuk panduan keamanan khusus agen dari OWASP. Kerangka ini membantu menemukan pertanyaan berguna; bukti pemasok sendiri harus menjawabnya.

Sebutkan satu calon penyedia beserta produk dan versi penerapan yang persis sedang dipertimbangkan. Dapatkan dokumentasi terbaru dan bukti yang berwenang dibagikan pemasok. Berikan peninjau keamanan dan penanggung jawab pengadaan akses ke catatan perbandingan. Simpan berkas arsitektur atau bukti sensitif di tempat pribadi yang disetujui; lembar kerja dapat menautkannya tanpa menyalin rahasia.

1. Ubah alur kerja menjadi persyaratan

Daftarkan setiap tindakan agen yang diusulkan, sistem sasarannya, serta data yang harus dibaca atau diubah. Pisahkan pembacaan dari penulisan dan tindakan yang terlihat di luar atau tidak dapat dibatalkan. Untuk setiap tindakan, salin persyaratan relevan dari profil risiko tertulis: identitas yang diizinkan, cakupan alat dan sasaran, persetujuan, pencatatan, penanganan data, penghentian dan pemulihan. Catat pemilik dan tanggal profil.

Buat satu baris per persyaratan. Hal yang tidak diketahui menjadi terlihat, bukan terkubur dalam skor keseluruhan penyedia. Larangan agen mengakses akun tertentu juga memerlukan baris seperti tindakan yang diizinkan.

2. Telusuri siapa yang bertindak dan apa yang dapat dieksekusi

Tanyakan manusia, akun layanan, atau identitas agen mana yang memulai setiap tindakan, tempat penyimpanan kredensial, dan apakah agen dapat meneruskan permintaan ke agen lain. Kenali komponen yang memeriksa izin saat eksekusi. Bandingkan izin alat penyedia yang sebenarnya dengan alat, operasi, akun, dan sasaran yang diizinkan profil. Minta bukti konfigurasi atau arsitektur yang berlaku bagi versi produk ini; pernyataan dalam perintah merupakan bukti lemah bahwa batas benar-benar ditegakkan.

Untuk tindakan yang perlu persetujuan, tanyakan apa yang dilihat peninjau sebelum eksekusi dan bagaimana persetujuan terikat pada pelaku, panggilan alat yang tepat, sasaran, dan parameter. Cari tahu akibat persetujuan kedaluwarsa, ditolak, dipakai dua kali, atau tindakan yang diminta berubah. Catat cara mencabut akses dan siapa yang dapat menghentikan eksekusi aktif. Layar persetujuan dan pemeriksaan saat eksekusi menjawab pertanyaan berbeda; minta bukti keduanya jika profil mensyaratkan keduanya.

3. Ikuti data dan catatan tindakan

Gambarkan jalur usulan dari masukan ke model, alat, penerima luar, salinan tersimpan, dan catatan. Tanyakan data yang diterima setiap komponen, siapa yang bisa mengambilnya, serta cara kerja retensi dan penghapusan. Sertakan subpemroses atau perpindahan antarsistem yang penting bagi profil. Tandai pertanyaan tujuan atau retensi yang belum terjawab sebagai tidak diketahui; jangan menyimpulkan perlindungan privasi dari pernyataan kebijakan yang umum.

Minta catatan eksekusi untuk versi terkait. Bisakah peninjau menghubungkan pelaku dan versi kebijakan dengan panggilan alat usulan, persetujuan atau penolakan, sasaran tepat, dan hasilnya? Periksa apakah catatan hanya menunjukkan keputusan, eksekusi nyata, atau keduanya. Tangkapan layar, ekspor konfigurasi, dan jejak peristiwa lengkap membuktikan hal berbeda. Catat bagian yang disamarkan sehingga menghambat perbandingan, sambil menjaga kredensial dan data pribadi tetap di luar lembar kerja.

4. Minta bukti kegagalan

Minta bukti terikat versi untuk tindakan yang diizinkan dan jalur kegagalan yang disyaratkan profil: persetujuan ditolak atau kedaluwarsa, alat atau sasaran di luar cakupan, eksekusi terputus, serta kegagalan pencatatan atau pemeriksaan kebijakan jika relevan. Catat apa yang diuji, kapan, dengan kebijakan dan pengaturan alat apa, hasil yang diharapkan, dan hasil yang diamati. Rencana uji adalah permintaan bukti, bukan hasil pengamatan.

Peninjau keamanan yang bertanggung jawab menentukan perlunya demonstrasi terawasi dan mengizinkan cakupannya. Gunakan masukan dan akun nonproduksi yang diizinkan. Jangan menghubungkan sistem aktif hanya untuk melengkapi lembar pengadaan. Jika pemasok tidak dapat memberikan bukti, catat kekurangan dan permintaan berikutnya, bukan membayangkan hasil pengujian.

5. Catat keputusan dan pekerjaan terbuka

Untuk setiap baris, beri tanda sesuai hanya jika bukti yang diberikan menjawab persyaratan tertulis bagi versi dan alur kerja ini. Tandai kesenjangan jika bertentangan, atau tidak diketahui jika bukti tidak ada atau terlalu lemah. Catat rekaman yang bertentangan dan pihak yang harus menyelesaikannya. Pemilik bisnis dan peninjau keamanan yang bertanggung jawab kemudian mencatat keputusan sebenarnya: meminta bukti tambahan, mencari persetujuan uji coba terbatas, menunda, atau menolak. Kesesuaian adalah penilaian bukti, bukan jaminan sistem aman atau pengganti proses pembelian organisasi.

Beri tanggal catatan dan tinjau ulang baris terdampak ketika alur kerja, versi produk, kebijakan, akun terhubung, atau tujuan data berubah. Uji coba berikutnya memerlukan izin, batasan, dan peninjauan sendiri.

Persyaratan dari profil tertulis

Bukti penyedia, versi, dan tanggal

Jenis bukti dan hal yang ditunjukkan

Sesuai, kesenjangan, atau tidak diketahui

Peninjau dan tindakan berikutnya

[Satu persyaratan tindakan atau kendali]

[Tautan pribadi atau rujukan dokumen; versi; tanggal]

[Klaim, konfigurasi, catatan peristiwa, atau demonstrasi yang diamati; keterbatasan]

[Pilih satu dan jelaskan]

[Nama, permintaan bukti, atau keputusan]

Kepala catatan: alur kerja dan pemilik; versi profil risiko dan tanggal persetujuan; produk calon dan versi penerapan; tanggal peninjauan; peninjau keamanan; penanggung jawab pengadaan; lokasi bukti dengan akses terbatas. Catatan keputusan: keputusan, baris belum terselesaikan, batasan yang diterima atau kendali pengganti, pemberi persetujuan yang bertanggung jawab, dan pemicu peninjauan berikutnya. Biarkan kolom kosong hingga pihak bertanggung jawab benar-benar meninjaunya.

Panduan publik yang dipakai untuk menyusun pertanyaan ini tersedia gratis. Persiapan perbandingan memerlukan waktu staf dan peninjau. Bukti pemasok, akses rahasia, serta demonstrasi yang diizinkan dapat menambah biaya atau membatasi hal yang bisa diverifikasi; dapatkan ketentuan sebenarnya dari calon penyedia. Kajian dokumentasi ini tidak menguji penyedia maupun menetapkan kepatuhan hukum atau ambang pembelian universal.

Sumber dan bacaan lanjutan

  1. NIST AI RMF Playbook, Manage mendukung penerapan toleransi risiko organisasi sendiri pada sumber daya AI pihak ketiga, pendokumentasian kendali, dan penilaiannya. Halaman daring menyatakan AI RMF 1.0 sedang diperbarui dan Playbook akan menyusul; tanggal revisi halaman tidak disebutkan. Halaman itu tidak menilai penyedia ini.
  2. Pengantar NIST AI RMF Playbook menjelaskan saran sebagai sukarela dan menyatakan Playbook bukan daftar yang harus diikuti seluruhnya. Lembar kerja ini adalah sintesis BIG CHANGE untuk tugas pembaca yang disebutkan.
  3. OWASP AI Agent Security Cheat Sheet membahas alat bercakupan terbatas, otorisasi saat eksekusi, persetujuan yang terikat tindakan, pencatatan, perlindungan data, serta bukti validasi terikat versi. Halaman saat ini tidak menyebut versi atau tanggal rilis. Rekomendasi merupakan kategori bukti, bukan bukti bahwa pemasok menerapkannya.