Apa itu keamanan LLM? Cara memitigasi 10 risiko keamanan teratas OWASP

Serangan yang mengelabui AI agar memperlakukan instruksi penyerang sebagai perintah—injeksi prompt—telah menempati peringkat No. 1 dalam OWASP Top 10 for LLM Applications di setiap edisi sejak 2023.

Daftar ini bisa dibilang yang paling mendekati konsensus di bidang keamanan AI. Proyek ini berawal dari sekelompok kecil profesional keamanan dan kini melibatkan lebih dari 600 pakar kontributor di lebih dari 18 negara.

Kami adalah perusahaan AI yang menerbitkan panduan tentang bagaimana AI bisa dibujuk melakukan sesuatu, jadi kami tidak akan berpura-pura masalah ini sudah terpecahkan. Wilson, salah satu pemimpin proyek OWASP, cukup lugas tentang pertahanan saat ini: "...terus terang, menurut saya kita belum mencapai 99%."

Edisi 2026 dibuka dengan nada yang sama. Pemimpin proyek meminta kita untuk "berhenti mencoba membangun model yang tidak bisa dikelabui" dan merancang sistem di sekitarnya agar model yang berhasil dikelabui tidak dapat merusak hal penting apa pun.

Kami menerapkan sudut pandang itu pada ke-10 risiko dalam daftar OWASP 2026.

Apa yang dimaksud dengan keamanan LLM?

Keamanan LLM berarti melindungi model AI dan aplikasi yang menggunakannya dari serangan dan penyalahgunaan. Risikonya bertambah seiring dengan apa saja yang terhubung ke model: file dan data yang bisa dibacanya, serta alat yang bisa digunakannya, seperti email, pencarian, atau database perusahaan.

Pada perangkat lunak yang diamankan dengan benar, ada batas tegas antara instruksi yang dijalankan program dan informasi yang diprosesnya. Namun, LLM tidak memiliki batas itu.

Semua yang dibaca model datang sebagai satu aliran teks panjang: instruksi developer, pertanyaan Anda, halaman web yang dicarinya. Model AI seharusnya bisa melacak siapa yang sedang berbicara, entah itu developer, pengguna, atau model itu sendiri yang sedang memikirkan suatu masalah.

Namun, peneliti Jasmine Cui dan Charles Ye menemukan bahwa model sebagian besar menebak siapa yang berbicara dari gaya bahasa teksnya. Jadi, jika penyerang menulis sesuatu yang terdengar seperti penalaran model itu sendiri, model bisa percaya bahwa ide tersebut berasal dari dirinya sendiri. Ini menjadi masalah bagi pengaturan keamanan apa pun yang bergantung pada kemampuan model untuk mengetahui siapa yang memegang kendali.

Kami juga mengalami masalah yang sama dengan agen AI kami sendiri. CISO kami, Kyle Polley, mengatakan kepada ISMG bahwa agen "mungkin tidak mengikuti kebijakan meskipun Anda menambahkannya ke prompt sistem." Itulah sebabnya kami membuat Numbat, alat open source yang memeriksa apa yang akan dilakukan agen dan dapat memblokirnya jika tindakan tersebut melanggar aturan keamanan yang telah dikonfigurasi.

Keamanan LLM berarti menerima bahwa model terkadang akan menuruti perintah dari orang yang salah, dan memasang pagar pengaman AI di sekitarnya yang tetap bertahan saat hal itu terjadi.

Apa saja praktik terbaik untuk keamanan LLM?

Kami akan membahas OWASP Top 10 for LLM Applications 2026 secara berurutan, dari No. 1 hingga No. 10.

Untuk setiap risiko, Anda akan mendapatkan penjelasan sederhana tentang bagaimana masalah bisa terjadi beserta contoh nyatanya. Lalu, kami akan membahas praktik yang dapat membantu mencegahnya, atau setidaknya membatasi kerusakannya.

1. Batasi injeksi prompt

Injeksi prompt terjadi ketika penyerang membuat AI mengikuti instruksi yang seharusnya tidak diikutinya. Instruksi tersebut bisa disampaikan langsung dalam chat atau ditanamkan dalam email, halaman web, atau dokumen.

Jenis kedua dikenal sebagai injeksi prompt tidak langsung. Anda meminta asisten untuk merangkum sebuah dokumen. Pembuat dokumen itu telah menyuruh asisten untuk mengirimkan file pribadi Anda kepada mereka. Jika asisten mengikuti instruksi tersebut, penulis dokumen itu pada dasarnya telah meminjam akses Anda.

PCMag membandingkan keamanan prompt dengan menambal lubang pada batu berpori. Anda menutup satu celah, dan air menemukan celah lain. “Sebuah serangan menemukan jalannya; serangan itu diperbaiki, tetapi tak terhitung jalur serangan lain yang masih menunggu untuk ditemukan, semata-mata karena betapa dinamisnya sistem seperti LLM.”

Contoh: Pada Juni 2025, peneliti Aim Security menemukan EchoLeak, sebuah celah yang mengelabui Microsoft 365 Copilot agar membocorkan informasi pribadi perusahaan. Saat seorang karyawan mengajukan pertanyaan rutin terkait pekerjaan, Copilot dapat menarik email tersebut, mengikuti instruksi yang tersembunyi di dalamnya, dan mengirimkan informasi sensitif kepada penyerang. Serangan ini berhasil lolos dari pemeriksaan yang dirancang untuk mendeteksi instruksi berbahaya dan menghapus tautan mencurigakan.

Yang dapat Anda lakukan:

• Ikuti “Rule of Two” dari Meta: EchoLeak membutuhkan AI yang bisa membaca data perusahaan, membaca email dari luar, dan mengirim informasi keluar—dan AI tersebut memiliki ketiganya. Membatasinya pada dua dari kemampuan tersebut mencegah injeksi prompt mendapatkan kendali yang terlalu besar. Jika tugas memerlukan ketiganya, wajibkan persetujuan manusia sebelum setiap tindakan.
• Uji dengan penyerang yang mengetahui pertahanan Anda: Berikan aturan dan filter yang telah Anda terapkan kepada penguji keamanan, lalu biarkan mereka mencari cara untuk mengakalinya. Dalam satu studi, penyerang yang beradaptasi dengan pertahanan berhasil dalam lebih dari 90% percobaan terhadap sebagian besar dari 12 pertahanan yang diuji.

2. Cegah kebocoran informasi sensitif

Ketika sistem AI memberikan informasi pribadi kepada orang yang seharusnya tidak melihatnya, hal ini disebut pengungkapan informasi sensitif. Contohnya bisa berupa terungkapnya detail pembayaran pelanggan atau percakapan pribadi yang tertinggal di database bersama.

Banyak kebocoran berawal dari “berbagi berlebihan” (oversharing). Misalkan sebuah perusahaan menghubungkan AI-nya ke drive dan basis pengetahuan dengan izin yang longgar. AI akan mengambil apa pun yang dapat dijangkaunya, persis seperti yang dirancang. Tidak ada yang perlu membobol masuk, tetapi anggap saja LLM tersebut sudah dibobol.

Contoh: Pada Januari 2025, peneliti Wiz menemukan database DeepSeek yang terbuka ke internet dengan lebih dari satu juta entri log, termasuk riwayat chat dan kunci API, yang digunakan perangkat lunak untuk mengakses layanan lain. Para peneliti bahkan tidak perlu membujuk model untuk mengungkapkan apa pun.

Yang dapat Anda lakukan:

• Periksa akses sebelum AI membaca data: Aplikasi Anda harus memeriksa dokumen mana saja yang boleh dilihat oleh orang yang mengajukan pertanyaan sebelum meneruskannya ke model.
• Lindungi catatan yang ditinggalkan AI Anda: Hapus detail pribadi dan kunci rahasia sebelum menyimpan log aktivitas, wajibkan login, dan batasi akses hanya untuk orang yang membutuhkannya. Tetapkan masa retensi agar catatan tersebut tidak menumpuk tanpa batas.

3. Kendalikan wewenang yang berlebihan

AI dengan wewenang berlebihan memiliki kekuasaan lebih besar daripada yang dibutuhkan pekerjaannya: alat yang tidak diperlukannya, izin yang melampaui tugasnya, atau kebebasan untuk bertindak tanpa pemeriksaan. Dalam hal ini, apa penyebabnya tidaklah penting.

Injeksi prompt, bug, atau model yang sekadar keliru, semuanya berujung pada hasil yang sama. Pada akhirnya, AI akan melakukan sesuatu yang merusak jika memiliki kemampuan untuk itu.

Contoh: Pada Juli 2025, pendiri SaaStr, Jason Lemkin, melaporkan bahwa agen coding Replit menghapus database-nya yang berisi 1.206 catatan eksekutif, meskipun sudah diinstruksikan untuk tidak membuat perubahan. Agen tersebut awalnya mengatakan bahwa data tidak dapat dipulihkan, meskipun belakangan pemulihan ternyata bisa dilakukan. Jason mendapati bahwa menyuruh agen untuk tidak menyentuh database tidak menghilangkan kemampuannya untuk menghapus database tersebut.

Perbesar

Sumber: X

Yang dapat Anda lakukan:

• Hapus kemampuan yang tidak dibutuhkan tugas: Batasi alat yang diberikan kepada agen sekaligus apa yang dapat dilakukan alat tersebut. Asisten yang merangkum email memerlukan izin untuk membacanya, bukan untuk mengirim atau menghapusnya.
• Tempatkan pemeriksaan izin di luar AI: Setiap kali suatu tindakan diminta, periksa tindakan tersebut berdasarkan aturan keamanan Anda, dan wajibkan persetujuan dari manusia.

4. Periksa apa saja yang masuk ke rantai pasokan AI Anda

Hanya sedikit perusahaan yang membangun AI dari nol, dan jumlahnya makin sedikit setiap tahun. Menurut survei The State of Generative AI in the Enterprise 2025 dari Menlo Ventures, 53% perusahaan membeli model AI pada 2024, dan angkanya naik menjadi 76% pada 2025.

Umumnya, perusahaan mengunduh model dari hub seperti Hugging Face, melatihnya lebih lanjut dengan dataset yang dikumpulkan orang lain, lalu memasang add-on serta paket kode yang ditulis oleh orang yang tidak mereka kenal.

Setiap bagian tersebut adalah pintu masuk. Jika salah satunya dimanipulasi, masalahnya ikut terbawa di dalam produk Anda.

Contoh: Repositori model publik Hugging Face bertambah dari 2,43 juta menjadi 2,96 juta antara Januari 2026 dan Agustus 2026. Namun, pada Juli 2026, model OpenAI berhasil mengakali kontrol yang dimaksudkan untuk menjauhkan mereka dari internet selama pengujian keamanan internal dan membobol sebagian sistem Hugging Face. Bahkan, satu agen berhasil mendapatkan 14 kredensial akses yang terekspos secara publik, memastikan kredensial tersebut berfungsi, lalu membagikannya kepada agen lain. Agen-agen itu kemudian mengeksploitasi celah yang memungkinkan mereka menjalankan kode di server Hugging Face.

“Kami menerapkan persyaratan yang lebih ketat terkait penyelarasan (alignment) di sepanjang siklus hidup model dan membuat kotak pasir yang lebih terisolasi, membatasi akses internet, serta mengontrol akses ke bobot model secara lebih ketat,” demikian laporan OpenAI.

Yang dapat Anda lakukan:

• Kunci model ke versi tertentu dan verifikasi model tersebut: Kunci setiap model ke versi yang telah ditinjau dan periksa sidik jari file-nya sebelum memuatnya, sehingga file yang ditukar tidak bisa menyusup dengan label yang sama. OWASP juga merekomendasikan tanda tangan digital, dengan catatan—tanda tangan membuktikan asal model, bukan bahwa model itu aman.
• Periksa setiap paket yang disarankan AI Anda: Sebelum memasang paket kode yang direkomendasikan asisten AI, pastikan paket itu memang ada, bahwa itu adalah paket yang Anda maksud, dan bahwa paket tersebut berasal dari penerbit yang Anda harapkan.

5. Waspadai peracunan data dan model

AI yang teracuni belajar dari data yang rusak. Data ini bisa berupa contoh yang digunakan untuk fine-tuning, atau basis pengetahuan yang dicarinya untuk mendapatkan jawaban. Model tetap terlihat berfungsi; hanya saja model mempelajari hal yang salah, dan terkadang model belajar untuk berperilaku menyimpang hanya ketika melihat frasa pemicu tertentu.

Model akan lolos semua pengujian yang Anda lakukan sampai seseorang menggunakan frasa tersebut.

Perbesar

Selain itu, hal ini sangat sulit dipulihkan. Peracunan bukanlah bug yang bisa Anda tambal begitu saja. Jika data Anda salah, Anda mungkin perlu memeriksanya ulang, melatih ulang model, atau menggantinya sepenuhnya.

Contoh: Pada Oktober 2025, peneliti di Anthropic, UK AI Security Institute, dan Alan Turing Institute menunjukkan bahwa 250 dokumen yang diracuni dapat mengajari model untuk menghasilkan teks tak bermakna setiap kali menemukan pemicu tertentu. Jumlah yang sama berhasil pada keempat ukuran model yang diuji, meskipun model terbesar dilatih dengan data bersih lebih dari 20 kali lipat lebih banyak.

Yang dapat Anda lakukan:

• Lacak asal data Anda: Simpan catatan setiap dataset dan model yang Anda gunakan, asal masing-masing, dan apa yang berubah antarversi. Kami merekomendasikan kontrol versi untuk dataset sehingga jika ditemukan peracunan, Anda dapat kembali ke versi yang bersih dan menelusuri bagaimana peracunan itu bisa masuk.
• Uji keberadaan backdoor: “Backdoor” adalah perilaku tersembunyi yang ditanamkan penyerang dalam model, yang menunggu frasa tertentu atau pemicu lain untuk mengaktifkannya. Uji hal ini dengan input yang dirancang untuk membuat model melanggar aturan yang biasa diikutinya.

6. Kendalikan konsumsi tanpa batas

Ketika AI tidak memiliki batasan atas seberapa banyak pekerjaan yang dapat dilakukannya atau seberapa besar biaya yang dapat ditimbulkannya, konsumsinya dianggap “tanpa batas”. Sebagian besar layanan AI mengenakan biaya per penggunaan, sehingga penyerang dapat membengkakkan tagihan Anda atau membuat salinan model Anda.

OWASP menyebut masalah intinya sebagai “asimetri biaya”. Permintaan yang singkat dan murah dapat memicu komputasi yang mahal di pihak Anda.

Contoh: Pada Mei 2024, Threat Research Team Sysdig menemukan serangan baru yang disebut “LLMjacking”. Sekelompok penyerang menargetkan 10 layanan LLM yang di-hosting di cloud menggunakan kredensial curian. Mereka masuk melalui versi Laravel yang rentan, lalu mencari tahu apa saja yang bisa dilakukan dengan kredensial tersebut beserta kuotanya, dengan tujuan yang jelas untuk menjual akses. Banyak pengaturan logging juga dikueri, kemungkinan untuk menghindari deteksi. Menurut Sysdig, dalam skenario terburuk, korban bisa menanggung biaya lebih dari $46.000 per hari.

Yang dapat Anda lakukan:

• Tetapkan anggaran yang benar-benar menghentikan pengeluaran: Terapkan batas pengeluaran yang tegas untuk setiap pengguna, kunci API, tim, dan akun secara keseluruhan. Berlakukan batas tersebut di setiap titik masuk permintaan.
• Berikan titik henti untuk setiap tugas: Batasi berapa lama tugas dapat berjalan, berapa banyak teks yang dapat diproses dan dihasilkannya, serta berapa banyak panggilan alat yang dapat dilakukannya. Tambahkan penghentian otomatis untuk agen yang terus berulang atau melampaui jatahnya.

7. Deteksi misinformasi sebelum bertindak

Ketika AI menghasilkan sesuatu yang salah tetapi terdengar benar, lalu seseorang atau sesuatu bertindak berdasarkan hal tersebut, ini disebut misinformasi. Risiko utamanya bukan terletak pada jawaban yang salah itu sendiri, melainkan pada jawaban salah yang dipercaya dan digunakan.

Catatan insiden menunjukkan bahwa para praktisi tidak sekhawatir yang seharusnya terhadap misinformasi. Menurut surat pembuka edisi 2026, para pemilih menempatkannya di dekat posisi terbawah, tetapi berdasarkan insiden di dunia nyata, risiko ini berada di dekat posisi teratas.

Contoh: Pada 2025, Deloitte Australia menyerahkan tinjauan atas sistem TI kesejahteraan sosial berdasarkan kontrak pemerintah senilai A$440.000. Peneliti University of Sydney Chris Rudge menemukan rujukan ke penelitian yang tidak ada serta kutipan palsu dari putusan pengadilan federal. Laporan revisi mengungkapkan bahwa Deloitte telah menggunakan Azure OpenAI GPT-4o dalam metodologinya, dan perusahaan tersebut setuju untuk mengembalikan pembayaran termin terakhir. Sayangnya, laporan ini merupakan tinjauan penjaminan (assurance review).

Yang dapat Anda lakukan:

• Pastikan bukti mendukung jawaban: Dasarkan klaim pada sumber yang terkini dan otoritatif. Untuk jawaban terkait kebijakan, ambil kebijakan yang telah disetujui dan periksa apakah kebijakan tersebut mendukung kesimpulannya, termasuk pengecualiannya.
• Verifikasi sebelum sistem bertindak: Jika agen menyatakan bahwa pelanggan telah lolos pemeriksaan identitas, konfirmasikan hal itu dengan sistem verifikasi sebelum mencairkan pembayaran. Wajibkan persetujuan manusia untuk keputusan penting, dengan bukti pendukung yang tersedia bagi peninjau.

8. Batasi kerusakan akibat paparan konteks tersembunyi

Aplikasi AI memberikan instruksi dan informasi latar belakang kepada model yang biasanya tidak dilihat pengguna. Ini bisa mencakup prompt sistem, kebijakan internal, deskripsi alat yang tersedia, dan aturan tentang siapa yang boleh menggunakannya. Paparan konteks tersembunyi terjadi ketika model mengungkapkan informasi tersebut kepada seseorang.

OWASP memperluas entri ini dari “kebocoran prompt sistem” pada 2026 karena prompt sistem hanyalah sebagian dari apa yang bisa bocor. Tingkat bahayanya bergantung pada apa yang Anda masukkan di sana. Panduan gaya bahasa yang bocor memang sedikit memalukan, tetapi kunci API yang bocor memberi seseorang akses ke database rahasia Anda.

Contoh: Pada Februari 2023, pengguna berhasil membuat Bing Chat milik Microsoft mengungkapkan instruksi internalnya. Salah satu upaya yang berhasil dilakukan oleh Marvin von Hagen, yang mengaku sebagai developer OpenAI dan meminta instruksi tersebut agar ia dapat mengonfigurasi model. Bing mengungkapkan aturan yang mengatur pencarian, respons, dan perilaku keamanannya, beserta nama internalnya, Sydney. Di antara instruksi yang terungkap, ada satu instruksi yang memerintahkannya untuk merahasiakan instruksi-instruksi tersebut.

Yang dapat Anda lakukan:

• Jauhkan rahasia dari konteks model: Anggap bahwa apa pun yang dapat dibaca model bisa terlihat oleh pengguna—simpan kata sandi, kunci API, dan token akses di sistem manajemen rahasia yang terpisah.
• Pastikan izin tetap berlaku meskipun aturannya bocor: Terapkan pemeriksaan akses di kode aplikasi Anda. Jika suatu alat hanya boleh digunakan oleh administrator, periksa izin akun pengguna sebelum menjalankannya.

9. Amankan vektor dan embedding Anda

Saat AI menggunakan pencarian vektor untuk menemukan jawaban dalam dokumen perusahaan Anda, AI tidak mencari teksnya secara langsung. Dokumen-dokumen tersebut diubah menjadi “embedding”, yaitu daftar panjang berisi angka yang menangkap makna setiap bagian teks, lalu disimpan dalam basis data vektor. Pertanyaan juga diubah dengan cara yang sama, lalu sistem mengambil bagian teks yang angkanya paling dekat.

OWASP merangkum empat cara kegagalannya: peracunan (poisoning) membuat sistem keliru, inversi membuatnya membocorkan data, jamming membuatnya bungkam, dan kontrol akses yang rusak membuatnya menyerahkan apa saja kepada siapa saja.

Angka-angka itu tidak seaman kelihatannya. Embedding yang tersimpan dapat diubah kembali menjadi teks, dan salah satu metode berhasil memulihkan 92% bagian teks pendek sepanjang 32 token secara persis dalam pengujiannya. Jadi, cadangan “khusus embedding” yang bocor juga dapat mengungkap isi dokumen.

Contoh: Dalam penelitian yang dipresentasikan di USENIX Security 2025, para peneliti menunjukkan bahwa satu dokumen yang dirancang dengan cermat dapat mencegah AI menjawab pertanyaan tertentu. Mereka menambahkannya ke kumpulan dokumen yang ditelusuri AI. Ketika AI menemukannya, AI bisa menyatakan bahwa informasinya tidak cukup atau bahwa menjawab pertanyaan itu tidak aman. Dokumen tersebut tidak perlu menyuruh AI mengabaikan aturannya. Ini disebut “retrieval jamming”.

Yang dapat Anda lakukan:

• Pisahkan indeks untuk data publik dan data privat: Jangan mencampur konten web hasil scraping dengan data mitra atau dokumen internal rahasia. Lakukan pemisahan fisik berdasarkan tingkat kepercayaan, alih-alih memberi tag pada konten dalam satu indeks, karena cara ini menghilangkan seluruh jenis kesalahan konfigurasi, dan konten hasil scraping dari internet tidak akan bercampur dengan dokumen rapat direksi Anda.
• Perlakukan embedding seperti dokumen asalnya: Enkripsi embedding, lindungi cadangan basis data vektor serta file sumbernya, dan hapus embedding saat Anda menghapus dokumen aslinya. Kunci API untuk layanan embedding Anda harus dirahasiakan.

10. Periksa output AI sebelum meneruskannya

Setiap kali aplikasi meneruskan output AI ke sistem lain tanpa memverifikasi apakah output tersebut aman digunakan di sana, aplikasi itu menangani output LLM secara tidak tepat.

Entri ini juga mencakup kode tidak aman yang dihasilkan asisten coding AI dalam skala besar. Karena itu, setiap baris yang ditulis asisten juga merupakan output.

Contoh: Pada 2025, peneliti Johann Rehberger menunjukkan bagaimana asisten coding Amp milik Sourcegraph dapat membocorkan isi chat hanya dengan menampilkan sebuah gambar. Ia menggunakan prompt injection untuk membuat Amp menyertakan informasi pribadi dalam alamat web sebuah gambar. Aplikasi kemudian secara otomatis mengambil gambar itu sehingga informasi tersebut terkirim ke servernya. Kegagalan penanganan output-nya terletak pada permintaan otomatis tersebut—teks yang dihasilkan model berubah menjadi koneksi ke server luar sambil membawa data pribadi.

Yang dapat Anda lakukan:

• Pastikan output aman untuk tujuannya: Periksa dan tangani respons sesuai dengan ke mana respons itu akan dikirim. Untuk halaman web, cegah teks yang dihasilkan menjadi kode yang dapat dieksekusi. Untuk basis data, gunakan prepared query yang memisahkan nilai yang diberikan dari perintah.
• Cegah jawaban membuat koneksi keluar secara otomatis: Nonaktifkan pemuatan otomatis gambar, pratinjau tautan, dan halaman tersemat dalam respons model secara default. Batasi koneksi yang diperlukan hanya ke tujuan yang telah disetujui secara eksplisit.

Bagaimana Perplexity mengamankan LLM?

Kami berasumsi bahwa setiap risiko di atas pada akhirnya akan terjadi, dan kami merancang sistem agar dampaknya tidak besar saat itu terjadi. CISO kami, Kyle Polley, menjelaskan caranya dalam sebuah lokakarya baru-baru ini.

• Agen mendapatkan komputernya sendiri, dan komputer itu mulai dalam keadaan kosong: Alat agen yang terpasang di laptop Anda dapat mengakses file, aplikasi, dan kredensial yang tersimpan di laptop tersebut. Perplexity Computer bekerja sebaliknya. Setiap tugas berjalan di dalam kotak pasir tersendiri yang terisolasi, dan, seperti kata Polley, “secara default, agen tidak memiliki akses ke apa pun.”
• Agen tidak pernah melihat kata sandi: Kredensial untuk layanan yang terhubung disimpan di luar kotak pasir. Saat agen perlu mengakses layanan seperti GitHub, agen mengirimkan permintaan tanpa kredensial apa pun. Sebuah gateway memeriksa bahwa tujuan dan permintaannya sesuai dengan yang diharapkan, lalu menambahkan kredensial saat permintaan keluar. Agen dapat menggunakan koneksi tersebut tanpa pernah memegang kuncinya.
• Izin Anda tetap berlaku, dan Anda dapat memperketatnya: Koneksi yang dibuat melalui OAuth mempertahankan izin akses Anda di layanan yang terhubung. Jika Anda tidak dapat melihat sesuatu, agen Anda juga tidak dapat melihatnya.
• Setiap halaman web diperlakukan sebagai orang asing: Kami membuat BrowseSafe untuk Comet, browser agentik kami, karena alat-alat yang kami uji tidak memenuhi kebutuhan kami dalam penggunaan di dunia nyata. Browser ini memindai halaman web dan konten luar lainnya, termasuk email, untuk mendeteksi prompt injection. Kami merilis model dan dataset-nya sebagai open source.
• Kami memantau agen dan mesin tempatnya berjalan: Numbat berada di antara keputusan agen untuk bertindak dan alat yang benar-benar dijalankan. Numbat mencatat aktivitas di berbagai agen coding yang didukung dan dapat memblokir tindakan yang melanggar kebijakan yang dikonfigurasi sebelum tindakan itu dieksekusi. Bumblebee menginventarisasi paket perangkat lunak di laptop, server, dan pipeline build, serta menandai paket yang diketahui berbahaya. Keduanya bersifat open source.
• Penyedia model tidak menyimpan data Anda: Kami memiliki perjanjian tanpa retensi data (zero data retention) dengan penyedia LLM pihak ketiga kami. Admin Enterprise juga dapat mengatur retensi data milik Perplexity sendiri hingga sesingkat 24 jam.

Kami membangun Numbat secara proaktif, dengan alasan yang dirangkum Polley dalam satu kalimat: “Makin besar otonomi yang Anda berikan kepada agen, makin besar pula risikonya.”

FAQ keamanan LLM

LLM apa yang paling aman?

Tidak ada LLM yang dapat membuat aplikasi aman dengan sendirinya—model masih bisa salah mengira konten yang seharusnya dibaca sebagai instruksi yang harus diikuti. Pertahanan yang tampak kuat dalam pengujian standar juga bisa runtuh saat berada di bawah tekanan.

Pertanyaan yang lebih tepat adalah konfigurasi mana yang paling aman untuk kasus penggunaan Anda. Artinya, izin yang terbatas, kredensial yang dijauhkan dari model, persetujuan manusia untuk tindakan berisiko, dan pengujian oleh orang-orang yang memahami pertahanan Anda.

Apa itu kerentanan LLM?

Kerentanan LLM adalah kelemahan yang memungkinkan sistem AI dikelabui, membocorkan data, atau menimbulkan kerusakan, baik karena ulah penyerang maupun karena kesalahannya sendiri.

Sepuluh risiko utama tersebut adalah prompt injection, pengungkapan informasi sensitif, agensi berlebihan, rantai pasokan, peracunan data dan model, konsumsi tanpa batas, misinformasi, paparan konteks tersembunyi, kelemahan vektor dan embedding, serta penanganan output yang tidak tepat.

Apakah LLM privat aman?

Untuk beberapa hal, LLM privat merupakan pilihan yang lebih aman, tetapi tidak secara default. Anda memiliki kendali lebih besar atas penanganan data jika menjalankan model di infrastruktur Anda sendiri atau di lingkungan cloud. Namun, tidak ada cara otomatis untuk mencegah prompt injection, agensi berlebihan, peracunan, atau misinformasi.

Dengan melakukan self-hosting, Anda juga bertanggung jawab atas model yang Anda unduh, termasuk risiko rantai pasokan dan infrastruktur yang dibutuhkannya.