Hermes Agent Menyimpan API Key Custom Endpoint dalam Plaintext: Audit dan Mitigasinya

Hermes Agent 0.19.0 punya celah credential handling yang mudah terlewat karena tampilan Desktop tetap menyamarkan API key. Saat custom OpenAI-compatible endpoint disimpan lewat Settings, secret tersebut justru ditulis mentah ke config.yaml.

Masalah ini dilaporkan di issue #69449, lalu diperbaiki melalui PR #71141 yang merge ke branch utama pada 25 Juli 2026. Stable terbaru saat artikel ini ditulis masih Hermes Agent 0.19.0. Artinya, pengguna stable yang pernah menyimpan custom endpoint perlu mengaudit file konfigurasinya; merge ke main belum otomatis melindungi instalasi yang sedang berjalan.

Status per 25 Juli 2026: upstream sudah memperbaiki write path dan migrasi credential pada penyimpanan berikutnya, tetapi belum ada release stable sesudah 0.19.0. Ini bukan GitHub Security Advisory atau CVE; sumber primernya adalah issue berlabel type/security dan patch upstream.

Apa yang sebenarnya bocor

Masalahnya bukan API key tampil di form. UI memang menggunakan field yang dimasking. Kebocoran terjadi pada jalur penyimpanan.

Ketika pengguna membuka Settings -> Providers -> Custom Endpoints, mengisi base URL, model, dan API key, lalu menekan Save, fungsi _write_custom_endpoint() menyimpan nilai tersebut sebagai providers.<id>.api_key. Seluruh konfigurasi kemudian ditulis ke YAML tanpa enkripsi atau pemindahan secret ke environment file.

Bentuk yang bermasalah secara konsep seperti ini:

providers:
 custom-provider:
 api_key: nilai-secret-mentah

Provider standar sudah memakai pola referensi key_env, sedangkan custom endpoint melewati jalur tersebut. Karena field di UI terlihat aman, operator bisa mengira secret juga ditangani seperti provider bawaan. Faktanya tidak.

Kenapa ini material untuk operator

Plaintext di file lokal tidak otomatis berarti internet bisa membaca key. Dampaknya bergantung pada siapa yang bisa mengakses host dan bagaimana file tersebut diproses. Namun risikonya tetap nyata karena config.yaml lebih mungkin ikut terbaca atau tersalin dibanding secret store khusus.

Surface yang perlu diperiksa antara lain:

• backup home directory atau snapshot VM;
• paket diagnostic dan support bundle;
• sinkronisasi dotfiles atau folder konfigurasi;
• artifact CI, cache, dan salinan staging;
• akses user lain pada mesin yang sama;
• commit Git yang tidak sengaja memasukkan konfigurasi;
• log atau screenshot troubleshooting yang menampilkan isi file.

Jika key punya izin luas, satu salinan konfigurasi lama sudah cukup untuk memperpanjang exposure. Menghapus key dari file aktif tidak membersihkan backup, Git history, atau artifact yang telanjur dibuat.

Siapa yang perlu melakukan audit

Prioritas audit tinggi jika Anda memenuhi salah satu kondisi berikut:

1. memakai Hermes Desktop 0.19.0 atau build sebelum merge PR #71141;
2. menambahkan provider OpenAI-compatible melalui menu Custom Endpoints;
3. memakai CLI hermes model untuk menyimpan custom provider pada versi terdampak;
4. pernah membagikan config.yaml untuk debugging;
5. membackup folder konfigurasi Hermes ke lokasi lain.

Pengguna yang hanya memakai provider bawaan dengan environment variable tidak otomatis terdampak oleh bug spesifik ini. Tetap cek file aktual, bukan menebak dari pola penggunaan.

Patch upstream mengubah apa

PR #71141 memindahkan secret custom endpoint ke .env dan menyimpan referensinya lewat key_env. Nama environment variable diturunkan dari identitas endpoint dengan prefix HERMES_CUSTOM_, bukan sekadar hostname.

Pilihan ini menyelesaikan dua masalah operasional. Dua endpoint pada host yang sama tetapi port berbeda tidak lagi berebut satu slot credential, dan endpoint berbasis alamat IP tetap menghasilkan nama environment variable yang valid.

Patch juga memperbaiki jalur baca dan hapus. Ini penting karena perubahan write path saja akan membuat Desktop menganggap endpoint tidak punya API key, kehilangan credential saat aktivasi, atau meninggalkan env entry ketika endpoint dihapus.

Untuk entry lama yang masih menyimpan api_key plaintext, penyimpanan berikutnya akan memigrasikan secret ke environment file. Referensi environment buatan pengguna seperti ${MY_KEY} dibiarkan tetap seperti semula agar tidak membuat salinan secret tambahan tanpa persetujuan.

PR yang sama memperbaiki bug kedua: tombol Test dapat menemukan banyak model dari /v1/models, tetapi Save sebelumnya hanya menyimpan satu model yang diketik manual. Setelah patch, daftar model hasil discovery ikut dipersist dan tetap tersedia di picker.

Langkah audit yang aman

Jangan menyalin isi secret ke terminal history, tiket, chat, atau laporan. Audit cukup mencari struktur field dan lokasi salinannya.

1. Identifikasi custom endpoint

Buka konfigurasi secara lokal dan cari entry provider custom. Yang dicari adalah keberadaan field api_key berisi nilai literal, bukan isi nilainya.

Jika audit dilakukan lewat automation, hasilnya cukup berupa status seperti plaintext credential field found dan path file. Jangan mencetak matching line penuh.

2. Periksa permission

Pastikan file konfigurasi dan environment hanya dapat dibaca account yang menjalankan Hermes. Permission ketat tidak menghapus exposure historis, tetapi mengurangi risiko akses lokal ke depan.

3. Telusuri salinan

Cek backup, snapshot, repository, artifact build, dan support bundle yang mungkin memuat konfigurasi. Prioritaskan lokasi yang pernah dibagikan ke pihak lain atau disimpan di layanan cloud.

4. Tentukan apakah key perlu dirotasi

Rotasi diperlukan jika key pernah masuk Git, log, artifact publik, support bundle eksternal, atau lokasi yang kontrol aksesnya tidak bisa dibuktikan. Jika file hanya berada pada host tunggal dengan akses terbatas, keputusan tetap harus mempertimbangkan nilai dan scope key.

5. Batasi scope setelah rotasi

Buat key baru dengan izin dan spending limit minimum. Pisahkan credential production, staging, dan eksperimen. Satu key global membuat insiden lokal punya blast radius yang terlalu besar.

Jangan menganggap update main sama dengan sudah aman

Fix sudah merge, tetapi stable terbaru masih 0.19.0. Ada tiga jalur yang masuk akal:

• Risiko rendah: hentikan sementara penyimpanan custom endpoint baru, audit file, lalu tunggu stable release berikutnya.
• Risiko menengah: uji build yang memuat merge commit di staging, pastikan migrasi berhasil, lalu deploy dengan rollback plan.
• Credential sudah terekspos: rotasi sekarang. Menunggu release tidak menarik kembali key dari backup atau Git history.

Setelah memakai build yang sudah dipatch, simpan ulang endpoint dan verifikasi bahwa konfigurasi hanya menyimpan referensi credential. Lakukan verifikasi tanpa menampilkan nilai .env.

Apa yang tidak boleh disimpulkan

Issue ini tidak membuktikan remote code execution, pencurian key dari server Nous, atau kebocoran massal pengguna. Tidak ada GitHub Security Advisory resmi pada repository saat audit dilakukan, dan upstream memberi issue ini prioritas P3 walaupun berlabel security.

Tetapi label rendah tidak membuat praktik plaintext menjadi aman. Bagi operator, pertanyaan yang relevan bukan seberapa dramatis judul issue, melainkan apakah secret pernah masuk ke file yang lifecycle-nya lebih longgar daripada secret store.

Kesimpulan operasional

Pengguna Hermes Agent 0.19.0 yang pernah menyimpan custom endpoint perlu mengecek config.yaml hari ini. Cari literal api_key tanpa mencetak nilainya, audit salinan file, rotasi credential jika pernah keluar dari boundary host, dan batasi scope key baru.

Patch sudah ada di branch utama dan memindahkan secret ke .env melalui key_env, sekaligus memperbaiki persistence daftar model. Instalasi belum dianggap terlindungi sampai build yang memuat patch benar-benar berjalan, entry lama sudah dimigrasikan, dan tidak ada salinan plaintext yang tertinggal di lokasi lain.

Sumber primer:

• Issue #69449: Custom endpoint API key stored in plaintext in config.yaml
• PR #71141: custom endpoint keys go to .env, and Save keeps the whole model list
• Issue #69988: model discovery hanya menyimpan satu model
• Hermes Agent 0.19.0 stable release