AI coding agent yang terlalu bebas itu mirip intern super cepat yang dikasih akses ke seluruh lemari kantor. Dia bisa bantu banyak hal, tapi dia juga bisa kebaca dokumen yang sebenarnya nggak relevan buat kerjaannya.

Artikel ini membahas kenapa developer perlu batas file saat memakai AI coding agent seperti Codex, Claude Code, Cursor, atau tool sejenis. Intinya sederhana: prompt yang bagus tetap kalah kalau permission repo terlalu longgar. Lu perlu desain akses yang eksplisit, karena file sensitif bukan cuma .env, dan .gitignore bukan security boundary.

Apa masalahnya dengan AI coding agent yang bisa baca semua file?

AI coding agent makin berguna karena dia bisa membaca repo, menjalankan command, mencari referensi, lalu mengubah file. Tapi kemampuan yang sama juga bikin surface area-nya melebar. Ketika agent bisa menjalankan pencarian seperti rg, membuka file, atau memasukkan hasil tool ke konteks model, file yang tadinya “cuma ada di lokal” bisa ikut kebawa ke workflow AI.

Ini bukan berarti semua AI tool otomatis membocorkan data. Framing yang lebih sehat: kalau sebuah tool punya akses baca ke file, anggap file itu masuk area yang mungkin diproses. Kalau file itu nggak perlu diproses, jangan kasih akses dari awal.

Diskusi soal ini muncul lagi dari issue OpenAI Codex tentang kebutuhan cara mengecualikan file sensitif. Di Hacker News, salah satu komentar yang cukup ngena: kalau lu menjalankan agent sebagai user yang bisa membaca file tersebut, agent secara praktis juga bisa membaca file itu. Solusi sementara yang disebut komunitas pun bukan mantra prompt, tapi boundary sistem: permission file, container, atau environment terpisah.

.gitignore itu bukan pagar keamanan

Banyak developer refleks mikir, “tenang, file ini udah masuk .gitignore.” Masalahnya, .gitignore cuma bilang ke Git file mana yang tidak perlu dilacak. Dia tidak otomatis mencegah proses lokal membaca file tersebut.

GitHub Docs menjelaskan ignore file sebagai mekanisme untuk mencegah file tertentu ikut masuk staging atau commit. Itu berguna banget buat menghindari file build, log, dependency lokal, atau konfigurasi pribadi masuk repo. Tapi dari sisi akses runtime, file itu tetap ada di disk. Program lokal, script test, extension editor, atau AI agent yang berjalan dengan user yang sama tetap bisa membacanya selama permission OS mengizinkan.

Jadi, kalau lu menaruh .env.local, dump database, transcript meeting, private note, credential cloud, atau file customer sample di folder repo, jangan merasa aman cuma karena file itu nggak akan ke-commit.

File sensitif bukan cuma .env

Bagian ini penting karena banyak checklist keamanan berhenti di secret. Padahal di workflow AI coding, “sensitif” bisa berarti lebih luas.

  • Secret langsung: API key, token, private key, service account, cookie session.
  • Data produk: export database, sample user data, log production, payment event, error report mentah.
  • Data internal: roadmap, pricing draft, strategi bisnis, catatan meeting, dokumen legal.
  • Data personal: file Obsidian pribadi, credential homelab, backup chat, catatan klien.
  • File yang bisa memicu aksi: deploy config, script admin, token registry, credential package manager.

GitHub Secret Scanning membantu mendeteksi banyak jenis token yang masuk ke GitHub. Itu layer penting, apalagi dengan push protection dan alert. Tapi secret scanning tetap bukan pengganti access control lokal. Dia membantu setelah secret terdeteksi di jalur tertentu. Sementara AI agent boundary harus mencegah file yang tidak relevan ikut terbaca sejak awal.

Prompt bagus nggak cukup kalau aksesnya terlalu bebas

Gua sering lihat pola begini: developer bikin instruksi panjang, “jangan baca file rahasia”, “jangan sentuh folder tertentu”, “jangan jalankan command destruktif”. Instruksi itu berguna, tapi jangan diperlakukan sebagai satu-satunya kontrol.

Prompt adalah arahan perilaku. Permission adalah batas teknis. Dua-duanya perlu, tapi level kepercayaannya beda. Kalau file benar-benar tidak boleh dibaca, idealnya agent memang tidak punya kemampuan membaca file itu. Bukan cuma “dilarang membaca”.

Analogi sederhananya: lu nggak bilang ke tamu rumah, “tolong jangan buka brankas,” sambil kasih dia kunci brankas. Lu simpan kuncinya di tempat berbeda.

Checklist repo AI-ready sebelum lu menjalankan agent

Kalau lu mau pakai AI coding agent secara lebih aman, mulai dari checklist praktis ini. Nggak harus sempurna di hari pertama, tapi minimal lu punya kebiasaan yang lebih sadar risiko.

  1. Pisahkan file sensitif dari repo kerja. Jangan taruh dump database, private note, atau credential permanen di root repo kalau agent sering jalan di sana.
  2. Pakai credential dummy untuk development. Kalau butuh .env, gunakan nilai lokal yang bisa dicabut cepat dan tidak punya akses production.
  3. Jalankan agent di user/container terpisah. Boundary OS lebih kuat daripada berharap agent selalu patuh instruksi.
  4. Mount folder secara allowlist. Untuk task tertentu, agent cuma perlu src/, tests/, dan dokumen teknis. Dia nggak selalu perlu seluruh home directory.
  5. Bikin AGENTS.md atau instruksi repo. Jelaskan struktur project, command aman, folder yang boleh disentuh, dan area yang wajib minta konfirmasi manusia.
  6. Review diff, bukan cuma chat history. Chat bisa terdengar meyakinkan, tapi keputusan merge tetap harus lihat perubahan file nyata.
  7. Aktifkan secret scanning dan pre-commit guard. Ini bukan pagar utama, tapi bagus sebagai alarm tambahan kalau ada token masuk jalur Git.
  8. Cabut token yang pernah terpapar. Jangan cuma hapus dari file. Anggap token lama sudah tidak bisa dipercaya.

Workflow aman yang realistis buat developer solo

Kalau lu kerja sendiri, keamanan sering kalah sama kecepatan. Gua paham, karena workflow builder memang sering berantakan: ada server, blog, automation, Obsidian, credential, dan eksperimen kecil dalam satu mesin. Tapi justru karena itu, boundary sederhana punya dampak besar.

Setup realistisnya bisa begini: satu folder repo bersih untuk coding, satu folder private di luar repo untuk credential dan catatan sensitif, satu .env.example yang aman dibaca agent, lalu satu file instruksi AGENTS.md yang menjelaskan command build/test dan batasan folder. Kalau task berisiko, jalankan agent di container atau VM kecil dengan folder yang di-mount terbatas.

Ini bukan paranoia. Ini hygiene. Sama seperti lu nggak menjalankan script random dari internet di laptop utama, lu juga nggak perlu memberi agent akses ke seluruh file cuma supaya dia bisa memperbaiki satu komponen React.

Apa bedanya dengan Codex logging bug sebelumnya?

Sebelumnya gua pernah membahas Codex logging bug sebagai pengingat bahwa AI coding tool juga butuh resource guardrail: disk, log, CPU, timeout, dan observability. Topik kali ini beda. Fokusnya bukan “tool bisa boros resource”, tapi “tool perlu batas data”.

Dua isu ini nyambung dalam satu prinsip: AI coding agent harus diperlakukan seperti sistem yang menjalankan kerja nyata, bukan chatbot biasa. Kalau dia bisa membaca file, menjalankan command, dan mengubah repo, maka dia butuh policy, sandbox, audit trail, dan review. Semakin agent berguna, semakin penting batasnya jelas.

Takeaway singkat

  • .gitignore membantu Git, tapi bukan security boundary untuk AI agent.
  • File sensitif mencakup secret, data user, log, dokumen internal, dan script yang bisa memicu aksi.
  • Prompt jangan dijadikan pagar utama. Permission dan isolasi environment lebih kuat.
  • Repo yang AI-ready perlu instruksi, allowlist folder, credential dummy, secret scanning, dan review diff.
  • Kalau agent nggak perlu membaca file tertentu, jangan kasih akses dari awal.

FAQ singkat

Apakah berarti developer harus berhenti pakai AI coding agent?

Nggak. AI coding agent tetap berguna. Yang perlu diubah adalah cara memberi akses. Treat agent seperti tool yang bisa bekerja di lingkungan lu, bukan sekadar text generator.

Apakah .env boleh ada di repo lokal?

Boleh kalau memang workflow lu butuh, tapi pakai credential development yang bisa dicabut cepat. Jangan pakai token production full-access untuk eksperimen agent.

Apakah secret scanning cukup?

Belum cukup. Secret scanning itu alarm. Boundary akses itu pagar. Lu butuh keduanya kalau workflow AI mulai menyentuh repo serius.

Apa langkah pertama yang paling murah?

Pindahkan file sensitif ke luar repo kerja, buat .env.example, lalu tulis AGENTS.md sederhana berisi folder aman, command test, dan area yang butuh konfirmasi manusia.

Penutup

AI coding agent bikin developer bisa kerja lebih cepat. Tapi kecepatan tanpa batas file bisa jadi utang keamanan yang baru terasa nanti. Menurut gua, skill penting developer ke depan bukan cuma prompt engineering, tapi access engineering: tahu data mana yang boleh dibaca tool, data mana yang harus dipisah, dan kapan automation perlu rem.

Kalau lu mulai pakai agent buat task harian, jangan cuma tanya “model mana yang paling pintar?” Tanya juga: “file apa aja yang sebenarnya boleh dia lihat?”

Referensi / Bacaan Lanjut