Havedev
AI Guardrails Tidak Selalu Membuat Cybersecurity Lebih Aman
The Core Update
Perusahaan AI besar sedang memperketat guardrails untuk mencegah model mereka dipakai dalam serangan siber. Secara niat, ini masuk akal. Model AI yang mampu membaca kode, menjelaskan kerentanan, membuat skrip, atau membantu eksploitasi memang punya risiko nyata jika jatuh ke tangan yang salah.
Tetapi situasinya tidak sesederhana itu.
Dalam laporan terbaru TechCrunch, beberapa peneliti keamanan ofensif menjelaskan bahwa guardrails yang terlalu ketat mulai menghambat pekerjaan sah mereka. Mereka bukan sedang mencari cara merusak sistem orang lain. Banyak dari mereka justru bekerja untuk menemukan celah, membuktikan dampaknya, lalu membantu organisasi memahami apa yang harus diperbaiki.
Masalahnya, di dunia cybersecurity, batas antara aktivitas ofensif dan defensif sering sangat tipis.
Prompt seperti “uji apakah bug ini bisa dieksploitasi” bisa dipakai penyerang untuk mencari jalan masuk. Tetapi prompt yang sama juga bisa dipakai defender untuk memastikan apakah bug tersebut benar-benar berbahaya dan perlu segera diprioritaskan.
Chris Anley dari NCC Group menggambarkannya seperti palu. Palu bisa dipakai membangun rumah. Palu juga bisa dipakai sebagai senjata. Masalahnya bukan hanya pada alat, tetapi pada konteks penggunaan, pengguna, dan tujuan akhirnya.
Di sisi lain, beberapa program akses khusus sudah dibuat oleh perusahaan AI. OpenAI memiliki Trusted Access for Cyber. Anthropic memiliki Cyber Verification Program. Program seperti ini mencoba memberi akses lebih longgar kepada pihak yang sudah diverifikasi.
Namun kritik tetap muncul. Proses vetting dianggap tidak selalu jelas. Keputusan tentang mana riset yang aman dan mana yang berbahaya terasa ditentukan oleh perusahaan besar, bukan oleh standar profesional cybersecurity yang lebih terbuka.
Akibatnya, sebagian peneliti mulai memakai model open source yang bisa dijalankan secara lokal. Bukan hanya karena guardrails lebih longgar, tetapi juga karena data riset kerentanan sering sangat sensitif. Mengirim detail zero-day atau exploit ke model cloud bisa menimbulkan risiko kebocoran, pencatatan, atau penggunaan ulang dalam training di masa depan.
Ini membuat paradoks baru: pembatasan yang dibuat untuk menjaga keamanan bisa mendorong peneliti serius keluar dari sistem AI yang lebih terkontrol.
The Reality Check
Kita perlu hati-hati membaca isu ini. Mudah sekali menyimpulkan bahwa guardrails buruk karena menghambat peneliti. Mudah juga menyimpulkan bahwa semua akses ofensif harus dibatasi karena berbahaya.
Dua-duanya terlalu sederhana.
AI untuk cybersecurity memang punya sifat ganda. Ia bisa membantu tim internal mempercepat audit kode, reverse engineering, triage vulnerability, membuat dokumentasi teknis, dan memahami pola serangan. Tetapi kemampuan yang sama juga bisa dipakai untuk phishing, exploit development, malware modification, atau automation serangan.
Karena itu, guardrails tidak bisa hanya dilihat sebagai fitur moral. Guardrails adalah desain operasional. Kalau terlalu longgar, risiko penyalahgunaan naik. Kalau terlalu ketat, orang baik kehilangan alat kerja. Kalau tidak konsisten, semua orang membuang waktu untuk menebak perilaku model.
Bagian paling penting dari berita ini bukan bahwa peneliti ingin AI tanpa batas. Banyak peneliti justru tetap membatasi penggunaan AI mereka sendiri. Ada yang hanya memakai AI untuk reverse engineering awal. Ada yang tidak mau memakai AI untuk bug discovery atau weaponization karena tidak ingin kehilangan kontrol atas proses teknisnya. Ada juga yang memilih model lokal karena tidak mau membocorkan data kerentanan ke layanan cloud.
Artinya, masalah utamanya bukan sekadar “AI boleh atau tidak boleh membantu exploit”.
Masalah yang lebih besar adalah trust boundary.
Siapa yang memakai model? Di lingkungan apa? Data apa yang dikirim? Apakah hasilnya diaudit? Apakah aktivitasnya tercatat? Apakah ada kontrak kerahasiaan? Apakah organisasi punya kebijakan disclosure? Apakah penggunaan AI masuk ke workflow security yang bisa dipertanggungjawabkan?
Tanpa pertanyaan seperti itu, guardrails hanya menjadi tombol kasar: boleh atau tolak.
Untuk pekerjaan teknis yang kompleks, tombol kasar sering menciptakan friksi yang tidak perlu. Peneliti akhirnya menghabiskan waktu menjelaskan ulang konteks ke model, mengganti kata, memecah prompt, atau pindah ke model lain. Waktu yang seharusnya dipakai menganalisis risiko berubah menjadi negosiasi dengan sistem.
Bagi bisnis biasa, isu ini juga relevan meskipun tidak sedang mengembangkan exploit atau mencari zero-day.
Banyak perusahaan mulai memakai AI untuk membantu pekerjaan keamanan dasar: membaca log, memeriksa konfigurasi, menulis policy, menjelaskan alert, membuat checklist hardening, atau membantu developer memahami bug. Jika guardrails terlalu sensitif, tim bisa mendapat jawaban dangkal saat butuh analisis teknis. Jika guardrails terlalu longgar, tim bisa tanpa sadar menghasilkan instruksi berisiko yang disalin ke lingkungan produksi.
Jadi pertanyaannya bukan apakah bisnis perlu AI yang bebas total.
Pertanyaannya: apakah bisnis punya batas penggunaan AI yang cukup jelas untuk membedakan pekerjaan defensif, data sensitif, dan aktivitas yang harus tetap ditangani manusia?
The Havedev Way
Dari sudut pandang Havedev, diskusi ini mengingatkan satu hal penting: keamanan digital tidak bisa hanya diserahkan ke tool, termasuk AI.
AI bisa membantu mempercepat analisis. AI bisa membantu membaca pola. AI bisa membantu tim kecil mengerjakan hal yang sebelumnya terlalu memakan waktu. Tetapi AI tetap harus masuk ke alur kerja yang punya batas, status, dan tanggung jawab yang jelas.
Untuk bisnis, langkah yang lebih sehat bukan langsung mencari model paling kuat atau guardrails paling longgar. Mulai dari peta penggunaan.
Tanyakan dulu:
- data apa yang boleh dikirim ke AI?
- data apa yang wajib tetap lokal?
- siapa yang boleh memakai AI untuk pekerjaan security?
- output AI mana yang harus dicek ulang sebelum dipakai?
- pekerjaan mana yang cukup dibantu AI?
- pekerjaan mana yang tetap harus diputuskan engineer atau security lead?
- bagaimana mencatat penggunaan AI saat menyangkut vulnerability, akses, atau konfigurasi sensitif?
Pertanyaan ini terdengar administratif, tetapi dampaknya teknis. Tanpa batas yang jelas, tim bisa terlalu takut memakai AI atau terlalu percaya pada AI. Dua-duanya berisiko.
Untuk pekerjaan cybersecurity, pendekatan yang lebih masuk akal adalah membagi AI berdasarkan tingkat sensitivitas.
Pekerjaan rendah risiko seperti merapikan dokumentasi, menjelaskan konsep, membuat checklist, atau membantu membaca error umum bisa memakai tool cloud dengan kontrol dasar. Pekerjaan yang menyentuh kode internal, konfigurasi produksi, log sensitif, atau detail kerentanan perlu aturan lebih ketat. Pekerjaan yang menyangkut zero-day, exploitability, kredensial, atau data pelanggan sebaiknya diproses dengan lingkungan yang lebih terkendali, termasuk opsi model lokal jika memang diperlukan.
Dengan cara ini, AI tidak diposisikan sebagai pengganti security judgment. AI menjadi asisten kerja yang ditempatkan sesuai risiko.
Hal yang sama berlaku untuk vendor AI. Jika perusahaan AI ingin membantu keamanan, mereka perlu bergerak dari guardrails kasar ke trust model yang lebih matang. Bukan semua orang diberi akses bebas. Tetapi juga bukan semua aktivitas teknis dianggap mencurigakan.
Akses berbasis verifikasi, logging yang jelas, mode enterprise dengan proteksi data, kebijakan non-training untuk data sensitif, dan jalur khusus untuk peneliti keamanan bisa lebih berguna daripada penolakan otomatis yang tidak konsisten.
Bisnis juga perlu realistis. Jika tim internal belum punya proses security yang rapi, AI tidak akan otomatis membuatnya aman. AI hanya akan mempercepat kebiasaan yang sudah ada. Kalau proses review lemah, AI bisa mempercepat kesalahan. Kalau data sensitif tersebar di chat dan dokumen tanpa kontrol, AI bisa menambah permukaan risiko. Kalau tidak ada pemilik keputusan, output AI hanya menjadi opini tambahan yang sulit dipertanggungjawabkan.
Jadi sebelum memakai AI untuk cybersecurity, rapikan dulu alur dasarnya.
Mulai dari aset penting. Lanjut ke akses. Lanjut ke backup. Lanjut ke monitoring. Lanjut ke incident response. Setelah itu, tentukan bagian mana yang bisa dipercepat AI tanpa membuka risiko baru.
AI guardrails memang perlu. Tetapi guardrails yang baik tidak hanya bertanya “apakah ini ofensif?”. Guardrails yang baik harus memahami konteks: siapa pengguna, apa tujuannya, data apa yang dipakai, dan bagaimana hasilnya akan digunakan.
Di sisi bisnis, aturan internal juga perlu punya prinsip yang sama. Jangan melarang semua penggunaan AI karena takut. Jangan membebaskan semua penggunaan AI karena ingin cepat. Buat batas yang bisa dipahami tim dan bisa diaudit saat terjadi masalah.
Keamanan bukan berarti semua pintu dikunci sampai tim tidak bisa bekerja. Keamanan berarti pintu yang tepat punya kunci yang tepat, akses yang tepat, dan catatan yang tepat.
Itu pelajaran penting dari debat AI guardrails di cybersecurity.
Tool yang terlalu bebas bisa berbahaya. Tool yang terlalu membatasi bisa membuat defender tertinggal. Yang dibutuhkan bukan hanya model yang lebih pintar, tetapi sistem kerja yang lebih jelas.
Dapatkan Audit Teknis Gratis untuk meninjau penggunaan AI, data sensitif, dan alur keamanan digital sebelum bisnis Anda menambah automation baru.
Sumber referensi berita: TechCrunch