GitLost: Menipu Agen AI GitHub hingga Membocorkan Repositori Privat

• Noma Labs menemukan GitLost, sebuah kerentanan indirect prompt injection di GitHub Agentic Workflows, yang memungkinkan data repositori privat dalam organisasi yang sama terekspos di komentar publik hanya melalui issue di repositori publik
• Fitur ini mengompilasi workflow Markdown menjadi file YAML Actions, dan agen AI berbasis Claude atau GitHub Copilot membaca issue, memanggil tool, serta mengakses repositori dalam organisasi
• Workflow yang rentan membaca Title dan Body issue pada event issues.assigned lalu merespons dengan add-comment, dalam kondisi memiliki izin baca untuk repositori publik dan privat
• Penyerang hanya perlu membuka issue yang tampak meyakinkan di repositori publik, tanpa kode, hak akses, atau kredensial; dalam pengujian, isi README.md dari poc dan testlocal diposting ke komentar issue publik
• Guardrail GitHub tidak berhasil memblokir seperti yang dimaksud pada variasi “Additionally”, dan pada AI agentic, context window itu sendiri harus dilihat sebagai permukaan serangan serta konten yang dikendalikan pengguna harus dipisahkan dari instruksi tepercaya

---

Batas Kepercayaan yang Diincar GitLost

• Noma Labs menemukan kerentanan bernama GitLost di Agentic Workflows baru milik GitHub
• Ketika penyerang yang tidak terautentikasi memposting GitHub Issue yang dimanipulasi ke repositori publik dalam organisasi yang sama, agen dapat dipancing untuk mengambil data repositori privat dalam organisasi tersebut
• Metode serangannya termasuk indirect prompt injection, yaitu menyembunyikan instruksi berbahaya di dalam konten yang dibaca agen AI
• Jika instruksi tersembunyi dari penyerang diproses dengan prioritas lebih tinggi daripada instruksi yang dimaksudkan operator, data privat dapat terekspos melalui komentar issue publik yang bisa dilihat siapa saja

Cara Kerja GitHub Agentic Workflows

• GitHub Agentic Workflows memungkinkan tim menulis otomatisasi repositori dengan bahasa alami
• Workflow ditulis sebagai file Markdown .md, lalu dikompilasi menjadi file GitHub Actions .yml berformat YAML
• Saat dijalankan, agen AI berbasis Claude atau GitHub Copilot bekerja dalam izin yang telah dikonfigurasi
  • Membaca GitHub Issue
  • Memanggil tool
  • Mengakses repositori lain dalam organisasi

Kondisi Workflow yang Rentan

• Konfigurasi rentan yang diidentifikasi Noma Labs menjadi bermasalah saat issue publik digabungkan dengan izin agen
  • Workflow dipicu oleh event issues.assigned GitHub
  • Membaca Title dan Body issue
  • Memposting komentar dengan tool add-comment
  • Memiliki izin baca ke repositori lain dalam organisasi
    • Repositori publik
    • Repositori privat
• Penyerang tidak memerlukan penulisan kode, hak akses, atau kredensial terpisah
• Syarat yang diperlukan hanyalah membuka issue di repositori publik milik organisasi yang menggunakan GitHub Agentic Workflow

Alur Serangan

• Para peneliti membuat GitHub Issue yang tampak meyakinkan seolah-olah diminta oleh VP Sales setelah rapat pelanggan
• Ketika issue ditugaskan, workflow action terpicu, dan dalam pengujian mekanisme yang sama juga berjalan pada GitHub workflow action lain
• Setelah otomatisasi GitHub menugaskan issue, workflow yang dijalankan oleh event membuat agen mengambil isi repositori
• Agen dipancing untuk mengambil isi README.md dari repositori berikut
  • Repositori publik poc
  • Repositori privat testlocal
• Setelah itu, agen GitHub memposting isi tersebut sebagai komentar issue di repositori publik, sehingga bisa dibaca siapa saja

Melewati Guardrail dengan “Additionally”

• GitHub memiliki guardrail terbatas untuk mencegah skenario ini
• Noma Labs menguji berbagai variasi berulang kali seperti penyerang
• Ketika kata kunci “Additionally” ditambahkan, muncul perilaku tak terduga: model tidak menolak dan justru menyusun ulang output
• Dengan bypass ini, guardrail GitHub tidak berfungsi sebagaimana dimaksud dan gagal mencegah kebocoran data

PoC dan Data yang Terekspos

• Noma Labs memublikasikan hasil verifikasi, workflow reproduksi, dan bukti nyata
  • Workflow run: https://github.com/sasinomalabs/poc/actions/runs/23909666039
  • Issue: https://github.com/sasinomalabs/poc/issues/153
• Data yang bocor mencakup isi README.md dari repositori berikut
  • sasinomalabs/poc: repositori publik
  • sasinomalabs/remote-ping: repositori publik, dikonfirmasi tidak memiliki README
  • sasinomalabs/testlocal: repositori privat

Asumsi Keamanan yang Berubah pada AI Agentic

• Context window agen menjadi ruang kerja sekaligus permukaan serangan
• Semua konten yang dibaca agen dapat dijadikan senjata
  • Issue
  • Pull Request
  • Komentar
  • File
• Model keamanan tradisional sering berasumsi bahwa batas kepercayaan ditegakkan oleh kode
• Dalam sistem agentic, sebagian batas kepercayaan ditegakkan oleh perilaku model
• Karena model pada dasarnya mengikuti instruksi, prompt injection menjadi jenis kerentanan kategoris pada AI agentic, seperti SQL injection pada aplikasi web
• Jenis kerentanan ini membutuhkan strategi dan pertahanan yang sistematis

Rekomendasi Pertahanan dan Proses Pengungkapan

• Konten yang dikendalikan pengguna tidak boleh diperlakukan sebagai input instruksi tepercaya untuk agen AI
• Izin agen harus dibatasi pada cakupan minimum yang diperlukan
  • Agen yang dapat mengakses banyak repositori menjadi target serangan yang sangat bernilai
• Konten yang dapat dipublikasikan agen harus dibatasi, misalnya saat merespons isi issue
• Sebelum input pengguna diberikan ke model, input tersebut harus dibersihkan atau diisolasi dari konteks instruksi
• GitLost telah diungkapkan secara bertanggung jawab kepada GitHub, dan detail kerentanan dibagikan dalam kondisi GitHub telah mengetahuinya

[GN⁺]

Komentar Hacker News

• Analogi bahwa injeksi prompt menempati posisi yang sama pada AI agen seperti injeksi SQL pada aplikasi web terasa aneh. Saya rasa injeksi prompt jauh lebih fatal bagi LLM daripada injeksi SQL.
  Injeksi SQL terjadi ketika input pengguna menjadi bagian dari string perintah yang diteruskan ke mesin SQL; jika input berbahaya menutup perintah saat ini dengan token sintaks SQL lalu menambahkan perintah SQL miliknya sendiri, mesin akan menjalankan keduanya. Solusinya adalah memakai string perintah yang tetap, statis, dan sudah dikompilasi sebelumnya seperti prepared statement, lalu memperlakukan input pengguna arbitrer hanya sebagai data.
  Mitigasi yang mirip pada agen adalah menyediakan tindakan tetap seperti “baca repo 1”, “baca repo 2”, lalu memakai input pengguna hanya sebagai data untuk memilih tindakan mana yang dijalankan. Namun teknik ini sudah kita sebut menu. Nilai LLM pada dasarnya ada pada kemampuannya melampaui menu, sedangkan nilai SQL tidak perlu melampaui “logika yang sudah didefinisikan sebelumnya dan diterapkan pada data arbitrer”; di situlah bedanya.

  • Benar. Injeksi SQL muncul karena input pengguna diperlakukan sebagai bagian dari perintah, bukan sebagai data murni; masalahnya selesai ketika keduanya dipisahkan. Injeksi prompt sulit dihindari karena input pengguna itu sendiri memang dimaksudkan sebagai perintah.
  • Alih-alih mengatakan “solusinya adalah prepared statement”, intinya lebih tepat disebut parameter binding. Parameter dikirimkan terpisah dari pernyataan SQL untuk memisahkan kode dan data pengguna.
    Membatasi agen agar hanya boleh melakukan tindakan tertentu hanya menangani sebagian masalah khusus, dan itu pun tidak memisahkan kode dari data pengguna, jadi bukan masalah yang sama. Menyediakan tindakan terbatas lebih mirip dengan memakai izin basis data yang lebih ketat. Jika hanya SQL yang memang boleh dijalankan pengguna yang diizinkan, injeksi SQL pun menjadi tidak terlalu berarti.
  • Ini memang jenis masalah yang sama dengan injeksi SQL, tetapi tingkat kesulitan penyelesaiannya tidak sama. Banyak masalah yang lebih halus bisa muncul, tetapi sebagai analogi untuk penjelasan, ini cukup layak.
    Memaksa memilih dari menu juga salah satu cara, tetapi ruang lingkup tindakan yang mungkin dapat dirancang lebih luas. Jika diberi alat email, agen bisa mengirim spam ke pelanggan; jika dikunci agar hanya bisa membalas, cakupan insidennya bisa dikurangi. Seperti kerentanan ketika data bocor lewat rendering gambar, eksfiltrasi data juga harus dibatasi.
  • Injeksi prompt tidak fatal, dan sebenarnya lebih mirip sesuatu yang mengungkap masalah arsitektur keamanan yang mendasarinya daripada masalah nyata itu sendiri. Ini mirip serangan rekayasa sosial terhadap manusia.
    Solusinya juga sama. Terapkan kontrol akses berbasis peran dengan prinsip hak istimewa minimum, dan wajibkan persetujuan administrator untuk tindakan penting. Dengan begitu, hal terburuk yang bisa dilakukan LLM sendirian hanyalah mengeluarkan kata-kata yang tidak pantas.
  • Saya tidak yakin ini masalah sedalam yang dibayangkan semua orang. Injeksi SQL juga sama berbahayanya. Sebab ia membuka akses tak terbatas ke semua operasi basis data yang dapat dilakukan oleh pengguna kueri.
    Salah satu mitigasinya adalah prepared statement, tetapi mitigasi lain adalah tidak memberikan akses penuh ke seluruh basis data kepada siapa pun. Pengguna hanya-baca seharusnya tidak bisa melakukan DROP TABLE, terlepas dari ada tidaknya injeksi SQL.
    Agen ini memiliki akses baca tanpa batas dan tidak punya konsep “penerima” dalam jawabannya. Jika memasukkan izin penerima, membuat akses baca ditolak secara otomatis akan cukup sederhana. Itu bukan satu-satunya solusi, tetapi tidak sulit membayangkan solusi ke arah itu.
    Contoh “menu” juga berarti sebenarnya tidak ada yang berubah. Baik LLM maupun pegawai manusia, yang diizinkan hanyalah kumpulan tindakan tetap yang terkendali. Kebebasannya terutama ada pada ekspresi, sementara pemberian izin adalah kumpulan tetap. Saya tidak mengerti mengapa harus melampaui menu.

• Saya tidak paham kenapa ini dianggap kerentanan GitHub. Para peneliti memberi agen hak akses ke repositori privat, lalu menyuruhnya menjawab pertanyaan dari repositori publik, jadi tentu saja ekstraksi informasi privat menjadi mungkin
  Ini sama seperti membuat job CI biasa yang bisa mengakses secret lalu menjalankannya dari PR publik. Kalau GitHub dikonfigurasi agar kode publik atau instruksi LLM berjalan dalam konteks yang bisa mengakses hal sensitif, ya akan bocor. Itu bukan salah GitHub, melainkan salah orang yang mengaturnya

  • Sepertinya mereka berasumsi izin dibatasi hanya ke repositori tempat pertanyaan diajukan saat ini, dan tidak mencakup repositori privat. Saya bisa memahami logika kedua pihak
  • GitHub tidak membuat pengaturan akses agen secara aman menjadi mudah. Token akses umum dan kredensial aplikasi tidak punya kontrol granular yang cukup untuk memberi akses langsung ke repositori privat
    Seketat apa pun scope token diatur, akses ke repositori publik selalu diizinkan, dan misalnya jalur kebocoran melalui issue repositori publik tetap ada. Agar aman, perlu dilengkapi dengan proxy MITM yang menerapkan kontrol lebih ketat daripada yang disediakan GitHub
    GitHub Agentic workflows semestinya menjadi solusi resmi lapis pertama untuk masalah seperti ini, tetapi tampaknya masih banyak pekerjaan yang harus dilakukan, baik dari sisi model keamanan maupun kegunaan yang aman
    Detailnya: https://haulos.com/blog/do-not-give-your-agent-github-access...
  • Inti dari serangan prompt injection seperti ini adalah kegagalan membatasi cakupan izin agen dengan benar. Dalam kasus ini, tergantung pekerjaan yang benar-benar perlu dilakukan agen, bisa dibuat agen workflow terpisah per repositori, atau agen dengan akses repositori lebih luas tetapi dikonfigurasi agar hanya bisa dipicu oleh pengguna dalam allowlist
    Ini juga kompatibel dengan pengembangan terbuka, tetap memungkinkan pihak luar membuka issue publik, sekaligus mencerminkan tingkat kepercayaan yang diberikan kepada masing-masing pengguna. Jika dipikirkan dengan benar, pilihannya mungkin lebih banyak
    Untuk itu, perlu dukungan teknis untuk penentuan scope dan izin yang rinci, serta perlu meluangkan waktu untuk menimbang apa yang ingin dicapai dengan agen dan izin serta kemampuan minimum yang dibutuhkan
    Yang pertama sepertinya akan datang. Penggunaan agen masih seperti era Wild West. Menarik untuk melihat abstraksi seperti apa yang akan mengurangi friksi saat manusia merancang agen untuk menemukan dan mendefinisikan scope serta izin, dan antarmuka seperti apa yang akan menyeimbangkan granularitas dan kegunaan saat membatasi kemampuan agen
    Yang kedua selalu menjadi hambatan utama dalam membangun perangkat lunak berkualitas tinggi. Meluangkan waktu untuk berpikir dengan benar dan mengimplementasikannya dengan benar bertentangan langsung dengan gaya “bergerak cepat dan merusak” yang melempar agen ke mana saja
  • Apakah ada cara untuk memisahkan akses per workflow agentic, sehingga satu workflow bisa mengakses data sensitif dan yang lain hanya mengakses data publik? Apakah default-nya membatasi scope hanya ke repositori saat ini? Apakah GitHub memberi peringatan yang memadai tentang risiko menggabungkan akses data repositori privat dengan workflow agentic?
    Jika jawaban untuk salah satu pertanyaan ini adalah “tidak”, maka itu masalah. GitHub Workflows klasik juga punya banyak eskalasi hak akses melalui workflow yang dipicu PR, tetapi itu topik terpisah
  • Dari sudut pandang izin, LLM hanyalah terminal bodoh. Yang diinginkan tampaknya seperti membuat izin sintetis secara ad hoc berdasarkan prompt, tetapi ini lebih mirip “membersihkan SQL pengguna dengan regex” daripada solusi “kalimat yang sudah disiapkan”. Kita sudah tahu bagaimana akhirnya
    Solusi sebenarnya adalah membuat UI kontrol izin per prompt yang lebih baik. Seperti memilih “apakah melakukan pencarian web”, harus mudah untuk menyalakan dan mematikan opsi “sertakan repositori privat saya”

• Lucu melihat para peneliti melewati guardrail yang dibanggakan GitHub hanya dengan satu kata seperti “Additionally”. Ini menunjukkan bahwa upaya membangun batas keamanan yang kuat di dalam jendela konteks LLM pasti gagal
  Model pada dasarnya dibuat untuk mengikuti instruksi, jadi ketika aturan sistem dan input pengguna dicampur, instruksi yang lebih baru atau lebih gigih akan menang

• Kenapa bagian “responsible disclosure” tidak mencantumkan kapan diperbaiki, atau apakah GitHub mengakui atau menolaknya? Disebutkan bahwa GitLost telah diungkapkan secara bertanggung jawab kepada GitHub dan detailnya dibagikan dalam kondisi GitHub mengetahuinya, jadi apakah ini belum diperbaiki?

  • Ini bukan bug perangkat lunak biasa, dan tidak bisa “diperbaiki” dengan cara yang sama seperti kita tidak bisa “memperbaiki” staf dukungan umum agar tidak tertipu. Jawabannya adalah tidak memberi LLM akses ke input yang tidak tepercaya dan data sensitif pada saat yang sama
  • Saya penasaran apakah penulis asli bereksperimen dengan pengaturan di bawah ini dalam keadaan aktif. Ada pengaturan harfiah yang mencegah ini. Saya ingin tahu apakah pengaturan ini muncul karena laporan ini, atau apakah pelapor ceroboh karena tidak menyebutkannya sebagai komentar
    https://github.github.com/gh-aw/reference/cross-repository/#...
  • Apa yang mau diperbaiki? Mereka hanya memberi LLM hak akses ke data privat sekaligus kemampuan membaca komentar publik. Itu cuma konfigurasi yang salah

• Perusahaan besar seperti Microsoft kini menempelkan AI ke semua produk agar bisa mengklaim diri sebagai perusahaan AI karena tekanan investor. Mirip dengan yang dilakukan Adobe
  Konsumen mulai lelah dengan integrasi AI setengah matang seperti ini, dan rasanya titik jenuhnya akan segera datang

  • Saya sudah selesai. Saya pindah ke Forgejo. Bagus sekali dan semuanya bekerja lebih baik
    Serius, saat mengklik ke sana kemari semuanya terasa instan, dan CI dengan runner terpasang juga berjalan indah. Dokumentasi pengaturan runner bisa sedikit lebih jelas, tetapi selain itu semuanya sangat mulus
  • Microsoft adalah perusahaan publik. Investor mana yang menekan mereka untuk merusak GitHub dengan fitur AI yang tidak diinginkan? Di forum mana hal itu terjadi?
  • Saya setuju, tetapi menurut saya produk AI untuk enterprise cukup mengesankan. Investor dan konsumen tidak begitu tahu, dan karyawan tidak bisa bertransaksi
    Pendapatannya benar-benar ada dan mengesankan, serta menggantikan pendapatan berbasis konsumen/kursi. Pasar masih menurunkan multiple SaaS, dan menurut saya penilaian itu benar. Jika pendapatannya dipisahkan dalam laporan kuartalan, ada kisah pertumbuhan besar yang berasal dari efisiensi nyata

• Saya tidak mengerti mengapa action yang berjalan dalam konteks repositori publik memiliki hak akses ke repositori privat. Jika melihat workflow-nya, tampaknya ia menggunakan github token yang biasanya tidak diberi izin ke repositori privat
  Atau apakah agennya sendiri somehow punya hak yang lebih tinggi? Jika begitu, berarti agennya salah dikonfigurasi. Kita sudah tahu bahwa tidak boleh percaya bahwa agen akan memaksakan sesuatu

• Tulisan ini terbaca seperti pemasaran Noma. Ada nama yang imut, logo, judul clickbait, bahkan nada dramatis yang tampaknya ditujukan untuk pembaca nonteknis
  Kalau ditanya kerentanan sebenarnya apa, intinya adalah jika Anda memberikan data privat ke LLM dan membiarkan siapa saja berinteraksi dengannya, data itu bisa bocor. Terlalu jelas

• Orang-orang seperti ini akan memberi LLM izin tulis ke seluruh disk lalu mengeluh bahwa ia melakukan operasi destruktif
  Kalau ingin agar agen AI tidak membaca repositori privat, jangan beri hak akses repositori privat. Ini bukan masalah bypass izin, melainkan masalah prompt injection, dan tidak bisa diselesaikan secara andal di lapisan agen

• Ini mungkin sudah menjadi masalah yang terselesaikan, atau GitHub masih belum menyelesaikannya dan sementara itu pelaku jahat akan mencoba mengeksploitasi kerentanan di berbagai repositori
  Karena jumlah repositorinya besar, ada peluang tidak nol terjadinya kebocoran. Namun, seperti korban penipuan, hampir tidak ada yang akan mengakui bahwa mereka mengalami kebocoran