Seorang developer meminta AI coding assistant membantu menemukan penyebab kegagalan pada fungsi pembayaran. Agar analisisnya lebih akurat, ia menyertakan potongan kode, stack trace, respons API, struktur tabel, dan konfigurasi aplikasi.

Masalah berhasil ditemukan dalam beberapa menit. Namun, materi yang digunakan untuk memperoleh jawaban tersebut ternyata memuat alamat endpoint internal, pola autentikasi, identitas pelanggan, serta sebagian token yang muncul dalam log.

Situasi ini memperlihatkan paradoks penggunaan AI dalam software development. Semakin lengkap konteks yang diberikan, semakin besar peluang AI menghasilkan jawaban yang relevan. Pada saat yang sama, semakin banyak pula informasi perusahaan yang ikut diproses.

Keamanan AI coding assistant karena itu tidak cukup dibahas sebagai persoalan source code. Risiko juga dapat berada dalam berbagai konteks development yang selama ini dianggap sebagai informasi teknis biasa.

Source Code Hanya Bagian yang Paling Mudah Terlihat

Ketika perusahaan membicarakan risiko AI coding assistant, kekhawatiran pertama biasanya tertuju pada kebocoran source code. Kekhawatiran tersebut beralasan karena kode dapat mengandung kekayaan intelektual, aturan bisnis, dan detail implementasi sistem.

Namun, source code bukan satu-satunya informasi sensitif di lingkungan development.

AI coding assistant dapat menerima konteks dari prompt yang ditulis pengguna, file yang sedang dibuka, potongan repository, dokumentasi, histori percakapan, dan hasil perintah yang dijalankan. Cakupan tersebut bergantung pada produk, konfigurasi, mode penggunaan, dan izin yang diberikan.

Konteks development dapat mencakup:

• komentar dalam kode;
• file konfigurasi;
• struktur database;
• dokumentasi arsitektur;
• contoh payload API;
• stack trace;
• terminal output;
• alamat server internal;
• tiket pengembangan;
• histori commit;
• aturan bisnis;
• data pelanggan;
• nama proyek yang belum diumumkan;
• informasi mengenai kelemahan sistem.

Masing-masing informasi mungkin terlihat tidak berbahaya ketika berdiri sendiri. Namun, gabungan beberapa bagian dapat memberikan gambaran yang cukup lengkap mengenai struktur, fungsi, dan kelemahan aplikasi perusahaan.

Informasi Teknis Tidak Selalu Berarti Informasi Publik

Developer terbiasa membagikan error message, log, dan contoh respons API untuk mempercepat proses investigasi. Kebiasaan tersebut sebelumnya mungkin hanya berlangsung di antara anggota tim atau melalui sistem internal perusahaan.

Kehadiran generative AI mengubah jalur pemrosesan informasi tersebut.

Data yang dimasukkan ke dalam prompt dapat diproses oleh layanan yang berada di luar lingkungan perusahaan. Ketentuan pemrosesannya dapat berbeda berdasarkan jenis akun, paket layanan, pengaturan administrator, model yang digunakan, dan kebijakan penyedia.

Informasi teknis yang perlu diperlakukan secara hati-hati antara lain:

• API key dan access token;
• password dan connection string;
• private key;
• session cookie;
• alamat IP internal;
• nama server;
• konfigurasi keamanan;
• struktur role dan permission;
• skema database;
• pola enkripsi;
• mekanisme autentikasi;
• informasi kerentanan yang belum diperbaiki.

Bahkan tanpa kredensial aktif, informasi tersebut dapat membantu pihak lain memahami attack surface perusahaan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Informasi yang dianggap sekadar data debugging ternyata dapat memperlihatkan endpoint tersembunyi, format token, struktur direktori, nama layanan, hingga alur yang dapat dimanipulasi.

Konteks Membuat AI Berguna Sekaligus Memperluas Risiko

AI coding assistant membutuhkan konteks agar dapat memberikan jawaban yang sesuai dengan proyek. Tanpa konteks, saran yang diberikan cenderung umum dan mungkin tidak mengikuti pola kode perusahaan.

Ketika memiliki konteks yang memadai, AI dapat memahami hubungan antarmodul, mengikuti gaya penulisan kode, mencari penyebab kesalahan, serta mengusulkan perubahan lintas file.

Inilah alasan mengapa persoalannya tidak dapat diselesaikan hanya dengan instruksi “jangan mengirimkan source code”.

Developer perlu mengetahui konteks apa yang dikumpulkan oleh alat, kapan konteks tersebut dikirim, dan fitur mana yang dapat memperluas aksesnya. Perusahaan juga perlu memahami apakah file terbuka, repository, dokumentasi, atau hasil perintah terminal ikut digunakan untuk menghasilkan respons.

Dokumentasi resmi beberapa penyedia AI coding assistant bahkan menyarankan pengguna untuk membuka file yang relevan dan menutup file yang tidak diperlukan. Hal ini menunjukkan bahwa pengelolaan konteks merupakan bagian penting dari penggunaan alat tersebut.

Pertanyaan utamanya bukan apakah AI membutuhkan konteks. Pertanyaannya adalah siapa yang menentukan batasnya dan bagaimana batas tersebut diverifikasi.

Data Sensitif Tidak Selalu Berbentuk Password

Kredensial merupakan jenis informasi yang paling mudah dikenali sebagai rahasia. Namun, data development memiliki tingkat sensitivitas yang lebih luas.

Informasi tersebut dapat dibagi menjadi beberapa kategori.

Pertama, data akses seperti password, token, private key, API key, dan connection string. Informasi ini dapat digunakan secara langsung untuk mengakses sistem apabila masih aktif.

Kedua, informasi teknis internal seperti topologi jaringan, alamat server, konfigurasi keamanan, skema database, dan mekanisme autentikasi. Informasi tersebut dapat membantu pemetaan sistem.

Ketiga, data pribadi dan operasional seperti nama pelanggan, alamat surel, nomor identitas, data pegawai, catatan transaksi, dan informasi kesehatan.

Keempat, kekayaan intelektual seperti algoritma internal, source code privat, model perhitungan, strategi produk, dokumentasi teknis, serta fitur yang belum dirilis.

Kelima, informasi keamanan seperti temuan penetration testing, bukti eksploitasi, kelemahan yang belum diperbaiki, dan konfigurasi kontrol pertahanan.

Klasifikasi ini penting karena tidak semua data memerlukan perlakuan yang sama. Kode pada repository publik tentu memiliki risiko berbeda dibandingkan konfigurasi production atau data pelanggan.

Tidak Semua AI Coding Assistant Memproses Data dengan Cara yang Sama

Pembahasan mengenai privasi AI coding assistant sering terjebak pada dua kesimpulan ekstrem. Sebagian pihak menganggap semua data yang diberikan kepada AI pasti digunakan untuk melatih model. Sebagian lainnya menganggap layanan perusahaan otomatis menghilangkan seluruh risiko.

Keduanya tidak selalu tepat.

Setiap produk dapat memiliki ketentuan yang berbeda mengenai:

• penyimpanan prompt dan respons;
• penggunaan data untuk pelatihan;
• lokasi pemrosesan;
• data residency;
• isolasi antar organisasi;
• masa retensi;
• sub processor;
• penghapusan data;
• pencatatan aktivitas;
• kontrol administrator.

Ketentuan juga dapat berbeda antara akun pribadi dan paket perusahaan. Fitur yang tersedia pada satu mode belum tentu berlaku pada mode lain.

Karena itu, perusahaan perlu mengevaluasi produk dan paket yang benar-benar digunakan. Penilaian tidak dapat hanya mengandalkan reputasi penyedia atau klaim pemasaran secara umum.

Risiko harus dinilai berdasarkan jenis data yang dikirim, konfigurasi layanan, kontrak pemrosesan, lokasi data, dan kemampuan akses yang dimiliki alat.

Akun Pribadi Dapat Menciptakan Shadow AI

Penggunaan AI coding assistant sering dimulai dari inisiatif individu. Developer mencoba sebuah alat karena dapat membantu menyelesaikan pekerjaan lebih cepat, sementara perusahaan belum memiliki kebijakan atau layanan resmi.

Kondisi ini dapat melahirkan shadow AI, yaitu penggunaan layanan kecerdasan buatan tanpa persetujuan, pengawasan, atau visibilitas organisasi.

Beberapa faktor yang mendorongnya antara lain:

• proses persetujuan alat terlalu lama;
• perusahaan hanya menerapkan larangan;
• tidak tersedia alternatif resmi;
• target development sangat ketat;
• akun pribadi lebih mudah digunakan;
• tim belum memahami klasifikasi data;
• kebijakan penggunaan AI tidak jelas.

Ketika akun pribadi digunakan untuk pekerjaan perusahaan, administrator tidak dapat memastikan konfigurasi keamanan yang diterapkan. Perusahaan mungkin tidak memiliki audit log, kontrol retensi, mekanisme pencabutan akses, atau perjanjian perlindungan data yang memadai.

Masalahnya tidak berhenti ketika developer berhenti menggunakan alat. Histori percakapan, prompt, dan konteks yang pernah diberikan dapat tetap berada di dalam akun pribadi sesuai ketentuan layanan yang berlaku.

Kebijakan yang hanya berisi larangan sering tidak cukup. Perusahaan perlu menyediakan alat yang disetujui, batas penggunaan yang jelas, serta proses pengecualian yang realistis.

Content Exclusion Membantu, tetapi Perlu Diuji

Beberapa AI coding assistant menyediakan fitur untuk mengecualikan file atau folder tertentu. Fitur ini dapat membantu mencegah alat menggunakan materi sensitif sebagai konteks.

Perusahaan dapat mempertimbangkan pengecualian terhadap:

• file rahasia;
• konfigurasi production;
• private key;
• data pelanggan;
• dokumentasi arsitektur sensitif;
• laporan kerentanan;
• kode kriptografi internal;
• file hasil ekspor;
• materi legal dan komersial.

Namun, content exclusion tidak boleh langsung dianggap sebagai batas yang mutlak. Dukungan terhadap fitur tersebut dapat berbeda menurut editor, integrasi, dan mode penggunaan.

Dokumentasi resmi GitHub, misalnya, mencatat adanya keterbatasan content exclusion pada mode tertentu. Artinya, perusahaan perlu menguji apakah kebijakan benar-benar berlaku pada seluruh cara kerja yang digunakan tim.

Konfigurasi yang terlihat aktif pada halaman administrator belum tentu memberikan hasil yang sama ketika pengguna berpindah dari fitur chat biasa ke Edit Mode atau Agent Mode.

Agent Mode Mengubah Risiko dari Membaca Menjadi Bertindak

AI coding assistant pada awalnya banyak digunakan untuk memberikan saran kode. Perkembangannya kini mengarah pada agent yang dapat merencanakan pekerjaan dan menjalankan tindakan secara lebih mandiri.

Bergantung pada produk serta izin yang diberikan, agent dapat:

• membaca banyak file;
• mengubah kode;
• membuat file baru;
• menjalankan perintah terminal;
• memasang dependensi;
• mengakses dokumentasi;
• memanggil tool eksternal;
• membuka koneksi jaringan;
• membuat commit;
• menyiapkan pull request.

Perubahan kemampuan tersebut turut mengubah model risikonya.

Ketika alat hanya memberikan saran, developer masih menjadi pihak yang menjalankan tindakan. Ketika agent diberi akses ke terminal, filesystem, repository, dan jaringan, kesalahan instruksi dapat menghasilkan dampak yang lebih luas.

Karena itu, agent mode perlu mengikuti prinsip least privilege. Agent hanya boleh memperoleh akses yang benar-benar diperlukan untuk menyelesaikan tugas.

Akses ke production, secret, repository lain, dan jaringan internal sebaiknya tidak tersedia secara default. Tindakan sensitif juga perlu membutuhkan persetujuan manusia dan dicatat agar dapat diaudit.

Repository Dapat Membawa Instruksi Berbahaya

Prompt injection tidak selalu berasal dari prompt yang ditulis langsung oleh pengguna. Instruksi berbahaya dapat ditempatkan pada materi yang dibaca oleh AI sebagai konteks.

Materi tersebut dapat berupa:

• dokumentasi repository;
• komentar kode;
• issue;
• file hasil unduhan;
• dependency;
• halaman web;
• output tool;
• data dari sistem eksternal.

Ketika AI agent membaca informasi tersebut, instruksi tersembunyi dapat mencoba mengubah perilakunya. Risikonya meningkat apabila agent memiliki akses ke secret, terminal, filesystem, atau jaringan.

OWASP menempatkan prompt injection dan sensitive information disclosure sebagai risiko penting pada aplikasi berbasis Large Language Model. NIST AI Risk Management Framework juga mendorong organisasi untuk memetakan data, konteks penggunaan, pihak terkait, dan dampak AI sebelum menentukan kontrol.

Dalam konteks software development, input dari repository atau tool tidak selalu dapat dipercaya hanya karena berbentuk dokumentasi teknis. Konten tersebut tetap perlu dianggap sebagai data yang dapat memengaruhi perilaku agent.

Enterprise Plan Bukan Jaminan Tanpa Batas

Paket perusahaan dapat memberikan kontrol yang lebih baik dibandingkan penggunaan akun pribadi. Fitur seperti Single Sign-On, pengaturan administrator, audit log, isolasi organisasi, dan ketentuan pemrosesan data dapat membantu mengurangi risiko.

Namun, enterprise plan tidak menghilangkan tanggung jawab perusahaan untuk mengelola konteks.

Developer tetap dapat menyalin data pelanggan ke dalam prompt. Log yang mengandung token tetap dapat dimasukkan saat debugging. Agent juga dapat memperoleh akses terlalu luas apabila konfigurasi izinnya tidak ditinjau.

Sebelum menggunakan layanan AI untuk development, perusahaan perlu memeriksa:

• kebijakan penggunaan data untuk pelatihan;
• masa retensi prompt dan respons;
• mekanisme penghapusan data;
• lokasi pemrosesan;
• data residency;
• isolasi antar pelanggan;
• sub processor yang digunakan;
• dukungan content exclusion;
• pengelolaan identitas;
• ketersediaan audit log;
• pembatasan agent dan tool;
• proses penanganan insiden.

Paket perusahaan merupakan salah satu lapisan kontrol. Keamanan tetap bergantung pada konfigurasi, kebijakan, perilaku pengguna, dan pengawasan yang diterapkan.

Kebijakan Harus Mengatur Data dan Aktivitas

Sebagian perusahaan membuat kebijakan AI dengan mencantumkan daftar alat yang boleh dan tidak boleh digunakan. Daftar tersebut berguna, tetapi belum cukup operasional.

Kebijakan juga perlu menjelaskan data yang boleh diproses dan aktivitas yang dapat dilakukan.

Sebagai contoh, repository publik dapat digunakan sesuai ketentuan umum. Dokumentasi internal hanya boleh digunakan melalui akun perusahaan. Source code rahasia memerlukan pembatasan tambahan. Sementara itu, secret, data pelanggan, dan kredensial production tidak boleh dimasukkan ke dalam layanan AI umum.

Perusahaan juga perlu menentukan:

• repository yang dapat diakses;
• mode AI yang diperbolehkan;
• tool yang dapat dipanggil;
• akses jaringan yang tersedia;
• tindakan yang membutuhkan persetujuan;
• proses pemeriksaan kode;
• mekanisme pelaporan kesalahan;
• cara meminta pengecualian;
• tanggung jawab pengguna dan administrator.

Dengan ketentuan yang jelas, developer tidak harus menebak apakah suatu penggunaan diperbolehkan.

Secure SDLC Perlu Memasukkan AI sebagai Komponen Baru

AI coding assistant telah menjadi bagian dari lingkungan development. Karena itu, penggunaannya perlu dimasukkan ke dalam Secure Software Development Life Cycle.

Threat model perlu memetakan aliran data dari editor atau repository menuju layanan AI. Security requirement harus menentukan konteks yang dapat digunakan. Vendor assessment perlu memeriksa kebijakan pemrosesan data dan kontrol keamanan penyedia.

Proses code review juga tetap diperlukan untuk memeriksa kode yang dihasilkan AI. Saran AI dapat mengandung kesalahan logika, penggunaan library yang tidak tepat, kontrol akses yang lemah, atau implementasi keamanan yang tidak sesuai kebutuhan aplikasi.

Secure SDLC yang telah diperbarui dapat mencakup:

• klasifikasi repository;
• pemetaan aliran data menuju layanan AI;
• evaluasi vendor;
• pembatasan akses agent;
• secret scanning;
• review terhadap kode yang dihasilkan;
• pengujian keamanan;
• pencatatan aktivitas;
• prosedur respons insiden;
• pencabutan akses ketika pegawai keluar.

AI tidak seharusnya diperlakukan sebagai alat produktivitas yang berada di luar tata kelola development. Alat tersebut telah menjadi komponen baru yang memproses konteks dan, pada beberapa mode, menjalankan tindakan.

Kontrol Teknis Perlu Mendukung Perilaku Pengguna

Pelatihan developer tetap diperlukan, tetapi perusahaan tidak dapat hanya mengandalkan kehati-hatian individu.

Developer dapat melakukan kesalahan ketika bekerja di bawah tekanan. Token dapat tidak sengaja masuk ke dalam log. File sensitif dapat terbuka ketika AI mengumpulkan konteks. Prompt juga dapat menyertakan data yang tampak tidak berbahaya.

Kontrol teknis yang dapat dipertimbangkan meliputi:

• secret scanning pada repository;
• pemeriksaan secret sebelum commit;
• Data Loss Prevention;
• content exclusion;
• pembatasan repository;
• sandbox untuk agent;
• pembatasan jaringan;
• akun perusahaan dengan SSO;
• pemisahan credential development dan production;
• audit log;
• proses persetujuan tindakan sensitif.

Log dan contoh payload sebaiknya dibersihkan sebelum digunakan untuk debugging dengan AI. Identitas pelanggan dapat diganti dengan data sintetis. Credential perlu disamarkan atau dihapus sepenuhnya.

Tujuannya bukan membuat developer takut menggunakan AI, tetapi membangun batas yang tetap bekerja ketika manusia melakukan kesalahan.

Produktivitas AI Perlu Diukur Bersama Risikonya

Keberhasilan AI coding assistant biasanya dinilai melalui kecepatan penyelesaian tugas, jumlah saran yang diterima, atau peningkatan output developer.

Perusahaan juga perlu mengukur aspek keamanan, seperti:

• jumlah alat AI yang digunakan;
• persentase penggunaan melalui akun resmi;
• repository yang dapat diakses AI;
• percobaan memasukkan secret;
• penggunaan akun pribadi;
• agent dengan akses terminal;
• pelanggaran kebijakan data;
• temuan keamanan pada kode hasil AI;
• waktu pencabutan akses;
• insiden yang melibatkan prompt atau konteks.

Metrik tersebut membantu perusahaan melihat apakah peningkatan produktivitas diperoleh dengan risiko yang masih dapat diterima.

Tanpa visibilitas, perusahaan mungkin hanya melihat pekerjaan selesai lebih cepat. Sementara itu, data development berpindah melalui jalur yang tidak pernah masuk dalam penilaian risiko.

AI Tidak Harus Mengetahui Semuanya untuk Membantu Developer

AI coding assistant dapat membantu memahami kode, mempercepat debugging, membuat dokumentasi, serta mengurangi pekerjaan berulang. Manfaat tersebut tidak harus dicapai dengan memberikan akses tanpa batas.

Perusahaan perlu memahami konteks yang digunakan, data yang diproses, kebijakan penyedia, serta tindakan yang dapat dilakukan oleh setiap mode AI.

Source code mungkin menjadi aset yang paling mudah terlihat. Namun, risiko juga dapat bersembunyi dalam log, konfigurasi, dokumentasi, terminal output, dan contoh data yang dianggap biasa.

AI dapat membantu developer tanpa harus mengetahui semua hal yang diketahui perusahaan. Batas tersebut perlu dirancang, diterapkan, dan diuji sebelum informasi sensitif terlanjur berpindah.

Perkuat Keamanan Development Bersama Fourtrezz

Fourtrezz dapat membantu perusahaan mengevaluasi keamanan aplikasi, API, dan infrastruktur melalui layanan Penetration Testing dan Vulnerability Assessment. Pengujian dapat disesuaikan dengan karakteristik sistem, teknologi yang digunakan, integrasi, role pengguna, dan risiko perusahaan.

Fourtrezz juga menyediakan layanan IT Development untuk membantu perusahaan mengembangkan sistem dengan mempertimbangkan kebutuhan bisnis serta aspek keamanan sejak proses perancangan.

Kolaborasi dengan Fourtrezz dapat membantu organisasi memperoleh perspektif independen terhadap risiko yang mungkin tidak terlihat dalam pengujian fungsional maupun proses development sehari-hari.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]