AI Cybersecurity Tidak Cukup Aman Jika Hanya Mengandalkan Larangan

Anthropic merilis Fable, versi publik dan terbatas dari model cybersecurity mereka yang lebih kuat, Mythos. Di atas kertas, langkah ini masuk akal. Model AI yang mampu membantu pekerjaan keamanan tentu tidak bisa dilepas begitu saja tanpa batas.

Risikonya nyata. Model seperti ini bisa membantu audit kode, membaca celah, menyusun mitigasi, dan mempercepat pekerjaan defensif. Tetapi kemampuan yang sama juga bisa disalahgunakan untuk membuat malware, mengeksploitasi software, atau mempercepat serangan.

Karena itu, Anthropic memasang guardrails yang cukup ketat.

Masalahnya, sebagian peneliti keamanan merasa batasnya terlalu kasar. Beberapa keluhan menyebut Fable menolak permintaan yang hanya sedikit bersinggungan dengan cybersecurity. Bahkan tugas seperti membaca blog post, meminta code review, atau menulis secure code bisa dianggap terlalu berisiko.

Di sinilah diskusinya menjadi menarik. Bukan karena guardrails itu salah. Tetapi karena guardrails yang terlalu kabur bisa membuat tool keamanan justru sulit dipakai oleh orang yang sedang berusaha memperbaiki keamanan.

The Core Update

Anthropic memperkenalkan Fable sebagai akses publik yang lebih terbatas dari Mythos, model AI cybersecurity yang sebelumnya hanya diberikan ke organisasi tertentu melalui Project Glasswing.

Mythos diposisikan untuk membantu mengamankan software dan infrastruktur penting. Aksesnya diperluas ke ratusan organisasi di 15 negara, tetapi tetap berada dalam jalur yang lebih terkontrol.

Fable berbeda. Ia dibuat agar publik bisa memakai sebagian kemampuan tersebut, tetapi dengan guardrails yang lebih agresif.

Ketika sebuah prompt dianggap menyentuh area cybersecurity atau biology, Fable dapat menghentikan percakapan dan menyatakan bahwa pesan tersebut terdeteksi oleh safety measures. Dalam beberapa kasus, model akan turun ke Claude Opus 4.8 ketika guardrail aktif.

Secara niat, ini mudah dipahami. Anthropic ingin mengurangi kemungkinan model dipakai untuk tujuan berbahaya. Cybersecurity dan biologi sama-sama area sensitif karena pengetahuan teknis yang benar bisa menghasilkan dampak besar, baik untuk perlindungan maupun penyalahgunaan.

Namun dari sisi praktisi keamanan, implementasinya terasa terlalu luas.

Jika permintaan seperti “review kode ini agar lebih aman” langsung dianggap sebagai pekerjaan cybersecurity yang harus dibatasi, maka garis antara software engineering sehat dan aktivitas berbahaya menjadi terlalu buram.

Padahal banyak pekerjaan keamanan modern memang terjadi di area yang terlihat biasa:

• membaca kode
• memperbaiki validasi input
• menulis error handling yang lebih aman
• mengecek konfigurasi dependency
• meninjau autentikasi dan otorisasi
• menjelaskan risiko dari pola implementasi tertentu

Jika semua itu terlalu mudah masuk kategori berbahaya, AI tidak lagi menjadi asisten keamanan. Ia menjadi asisten yang harus dihindari setiap kali pembahasan mulai serius.

The Reality Check

Kita perlu adil melihat dua sisi.

Di satu sisi, perusahaan AI memang tidak bisa bersikap terlalu longgar. Jika model cybersecurity dilepas tanpa kontrol, dampaknya bukan hanya reputasi perusahaan. Ada risiko nyata terhadap software publik, infrastruktur, organisasi kecil, dan pengguna biasa.

Di sisi lain, keamanan software tidak bisa maju jika semua pembahasan teknis dianggap mencurigakan.

Ini masalah lama dalam bentuk baru: bagaimana membedakan niat defensif dari niat ofensif?

Jawabannya tidak mudah. Prompt yang sama bisa dipakai dalam dua konteks berbeda. Permintaan untuk menjelaskan vulnerability bisa menjadi bahan edukasi, tetapi juga bisa menjadi langkah awal eksploitasi. Permintaan untuk membaca kode bisa menjadi audit internal, tetapi juga bisa dipakai untuk mencari celah.

Karena sulit, pendekatan awal biasanya konservatif. Lebih baik terlalu banyak menolak daripada terlalu banyak meloloskan. Secara risk management, itu masuk akal.

Tetapi secara product experience, pendekatan ini cepat terasa rusak.

Masalahnya bukan hanya penolakan. Masalahnya adalah penolakan yang tidak cukup kontekstual.

Jika guardrails bekerja seperti daftar kata kunci, maka kata seperti “security”, “vulnerability”, “exploit”, atau “secure code” bisa memicu alarm tanpa membaca tujuan sebenarnya. Akibatnya, pekerjaan defensif yang sah ikut terkena batas.

Ini mirip dengan bisnis yang memakai status kerja terlalu kasar. Semua hal diberi label “pending”, padahal ada pending karena menunggu pelanggan, pending karena menunggu tim internal, dan pending karena belum dikerjakan. Labelnya terlihat aman, tetapi tidak membantu tindakan berikutnya.

Guardrails AI juga begitu. Label “cybersecurity” terlalu besar jika tidak dibagi lagi.

Ada perbedaan besar antara:

• menulis malware baru
• mengeksploitasi target nyata
• membuat langkah bypass autentikasi
• mengaudit kode milik sendiri
• menjelaskan konsep keamanan tingkat tinggi
• memperbaiki input validation
• membuat checklist hardening server

Jika semuanya diperlakukan sebagai satu risiko yang sama, pengguna serius akan kesulitan. Mereka tidak hanya kehilangan fitur. Mereka kehilangan kepercayaan pada sistem.

Untuk cybersecurity, ini penting. Praktisi keamanan sudah terbiasa bekerja dengan konteks, bukti, dan batas izin. Mereka tahu perbedaan antara authorized testing dan penyalahgunaan. Jika AI tidak bisa membaca perbedaan itu, AI akan terasa seperti tool yang kuat tetapi tidak memahami cara kerja profesinya.

Program seperti Cyber Verification Program dari Anthropic atau Trusted Access for Cyber dari OpenAI mencoba menjawab masalah ini. Praktisi yang diverifikasi bisa mendapatkan batas yang lebih longgar.

Itu langkah yang masuk akal, tetapi belum menyelesaikan seluruh masalah.

Karena pekerjaan keamanan tidak hanya dilakukan oleh tim red team besar atau perusahaan cybersecurity. Banyak developer biasa juga perlu bantuan untuk menulis kode yang lebih aman. Banyak founder teknis perlu mengecek risiko dasar. Banyak tim kecil tidak punya security engineer khusus, tetapi tetap harus menjaga aplikasi mereka.

Jika akses keamanan yang berguna hanya tersedia untuk kelompok terverifikasi, maka banyak tim kecil tetap berada di area abu-abu: terlalu teknis untuk dibantu AI umum, tetapi terlalu kecil untuk masuk program khusus.

The Havedev Way

Dari sudut pandang Havedev, pelajaran dari Fable bukan bahwa guardrails itu buruk. Guardrails tetap perlu. Tetapi guardrails yang baik harus membantu pekerjaan yang benar, bukan hanya memblokir pekerjaan yang berisiko.

Untuk AI di area cybersecurity, pertanyaannya bukan sekadar “boleh atau tidak boleh”.

Pertanyaannya lebih spesifik:

• konteks pekerjaannya apa?
• aset yang dianalisis milik siapa?
• apakah ada izin yang jelas?
• output yang diminta bersifat edukatif, defensif, atau operasional ofensif?
• apakah respons bisa diarahkan ke mitigasi tanpa memberi langkah penyalahgunaan?
• apakah pengguna meminta eksploitasi target nyata atau perbaikan sistem sendiri?

Dengan pertanyaan seperti ini, guardrails bisa menjadi lebih berguna. Bukan longgar tanpa arah, tetapi lebih presisi.

Dalam praktik software engineering, banyak pekerjaan keamanan seharusnya tetap bisa dibantu AI dengan aman. Misalnya:

• meninjau apakah form rentan terhadap input yang tidak tervalidasi
• menjelaskan risiko menyimpan token di local storage
• membantu membuat checklist permission untuk admin panel
• memperbaiki error message agar tidak membocorkan detail sistem
• menyusun rekomendasi rate limiting untuk endpoint publik
• membantu developer memahami dependency yang sudah usang

Ini bukan pekerjaan yang seharusnya otomatis dianggap berbahaya. Justru ini pekerjaan defensif yang membantu banyak bisnis menjadi lebih aman.

Yang perlu dibatasi lebih ketat adalah permintaan yang mengarah pada penyalahgunaan langsung: instruksi eksploitasi terhadap target nyata, pembuatan malware, pencurian kredensial, bypass sistem, atau otomasi serangan.

Perbedaannya memang tidak selalu mudah, tetapi harus diusahakan. Kalau tidak, AI cybersecurity akan terjebak di dua ekstrem: terlalu bebas untuk aman, atau terlalu terkunci untuk berguna.

Bagi bisnis, ada pelajaran praktis di sini.

Jangan menganggap AI otomatis membuat proses keamanan menjadi matang. AI bisa mempercepat audit, dokumentasi, review kode, dan checklist. Tetapi bisnis tetap perlu punya batas kerja yang jelas:

• repository mana yang boleh dianalisis
• data apa yang tidak boleh dikirim ke AI
• jenis temuan apa yang perlu divalidasi manual
• siapa yang bertanggung jawab memperbaiki issue
• kapan hasil AI dianggap cukup untuk tindakan awal
• kapan harus melibatkan security professional

Tanpa aturan internal seperti ini, penggunaan AI untuk keamanan bisa menjadi kacau. Tim mungkin terlalu percaya pada jawaban AI, atau sebaliknya tidak bisa memakainya karena takut melanggar batas.

Pendekatan yang sehat adalah mulai dari pekerjaan defensif yang jelas.

Misalnya, gunakan AI untuk membantu membaca kode sendiri, membuat checklist secure coding, merapikan dokumentasi risiko, atau menjelaskan konsekuensi dari konfigurasi tertentu. Jangan mulai dari skenario eksploitasi yang tidak jelas izinnya.

Untuk perusahaan AI, tantangannya adalah membuat guardrails yang lebih memahami konteks. Untuk bisnis, tantangannya adalah membuat kebijakan penggunaan AI yang cukup jelas agar tim tahu batas aman.

Keduanya perlu bertemu di tengah.

AI cybersecurity tidak akan berguna jika terlalu mudah disalahgunakan. Tetapi AI cybersecurity juga tidak akan membantu banyak orang jika terlalu mudah menolak pekerjaan keamanan yang sah.

Fable menunjukkan bahwa industri masih mencari bentuk yang tepat. Ini fase awal, dan wajar jika guardrails masih kasar. Namun arah perbaikannya seharusnya jelas: dari sekadar memblokir kata, menuju memahami konteks kerja.

Karena keamanan bukan hanya soal menutup akses. Keamanan juga soal membantu orang yang benar melakukan pekerjaan yang benar dengan cara yang lebih rapi.

Untuk bisnis yang sedang memakai AI dalam pengembangan software, pertanyaan pentingnya bukan hanya “AI apa yang paling kuat?” tetapi juga “apakah proses kita cukup jelas untuk memakai AI dengan aman?”

Kalau jawabannya belum jelas, mulai dari sana.

Dapatkan Audit Teknis Gratis untuk meninjau alur pengembangan, keamanan aplikasi, dan peluang automation yang bisa dibantu AI tanpa mengorbankan kontrol teknis.

---

Sumber referensi berita: TechCrunch