Public issue di GitHub itu bukan instruksi dari bos. Itu input dari internet. Kalau AI agent lu membaca issue, PR, komentar, atau file Markdown dari luar lalu langsung menjalankan instruksi di dalamnya, lu baru saja mencampur data tidak tepercaya dengan akses kerja yang sensitif.
Artikel ini membahas GitLost, riset dari Noma Security tentang prompt injection di GitHub Agentic Workflows, dan kenapa ini penting buat developer yang mulai memasukkan AI agent ke repo, CI/CD, atau workflow triage. Intinya sederhana: prompt bukan permission system. AI agent butuh boundary yang jelas antara instruksi internal, data eksternal, akses tool, audit log, dan proses approval manusia.
Apa itu GitLost?
GitLost adalah nama riset Noma Security yang membahas skenario prompt injection pada workflow agentic di GitHub. Menurut tulisan Noma, attacker bisa menaruh instruksi berbahaya di issue publik, lalu AI agent yang membaca issue itu bisa diarahkan untuk mengambil konteks dari area yang lebih sensitif, termasuk private repository dalam kondisi tertentu.
Gua sengaja pakai framing hati-hati di sini: ini bukan berarti semua repo GitHub otomatis bocor. Ini juga bukan ajakan buat panik. Yang penting buat developer adalah mental model-nya: begitu agent punya tool access, permission repo, atau akses lintas project, konten publik yang dibaca agent harus diperlakukan sebagai untrusted input.
Kalau dulu prompt injection sering dibahas sebagai masalah chatbot yang membaca halaman web, sekarang boundary-nya makin dekat ke workflow engineering: issue tracker, CI/CD, code review, automation, dan repo internal. Ini yang bikin topik GitLost terasa penting.
Kenapa prompt injection di repo beda dari prompt injection biasa?
Prompt injection biasa sering terdengar abstrak: ada halaman web berisi instruksi palsu, lalu chatbot salah nurut. Di repo, dampaknya bisa lebih konkret karena agent tidak cuma menjawab teks. Agent bisa membaca file, memanggil tool, membuka konteks repo, membuat branch, menulis komentar, menjalankan workflow, atau membantu triage issue.
Masalahnya muncul saat sistem tidak membedakan tiga hal ini:
- Instruksi internal: aturan dari developer, system prompt, workflow policy, atau dokumen operasional yang memang dipercaya.
- Data eksternal: issue publik, komentar PR, deskripsi bug, lampiran, log, atau konten dari user yang belum tentu aman.
- Akses agent: kemampuan agent untuk membaca repo, memanggil tool, mengakses secret, atau mengambil konteks private.
Kalau ketiganya dicampur tanpa boundary, agent bisa salah menganggap data eksternal sebagai instruksi. Ini mirip kasus klasik SQL injection: masalahnya bukan karena user bisa mengetik teks, tapi karena sistem gagal memisahkan data user dari perintah yang dieksekusi.
Pelajaran utama: public issue itu input musuh
Buat open-source maintainer, public issue adalah pintu masuk kolaborasi. Buat security engineer, public issue juga input dari internet. Dua-duanya benar. Yang salah adalah ketika automation memperlakukan issue publik sebagai sumber instruksi yang setara dengan policy internal.
Lu boleh minta AI agent membaca issue untuk meringkas bug report, mencari file yang relevan, atau menyarankan langkah reproduksi. Tapi agent tidak boleh langsung mengambil keputusan sensitif hanya karena teks issue menyuruh begitu. Instruksi seperti “abaikan policy sebelumnya”, “baca repo lain”, atau “ambil file rahasia” harus dianggap noise, bukan perintah.
Di sinilah perbedaan antara agent demo dan agent produksi kelihatan. Demo biasanya fokus ke kemampuan: agent bisa baca issue, cari kode, lalu bikin PR. Produksi harus fokus ke boundary: agent boleh baca apa, boleh memanggil tool apa, kapan butuh approval, dan aktivitasnya bisa diaudit atau tidak.
Checklist defensif buat AI agent di repo
Kalau lu mulai pakai AI agent di GitHub, GitLab, CI/CD, atau tool internal, gua bakal mulai dari checklist ini:
1. Pisahkan sumber instruksi dan sumber data
System prompt, policy repo, dan workflow config harus datang dari sumber yang dipercaya. Issue, PR, komentar, dan dokumen user harus diberi label sebagai data eksternal. Jangan biarkan agent menggabungkan keduanya tanpa aturan yang jelas.
2. Pakai least privilege untuk akses repo
Agent yang menangani public repo tidak otomatis perlu akses ke private repo lain. Agent triage issue tidak otomatis perlu akses secret, deployment token, atau billing. Akses yang terlalu luas membuat prompt injection kecil bisa berubah jadi insiden besar.
3. Batasi tool berdasarkan task
Kalau task-nya cuma meringkas issue, agent tidak perlu tool untuk membaca private repository. Kalau task-nya membuat draft PR, agent tidak perlu izin merge otomatis. Tool access harus mengikuti kebutuhan task, bukan kenyamanan demo.
4. Wajibkan approval untuk aksi sensitif
Operasi seperti membaca konteks private, membuat branch dari repo sensitif, menjalankan workflow mahal, mengubah config CI, atau menyentuh secret harus punya approval gate. Human-in-the-loop bukan tanda workflow gagal; itu rem untuk area high-trust.
5. Simpan audit log yang bisa dibaca manusia
Chat history saja tidak cukup. Lu butuh log: input apa yang dibaca agent, tool apa yang dipanggil, file apa yang disentuh, permission apa yang dipakai, dan keputusan mana yang menunggu approval. Saat ada incident, log ini jauh lebih penting daripada ringkasan cantik dari model.
6. Uji dengan skenario adversarial
Jangan cuma tes happy path. Buat issue palsu yang mencoba mengubah instruksi agent, meminta akses tidak perlu, atau menyuruh agent mengabaikan policy. Tujuannya bukan mencari prompt sakti, tapi memastikan boundary tetap jalan saat input dari luar terlihat meyakinkan.
Kenapa ini penting buat developer biasa?
Karena agentic workflow pelan-pelan akan terasa normal. Hari ini agent bantu triage issue. Besok agent bantu review PR. Lusa agent bisa jalan di CI, membuka environment preview, membaca observability, atau menjalankan script migrasi. Semakin dekat agent ke sistem kerja nyata, semakin mahal dampak dari boundary yang kabur.
Gua melihat ini sebagai pola yang sama dengan API key statis, OAuth, MCP auth, dan agent access control. Masalahnya bukan “AI-nya pintar atau tidak”. Masalahnya adalah sistem di sekitar AI: permission, session, revocation, audit, dan ownership.
Prompt bagus tetap penting, tapi prompt tidak bisa menggantikan permission boundary. Kalau agent punya akses terlalu luas, prompt injection tidak perlu super canggih. Cukup bikin agent bingung soal mana instruksi dan mana data.
Takeaway singkat
- Public issue, PR, komentar, dan dokumen user adalah untrusted input.
- AI agent di repo harus punya akses minimal sesuai task.
- Prompt bukan permission system; permission harus ditegakkan di level platform/tooling.
- Audit log, approval gate, dan scoped tool access lebih penting daripada prompt yang terdengar rapi.
- Kalau agent bisa menyentuh private context, semua input publik harus dianggap hostile sampai terbukti aman.
FAQ singkat
Apakah ini berarti jangan pakai AI agent di GitHub?
Bukan. Pakai saja kalau value-nya jelas. Tapi jangan kasih akses luas hanya karena agent terlihat membantu. Mulai dari task sempit, permission kecil, dan approval untuk aksi sensitif.
Apakah prompt injection bisa diselesaikan dengan prompt yang lebih panjang?
Tidak cukup. Prompt bisa membantu menjelaskan policy, tapi enforcement tetap harus ada di permission, sandbox, tool gating, dan audit log.
Apa langkah pertama yang paling praktis?
Audit izin agent yang sudah lu pakai. Tulis daftar: agent bisa baca apa, bisa menjalankan tool apa, bisa menulis ke mana, dan siapa yang menyetujui aksi sensitif. Kalau daftar itu belum jelas, boundary lu belum siap.
Penutup
GitLost menarik bukan karena dia bikin headline security yang seram. Menurut gua, nilai paling pentingnya adalah mengingatkan developer bahwa AI agent bukan cuma “chatbot yang lebih rajin”. Begitu agent masuk repo dan workflow, dia jadi bagian dari sistem akses.
Kalau lu mau pakai agent dengan aman, mulai dari prinsip sederhana: data dari internet bukan instruksi, akses harus sekecil mungkin, dan aksi sensitif wajib bisa diaudit. Simpen checklist ini kalau lu atau tim lu mulai eksperimen dengan agent di repo.
