Bug Model Alias Hermes Agent Bisa Membocorkan API Key

Model Alias Hermes Agent 0.20.0 Bisa Mengirim API Key ke Endpoint yang Salah

Alias model seharusnya mempermudah perpindahan model atau endpoint. Pada Hermes Agent 0.20.0, kombinasi model_aliases, provider: custom, dan base_url justru bisa membawa API key provider yang sedang aktif ke host lain.

Temuan ini dilaporkan melalui issue #83612 pada 11 Agustus 2026. Reporter sudah memasang credential milik endpoint alias, tetapi Hermes mengabaikannya. Sistem mengambil key provider default, mengganti URL tujuan ke endpoint custom, lalu mengirim request dengan key yang salah. Respons 401 adalah gejala yang terlihat. Risiko sebenarnya adalah credential provider A keluar ke host provider B.

Per 12 Agustus 2026, release publik terbaru masih Hermes Agent 0.20.0 / v2026.8.3, dirilis 3 Agustus 2026. PR #84199 sudah menyiapkan perbaikan dan test regresi, tetapi statusnya masih terbuka. Artinya, operator stable belum punya patch resmi dalam release baru.

Akar masalahnya ada di urutan resolusi credential

Hermes memakai model_aliases untuk memberi nama pendek pada kombinasi model, provider, dan endpoint. Operator bisa, misalnya, membuat alias yang menunjuk inference server internal atau vendor custom.

Bug #83612 muncul dari dua kesalahan yang saling memperburuk.

Pertama, struktur internal DirectAlias hanya membawa model, provider, dan base_url. Field api_key dari konfigurasi alias tidak dibaca. Credential yang sengaja disiapkan untuk endpoint tersebut hilang sebelum request dibuat.

Kedua, Hermes menyelesaikan credential berdasarkan provider aktif lebih dulu. Setelah key ditemukan, kode baru mengganti base_url dengan endpoint alias. Karena key sudah terisi, nilai lama tetap dibawa.

Alurnya menjadi seperti ini:

sesi berjalan memakai provider A;
Hermes mengambil API key provider A;
operator beralih ke alias custom milik provider B;
base_url berubah ke host provider B;
API key provider A tidak ikut diganti;
request validasi model dan request berikutnya dapat membawa key provider A ke host provider B.

Ini bukan sekadar salah mapping yang menghasilkan 401. Request validasi /v1/models pun disebut dapat membawa credential yang salah keluar dari boundary provider asal.

Konfigurasi seperti apa yang perlu diaudit

Reproducer resmi memakai alias custom dengan endpoint dan credential sendiri:

model_aliases:
 internal-model:
 provider: custom
 base_url: https://inference.example.com/v1
 model: model-name
 api_key: ${INTERNAL_MODEL_API_KEY}

Pada stable 0.20.0, jangan menganggap api_key di entry tersebut pasti dipakai. Issue resmi menunjukkan field itu dapat diabaikan, sementara key provider default justru ikut terkirim ke host alias.

Prioritas audit tinggi jika:

provider default memakai key dengan billing tinggi atau permission luas;
alias menunjuk vendor, proxy, partner, atau server di trust boundary berbeda;
alias sering dipanggil lewat /model <alias>;
workflow memakai hermes chat -m <alias> untuk one-shot task;
reverse proxy, API gateway, atau vendor tujuan mencatat header request;
satu profile memuat beberapa credential provider.

Alias yang hanya mengganti nama model tanpa base_url sendiri tidak termasuk reproducer utama. Fokus audit ada pada perpindahan endpoint atau origin.

Dampak keamanan yang terbukti dan yang belum

Sumber primer membuktikan reproducer mengirim key OpenRouter ke endpoint pihak ketiga yang berbeda. Itu cukup untuk memperlakukan kejadian sebagai kemungkinan exposure credential.

Namun, belum ada bukti publik bahwa semua instalasi Hermes 0.20.0 terdampak, terjadi eksploitasi massal, atau endpoint penerima menyimpan dan menyalahgunakan key. Dampak aktual tergantung konfigurasi serta apakah alias pernah dipakai.

Pisahkan status insiden menjadi tiga:

Alias rentan ada, tetapi belum pernah dipakai. Belum ada bukti key keluar. Nonaktifkan konfigurasi dan lanjutkan audit.
Alias pernah dipakai dan menghasilkan 401. Anggap credential salah mungkin sudah mencapai endpoint tujuan.
Log tujuan atau proxy menunjukkan Authorization header diterima. Perlakukan sebagai exposure terkonfirmasi, rotasi key, dan audit aktivitas akun.

Jangan memasukkan nilai key ke issue, tiket, atau chat saat menyelidiki. Catat nama secret, host asal, host tujuan, timestamp, dan hasil rotasinya saja.

Status fix upstream belum final

PR #84199 mengubah beberapa jalur penting.

Alias membaca credential miliknya sendiri

DirectAlias ditambah dukungan untuk api_key dan key_env. Tujuannya agar endpoint alias memakai credential yang memang didefinisikan operator, termasuk referensi environment variable.

Credential diselesaikan terhadap endpoint akhir

Perbaikan mengarahkan resolver untuk mempertimbangkan base_url alias sebelum memilih key. Credential sesi lama hanya boleh dipakai kembali jika origin tetap sama. Jika host, scheme, atau port berubah, key lama harus dibuang.

Review lanjutan menemukan pemeriksaan hostname saja belum cukup. https://host dan http://host punya hostname sama, tetapi trust boundary-nya berbeda. Patch terbaru membandingkan origin, termasuk scheme dan effective port, serta menolak downgrade ke HTTP di luar loopback.

Label provider tidak boleh mengalahkan host

Review PR juga menemukan alias dapat memberi label provider built-in sambil menunjuk base_url asing. Jika resolver percaya label tersebut, key provider tetap bisa dipilih untuk host yang salah. Revisi PR memaksa pemilihan credential berdasarkan origin endpoint alias, bukan sekadar label provider.

Jalur interaktif dan one-shot diuji

Test mencakup /model <alias> dan hermes chat -m <alias>, credential literal, key_env, host berbeda, scheme dan port berbeda, built-in provider, Ollama Cloud, serta domain look-alike. Ini arah perbaikan yang tepat.

Tetap bedakan tiga status:

issue sudah dilaporkan;
PR fix sudah tersedia untuk direview;
patch sudah masuk release stable.

Saat artikel ini diterbitkan, dua status pertama sudah ada. Status ketiga belum.

Mitigasi yang aman untuk operator Hermes

1. Hentikan direct alias yang mengganti endpoint

Pada stable 0.20.0, nonaktifkan sementara entry model_aliases yang memakai provider: custom dan base_url berbeda dari provider aktif. Menghapus credential alias saja bukan solusi karena bug justru dapat mengambil key provider default.

2. Gunakan named custom provider sebagai workaround

Issue resmi melaporkan named provider bekerja karena URL dan credential diselesaikan sebagai satu unit. Bentuk umumnya:

providers:
 internal-inference:
 name: Internal Inference
 base_url: https://inference.example.com/v1
 key_env: INTERNAL_MODEL_API_KEY
 model: model-name

model_aliases:
 internal-model:
 provider: custom:internal-inference
 model: model-name

Sesuaikan schema dengan dokumentasi versi yang benar-benar Anda jalankan. Simpan secret lewat environment atau secret store dengan permission ketat, bukan literal di file YAML bila bisa dihindari.

3. Audit penggunaan alias lintas origin

Cari bukti tanpa menampilkan credential:

kapan /model <alias> dijalankan;
pemanggilan hermes chat -m <alias>;
error 401 dari endpoint custom;
provider yang aktif sebelum switch;
origin sebelum dan sesudah switch;
access log pada reverse proxy atau endpoint tujuan;
lonjakan penggunaan quota provider asal.

Periksa host, scheme, dan port. Pindah dari HTTPS ke HTTP pada hostname sama tetap perubahan boundary.

4. Rotasi key bila alias pernah dipakai

Jika alias pernah dipanggil menuju origin berbeda, rotasi key provider yang aktif saat itu. Prioritaskan key dengan billing, akses model premium, write permission, atau cakupan organisasi.

Urutan aman:

buat key pengganti;
pasang di secret store atau environment yang benar;
restart service secara terkontrol;
uji provider asli tanpa alias rentan;
revoke key lama;
periksa usage, billing, dan request mencurigakan.

5. Pastikan log tidak menyimpan Authorization

Cek reverse proxy, API gateway, tracing, error reporter, dan vendor observability. Header Authorization seharusnya tidak masuk log. Jangan memindahkan key ke query parameter karena biasanya lebih mudah terekam di access log dan analytics.

6. Tunggu release resmi yang memuat fix

Jangan menyamakan PR terbuka dengan patch stable. Setelah release berikutnya tersedia, verifikasi changelog dan ancestry tag untuk memastikan commit final PR benar-benar ikut. Jika harus mengambil patch lebih cepat, gunakan build internal terkontrol dengan dummy credential, test lintas origin, canary satu profile, dan rollback yang jelas.

Checklist test setelah patch rilis

Gunakan key dummy dan endpoint yang Anda kuasai. Minimum test:

alias memakai key_env miliknya sendiri;
provider aktif dan alias berada pada host berbeda;
endpoint hanya menerima dummy key alias;
alias tanpa credential tidak menerima key provider aktif;
perubahan HTTPS ke HTTP tidak membawa credential lama;
perubahan port tidak membawa credential lama;
same-origin alias tetap berfungsi;
domain look-alike tidak mendapat key domain resmi;
/model <alias> dan hermes chat -m <alias> konsisten;
log tidak menyimpan Authorization header.

Keputusan operasional

Bug #83612 layak diperlakukan sebagai masalah keamanan, bukan error konfigurasi biasa. Pada Hermes Agent 0.20.0, direct model alias dapat mengabaikan credential miliknya, mengganti endpoint, lalu membawa API key provider aktif ke origin lain.

Rekomendasi Rama Digital: hentikan direct alias lintas endpoint pada stable 0.20.0, audit pemakaian sebelumnya, rotasi key bila alias pernah dijalankan, dan gunakan named custom provider bila endpoint harus tetap tersedia. Tunggu release resmi yang memuat fix final sebelum mengaktifkan kembali pola direct alias tersebut.

Referensi resmi

Tags: #Hermes Agent #model alias #API key #credential leak #custom provider #security

Rama Aditya

Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.

Tentang Rama Digital