Monitor Mode Hermes Agent 0.20.0 Bisa Mengakses Layanan Privat dan Melewatkan Perubahan

Hermes Agent 0.20.0 menambahkan monitor mode untuk cron: job dapat mengawasi URL atau output script, menghitung perubahan, lalu menjalankan analisis hanya ketika sumbernya berubah. Konsepnya efisien. Masalahnya, implementasi yang ada pada release stabil belum memberi batas jaringan dan konsistensi state yang cukup kuat.

Issue upstream #81406 menunjukkan dua risiko dalam satu fitur. URL monitor dapat menjangkau loopback, jaringan privat, atau endpoint metadata. Di saat yang sama, perubahan sumber dan output tertentu dapat dianggap tidak berubah sehingga run yang seharusnya terjadi justru dilewati.

Status per 8 Agustus 2026: release publik terbaru masih Hermes Agent 0.20.0 / v2026.8.3. Fix ada di PR #81407, tetapi masih terbuka dan belum masuk patch release resmi.

Apa fungsi monitor mode

Monitor mode ditujukan untuk job yang tidak perlu menjalankan agent pada setiap tick. Hermes mengambil sumber, membandingkan hasilnya dengan snapshot sebelumnya, lalu meneruskan proses hanya ketika ada perubahan.

Pola ini cocok untuk:

• memantau changelog atau halaman status;
• mengawasi output script internal;
• mengecek feed yang berubah tidak teratur;
• menghemat token karena agent tidak dipanggil ketika hasil sama.

Ada dua jenis sumber utama: monitor_url untuk HTTP(S), dan script monitor yang dijalankan oleh cron runner. Temuan #81406 paling sensitif berada pada fetch URL dan cara state perubahan disimpan.

Risiko pertama: URL monitor dapat mencapai jaringan privat

Pada jalur yang dilaporkan, validasi awal hanya memastikan URL memakai skema HTTP atau HTTPS. Itu belum cukup untuk mencegah server-side request forgery atau SSRF.

Tanpa pemeriksaan tujuan jaringan, operator yang salah memasukkan URL, konfigurasi yang sudah terpengaruh, atau redirect dari situs publik dapat membawa fetch ke alamat seperti:

http://127.0.0.1:PORT
http://localhost:PORT
http://10.x.x.x/
http://172.16.x.x/
http://192.168.x.x/
http://169.254.169.254/

Masalah redirect perlu diperhatikan. URL pertama dapat terlihat publik, tetapi responsnya mengarahkan Hermes ke loopback, layanan intranet, atau metadata cloud. Pemeriksaan hanya pada URL awal tidak menutup jalur tersebut.

Konten respons kemudian tersedia bagi cron agent untuk dianalisis. Jadi dampaknya bukan sekadar request internal terjadi. Data yang dikembalikan endpoint privat dapat masuk ke konteks kerja agent dan berpotensi ikut tersimpan dalam snapshot, log, atau output run, bergantung pada konfigurasi deployment.

Belum ada bukti dari sumber primer bahwa bug ini sudah dieksploitasi secara luas. Namun kelas risikonya jelas: monitor URL pada release stabil tidak boleh dianggap sebagai fetcher aman untuk input yang tidak sepenuhnya dipercaya.

Risiko kedua: perubahan nyata dapat dianggap tidak ada

Bug yang sama juga menyentuh integritas monitoring. State hasil sebelumnya dapat digunakan kembali ketika sumber monitor diganti, sementara observasi lama yang masih berjalan dapat menulis hash usang setelah perubahan konfigurasi.

Skenarionya seperti ini:

1. job sedang mengambil sumber A;
2. operator mengubah job agar memantau sumber B;
3. fetch sumber A yang masih berjalan selesai belakangan;
4. hasil lama menulis state tanpa memastikan sumber job masih A;
5. observasi awal sumber B dapat dibandingkan dengan baseline yang salah atau ditekan.

Selain race tersebut, implementasi lama mengubah output menjadi representasi teks sebelum menghitung hash. Dua respons yang berbeda pada level byte dapat menjadi identik setelah decoding atau normalisasi. Perubahan whitespace tertentu, data non-UTF-8, atau byte yang tidak terwakili dengan tepat berisiko tidak memicu run.

Bagi operator, efeknya membingungkan: scheduler hidup, job tetap terdaftar, tidak ada error besar, tetapi perubahan yang seharusnya dianalisis tidak menghasilkan notifikasi.

Kenapa ini material untuk operasional

Monitor cron biasanya dipakai karena operator ingin sistem diam saat tidak ada perubahan dan bergerak cepat saat ada perubahan. Bug ini merusak dua asumsi itu sekaligus.

Dari sisi security, fetcher terlalu bebas menjangkau network target. Dari sisi reliability, change detector dapat kehilangan event. Kombinasi tersebut berbahaya untuk workload seperti:

• monitoring deployment atau status service internal;
• watch release dan security advisory;
• perubahan harga, stok, atau konfigurasi;
• alarm berbasis output script;
• pemantauan endpoint cloud atau panel admin;
• automasi yang meneruskan hasil ke tool lain.

Jika job mempunyai tool write, akses credential, atau delivery eksternal, konten dari endpoint yang tidak semestinya dapat memengaruhi langkah agent berikutnya. Itu tidak otomatis berarti remote code execution, tetapi blast radius-nya lebih besar daripada monitor read-only yang hanya menulis log lokal.

Status fix upstream

PR #81407 mengusulkan perbaikan pada empat area.

1. Pemeriksaan SSRF pada setiap hop

Fetch URL diarahkan ke helper URL-safety yang memvalidasi tujuan awal dan setiap redirect. Respons juga dibatasi ukurannya agar monitor tidak mengunduh data tanpa batas.

2. Hash dari byte sumber yang sebenarnya

Sumber URL dan output script dipertahankan sebagai raw bytes untuk kebutuhan hash. Text decoding tetap dapat dipakai untuk prompt atau tampilan, tetapi tidak lagi menentukan identitas perubahan.

3. State terikat pada identitas sumber

Setiap perubahan sumber menaikkan generation. Penulisan state menggunakan compare-and-set terhadap identitas sumber tersebut sehingga observasi lama tidak boleh menimpa baseline job yang sudah diarahkan ke sumber baru.

4. Outcome no_change dicatat secara eksplisit

Tick yang sehat tetapi tidak menemukan perubahan mendapat outcome durable no_change. Ini membuat operator dapat membedakan suppress yang memang normal dari run yang gagal atau hilang.

PR tersebut melaporkan 47 regression test lulus. CI publik untuk pull request juga sudah hijau saat audit dilakukan. Tetap saja, statusnya masih pull request terbuka. Kode yang lolos CI belum sama dengan patch stabil yang sudah dipilih dan dirilis maintainer.

Mitigasi aman sebelum patch resmi

1. Jangan berikan monitor_url dari input eksternal

URL monitor harus berasal dari konfigurasi yang dikendalikan operator. Jangan membangun URL langsung dari email, chat, webhook, hasil web search, atau output model.

2. Pakai allowlist host dan skema

Batasi target ke HTTPS dan hostname yang memang diperlukan. Jika memungkinkan, lakukan validasi pada layer reverse proxy atau egress policy, bukan hanya lewat prompt.

Tolak loopback, link-local, private range, hostname internal, dan metadata cloud. Validasi ulang tujuan setelah DNS resolution dan pada setiap redirect.

3. Matikan redirect jika tidak dibutuhkan

Untuk endpoint yang stabil, respons redirect tidak memberi manfaat besar. Menonaktifkannya mengurangi satu jalur bypass. Jika redirect wajib, izinkan hanya ke hostname yang sudah ada dalam allowlist.

4. Jalankan cron dalam network boundary terbatas

Jangan bergantung pada filter aplikasi sebagai satu-satunya batas. Tempatkan proses Hermes atau worker cron di container, VM, atau network namespace yang tidak dapat menjangkau control plane, database, metadata cloud, dan service privat yang tidak dibutuhkan.

Security policy resmi Hermes juga menegaskan bahwa OS-level isolation adalah boundary yang sebenarnya. Filter in-process hanya lapisan pencegahan tambahan.

5. Re-baseline setelah sumber diubah

Setelah mengganti URL atau script monitor, anggap observasi pertama sebagai baseline baru dan verifikasi manual bahwa perubahan berikutnya benar-benar memicu run. Jangan langsung mengandalkan state lama.

6. Buat canary change yang terukur

Ubah source dengan sentinel yang mudah dikenali, lalu pastikan:

1. hash atau snapshot berubah;
2. execution ledger mencatat run;
3. agent menerima konten baru;
4. delivery sampai ke channel yang benar;
5. observasi kedua tanpa perubahan tidak menghasilkan alert duplikat.

7. Kurangi izin job monitor

Monitor yang hanya butuh membaca dan mengirim notifikasi tidak perlu terminal write, filesystem luas, atau credential produksi. Pisahkan job yang memantau sumber publik dari agent dengan tool sensitif.

Checklist audit cepat

Sebelum mempertahankan monitor mode di produksi, cek hal berikut:

1. semua monitor_url berasal dari config yang dipercaya;
2. destination IP diperiksa setelah DNS resolution;
3. setiap redirect divalidasi ulang;
4. loopback, private, link-local, dan metadata endpoint diblokir;
5. ukuran dan waktu respons dibatasi;
6. perubahan source mereset baseline;
7. state lama tidak bisa menimpa source generation baru;
8. hash dihitung dari raw bytes;
9. tick tanpa perubahan terlihat sebagai outcome yang jelas;
10. job berjalan dengan network dan tool permission minimum.

Keputusan operasional

Monitor mode Hermes Agent 0.20.0 belum layak dipakai untuk URL yang berasal dari input tidak tepercaya atau deployment yang punya akses luas ke jaringan privat. Untuk target publik yang ditentukan operator sendiri, risikonya dapat ditekan dengan egress restriction, redirect policy, allowlist host, dan verifikasi perubahan secara manual.

Rekomendasi Rama Digital: pertahankan monitor mode hanya untuk target yang benar-benar dikontrol, batasi jaringan dari luar proses Hermes, dan anggap PR #81407 sebagai kandidat fix, bukan patch produksi resmi. Tunggu merge dan patch release sebelum menghapus mitigasi.

Sumber primer: release Hermes Agent 0.20.0, issue #81406, PR #81407, dan security policy Hermes Agent.