Hermes Agent 0.19.1 Punya Celah Konfigurasi Website Blocklist: Salah Ketik Bisa Lolos Diam-Diam

Website blocklist seharusnya menjadi pagar. Di Hermes Agent 0.19.1, pagar itu bisa terlihat aktif padahal sebagian aturannya tidak pernah dimuat.

Masalahnya ada pada validasi konfigurasi. Hermes hanya memakai tiga key di security.website_blocklist: enabled, domains, dan shared_files. Key lain tetap diterima tanpa error atau warning, lalu diabaikan. Salah ketik seperti shared_file -- tanpa huruf s -- membuat file aturan tidak terbaca, sementara agent tetap berjalan seperti biasa.

Status per 3 Agustus 2026: versi stabil terbaru masih Hermes Agent 0.19.1 / v2026.7.30. Bug ini dilacak sebagai issue #76946 dengan label P2. Dua pull request perbaikan sudah terbuka, tetapi belum merge dan belum tersedia dalam release stabil.

Apa yang sebenarnya terjadi

Dokumentasi resmi Hermes mencontohkan konfigurasi berikut:

security:
 website_blocklist:
 enabled: true
 domains:
 - "*.internal.company.com"
 - "admin.example.com"
 shared_files:
 - "/etc/hermes/blocked-sites.txt"

Konfigurasi tersebut valid. Masalah muncul ketika operator menulis key yang kelihatannya masuk akal, tetapi bukan bagian dari schema:

security:
 website_blocklist:
 enabled: true
 domains:
 - "admin.example.com"
 shared_file: "/etc/hermes/blocked-sites.txt" # typo

Hermes 0.19.1 tidak menolak shared_file. Ia juga tidak memperingatkan bahwa key itu tidak dikenali. admin.example.com tetap masuk daftar blokir, tetapi semua domain di /etc/hermes/blocked-sites.txt tidak ikut dimuat.

Dari luar, sistem terlihat sehat:

• YAML berhasil diparse;
• tool web dan browser tetap aktif;
• domain yang ditulis langsung di domains masih dapat diblokir;
• tidak ada warning tentang shared_file;
• aturan dari file eksternal tidak berlaku.

Ini membuat salah konfigurasi sulit terdeteksi. Operator dapat menyimpulkan bahwa seluruh policy sudah terpasang hanya karena satu rule sederhana bekerja.

Kenapa bug ini bisa terjadi

Source tag v2026.7.30 memperlihatkan jalur yang sederhana. Hermes membuat policy default, lalu menggabungkan seluruh mapping buatan user:

policy = dict(_DEFAULT_WEBSITE_BLOCKLIST)
policy.update(website_blocklist)

Setelah itu loader hanya membaca tiga field berikut:

enabled
domains
shared_files

Tidak ada pemeriksaan terhadap key tambahan. Akibatnya, shared_file, allowed, blocklist, atau nama lain dapat masuk ke object konfigurasi lalu tidak pernah dipakai.

Ini berbeda dari dua kegagalan lain yang sudah ditangani lebih jelas:

• domains atau shared_files dengan tipe data salah memicu WebsitePolicyError;
• file yang tercantum di shared_files tetapi hilang atau tidak terbaca menghasilkan warning.

Khusus key yang salah nama, kegagalannya silent.

Dampak operasionalnya

Website blocklist diberlakukan pada tool yang menerima URL, termasuk web search, web extract, dan browser navigation. Tujuannya adalah mencegah agent mengakses domain tertentu, misalnya panel internal, alamat admin, atau host yang memang tidak boleh disentuh.

Kalau daftar utama disimpan dalam shared file, satu typo dapat menghilangkan banyak rule sekaligus. Dampaknya bukan Hermes otomatis menyerang sistem. Dampaknya adalah pagar yang diasumsikan aktif ternyata tidak lengkap.

Risiko ini paling relevan pada deployment yang:

• memberi agent akses web atau browser;
• mengandalkan shared blocklist untuk banyak domain;
• mengelola konfigurasi lewat automation atau template;
• tidak punya test akses setelah perubahan policy;
• menganggap keberhasilan startup sebagai bukti policy sudah benar.

Website blocklist juga merupakan denylist, bukan network sandbox. Ia sebaiknya dipakai sebagai lapisan tambahan, bukan satu-satunya kontrol egress untuk workload sensitif.

Cara mengecek konfigurasi sekarang

1. Audit key yang dipakai

Buka ~/.hermes/config.yaml, lalu pastikan bagian website blocklist hanya memakai key resmi:

security:
 website_blocklist:
 enabled: true
 domains: []
 shared_files: []

Perhatikan bentuk plural: shared_files.

Jangan menganggap key seperti allow, allowed, blocklist, deny, atau shared_file punya efek. Dokumentasi 0.19.1 tidak mendefinisikannya sebagai bagian dari website blocklist.

2. Pastikan shared file benar-benar ada

Periksa setiap path yang tercantum:

while IFS= read -r file; do
 [ -r "$file" ] && printf 'OK %s\n' "$file" || printf 'FAIL %s\n' "$file"
done <<'EOF'
/etc/hermes/blocked-sites.txt
EOF

Ganti daftar tersebut dengan path Anda sendiri. File seharusnya berisi satu rule domain per baris. Baris kosong dan komentar dengan # akan diabaikan.

3. Uji rule dari setiap sumber

Jangan hanya menguji domain yang ada di domains. Pilih minimal satu rule yang berasal dari setiap shared file, lalu minta Hermes mengakses URL uji tersebut melalui tool yang relevan.

Hasil yang diharapkan adalah penolakan sebelum tool berjalan, dengan pesan bahwa host cocok dengan website policy. Gunakan domain milik sendiri atau endpoint yang memang aman untuk test. Jangan menguji panel produksi yang sensitif hanya untuk membuktikan blocklist bekerja.

4. Uji ulang setelah masa cache

Dokumentasi resmi menyebut policy dicache selama 30 detik. Setelah mengubah config, tunggu lebih dari 30 detik sebelum menyimpulkan hasil test, atau restart proses Hermes secara terukur bila prosedur operasional Anda memang mengizinkannya.

5. Tambahkan validation gate di deployment

Sampai fix resmi rilis, validasi key sebelum config dipromosikan. Contoh sederhana dengan Python:

python3 - <<'PY'
from pathlib import Path
import yaml

path = Path.home() / ".hermes" / "config.yaml"
config = yaml.safe_load(path.read_text()) or {}
blocklist = (config.get("security") or {}).get("website_blocklist") or {}
known = {"enabled", "domains", "shared_files"}
unknown = sorted(str(key) for key in set(blocklist) - known)

if unknown:
 raise SystemExit(
 "Unknown security.website_blocklist key(s): " + ", ".join(unknown)
 )

print("website_blocklist keys: OK")
PY

Gate ini tidak menggantikan test akses. Ia hanya menangkap salah nama sebelum deployment.

Kalau menemukan typo

Jangan sekadar mengganti key lalu menganggap pekerjaan selesai. Gunakan urutan berikut:

1. backup config aktif;
2. ganti key menjadi nama yang didokumentasikan;
3. validasi syntax YAML;
4. pastikan setiap shared file readable;
5. tunggu cache kedaluwarsa atau restart secara terukur;
6. test satu rule dari domains dan satu rule dari tiap shared file;
7. simpan hasil test sebagai evidence deployment.

Jika config dikelola oleh template, perbaiki source of truth-nya. Mengedit file hasil render saja membuat typo berpotensi kembali pada deploy berikutnya.

Status patch upstream

Dua pull request, #76960 dan #76983, mengusulkan warning untuk key yang tidak dikenal. CI keduanya sudah melewati rangkaian check utama, tetapi review otomatis masih meminta koreksi pada detail implementasi.

Yang penting bagi operator: source main dan tag stabil v2026.7.30 yang diaudit masih identik pada file tools/website_policy.py. Belum ada warning untuk unknown key di source resmi yang aktif. PR terbuka dan CI hijau belum sama dengan patch yang sudah tersedia.

Jangan mencabut validation gate sampai perbaikan merge, masuk tag release baru, dan perilakunya diuji pada deployment Anda.

Keputusan operasional

Pengguna Hermes Agent 0.19.1 yang mengaktifkan security.website_blocklist perlu mengaudit config sekarang. Fokus utama ada pada ejaan shared_files, keberadaan file, dan bukti bahwa rule dari setiap sumber benar-benar menolak akses.

Tidak perlu mematikan seluruh tool web jika policy yang ada dapat diverifikasi. Namun jangan memperlakukan blocklist sebagai kontrol keamanan yang terbukti aktif hanya karena Hermes berhasil startup. Pada kasus ini, startup sehat justru dapat menyamarkan policy yang tidak lengkap.

Referensi resmi

• Hermes Agent v0.19.1 / v2026.7.30
• Issue #76946 -- unknown key pada website blocklist diterima diam-diam
• Pull request #76960
• Pull request #76983
• Dokumentasi Website Blocklist
• Source tools/website_policy.py pada v2026.7.30