Hermes Agent 0.20.0 Masih Punya Risiko Otorisasi Silang di Discord Multiplex

Hermes Agent 0.20.0 sudah memperbaiki sebagian masalah isolasi allowlist pada gateway multi-profile. Namun, masih ada gate otorisasi kedua yang dapat membaca allowlist milik profil lain ketika beberapa profil Discord dijalankan dalam satu proses dengan gateway.multiplex_profiles: true.

Issue upstream #80026 menunjukkan dampak yang konkret: user yang hanya diizinkan oleh profil A bisa dianggap sah saat masuk ke profil B, sementara user yang memang dikonfigurasi untuk profil B justru ditolak.

Ini adalah regression pada pemisahan kebijakan antarprofil, bukan bukti kebocoran token atau credential. Meski begitu, untuk deployment yang memakai profil Discord dengan trust boundary berbeda, dampaknya material: keputusan akses bisa dibuat memakai policy yang salah.

Status per 7 Agustus 2026: release publik terbaru masih Hermes Agent 0.20.0 / v2026.8.3. Perbaikan untuk issue ini masih berupa pull request terbuka. Belum ada patch release resmi yang dapat dianggap menyelesaikannya.

Apa yang sebenarnya terjadi

Dalam mode multiplex, beberapa profil gateway berjalan di proses Hermes yang sama. Masing-masing profil seharusnya membawa credential, adapter, dan aturan aksesnya sendiri.

Perbaikan sebelumnya, PR #75970, sudah memindahkan banyak pemeriksaan Discord dan Telegram ke policy per-adapter. Jalur message, slash command, component callback, username resolution, allow-all, dan beberapa gate lain tidak lagi bergantung langsung pada environment global.

Masalahnya, setelah adapter melakukan pemeriksaan awal, gateway masih punya gate otorisasi kedua. Pada release 0.20.0, helper _auth_env() bekerja seperti ini:

1. baca nilai dari secret scope profil aktif;
2. jika nilainya ada, gunakan nilai tersebut;
3. jika key tidak ada atau kosong, fallback ke os.environ milik proses;
4. gunakan nilai environment itu untuk menentukan platform allowlist;
5. policy lokal pada adapter baru diperiksa jika allowlist dari environment kosong.

Fallback pada langkah ketiga yang berbahaya dalam mode multiplex. Environment proses dapat masih memuat nilai yang sebelumnya dijembatani oleh profil lain. Karena nilainya tidak kosong, gateway menganggap policy sudah ditemukan dan tidak melanjutkan ke allowlist lokal profil penerima.

Bentuk kegagalannya

Reproducer dua profil pada issue resmi menggunakan skenario sederhana:

• profil A mengizinkan user 111 lewat nilai environment;
• profil B tidak punya allowlist environment;
• profil B mengizinkan user 222 lewat konfigurasi adapter;
• request diuji pada konteks profil B.

Hasil yang seharusnya:

user 111 pada profil B: ditolak
user 222 pada profil B: diterima

Hasil yang dilaporkan pada source release 0.20.0:

user 111 pada profil B: diterima
user 222 pada profil B: ditolak

Dua hal terjadi sekaligus. Ada false authorization untuk user dari profil lain, lalu ada false rejection untuk user yang seharusnya sah pada profil penerima.

Kenapa PR #75970 belum menutup seluruh masalah

PR #75970 adalah perbaikan yang substansial. Patch itu membuat gate awal pada adapter Discord dan Telegram memakai snapshot serta konfigurasi yang dimiliki setiap instance adapter. Ia juga mencegah sejumlah nilai authorization ditulis kembali ke environment global saat profil multiplex dimuat.

Namun arsitektur Hermes masih melakukan pemeriksaan setelah jalur adapter. Gate downstream di gateway/authz_mixin.py tetap bisa membaca process-global environment jika secret scope profil tidak memiliki key yang dicari.

Jadi statusnya bukan "fix sebelumnya gagal total". Yang lebih akurat:

• gate tingkat adapter sudah jauh lebih terisolasi;
• gate otorisasi kedua di gateway masih punya fallback lintas profil;
• beberapa jalur asynchronous dan session restoration juga perlu mempertahankan ownership profil asal secara konsisten.

Perbedaan ini penting agar operator tidak menganggap semua instalasi Discord rusak, tetapi juga tidak menganggap merge PR #75970 sudah menjadi bukti isolasi end-to-end.

Siapa yang paling berisiko

Issue ini paling relevan jika deployment memenuhi seluruh kondisi berikut:

• memakai Hermes Agent 0.20.0 atau source yang belum memuat fix final;
• mengaktifkan gateway.multiplex_profiles: true;
• menjalankan lebih dari satu profil Discord dalam proses yang sama;
• setiap profil punya allowlist, role, channel, pairing state, atau tingkat kepercayaan berbeda;
• satu profil melayani komunitas atau user yang tidak boleh masuk ke agent context profil lain.

Deployment satu profil tidak berada pada skenario reproduksi utama. Multiplex dengan policy identik juga mengurangi perbedaan keputusan, tetapi tetap bukan alasan untuk mengabaikan isolation bug.

Risiko meningkat tajam bila profil A bersifat lebih terbuka daripada profil B. Contohnya, satu bot komunitas dan satu bot operasional internal dijalankan bersama, tetapi keduanya seharusnya tidak berbagi user allowlist maupun tool context.

Dampak keamanan yang perlu dibaca dengan tepat

Belum ada bukti pada sumber primer bahwa issue ini membocorkan bot token, membaca credential profil lain, atau otomatis mengeksekusi tool berbahaya. Klaim seperti itu akan terlalu jauh.

Dampak yang sudah direproduksi adalah cross-profile authorization decision: gate milik profil B dapat memakai allowlist yang berasal dari profil A. Jika request yang salah lolos kemudian diteruskan ke agent dan tool context profil B, boundary akses yang dirancang operator tidak lagi dapat dipercaya.

Severity praktis bergantung pada konfigurasi:

• rendah bila profil hanya untuk test dan tidak punya tool sensitif;
• menengah bila profil memiliki data atau percakapan berbeda;
• tinggi bila satu profil punya akses produksi, filesystem, terminal, secret-backed API, atau automation eksternal yang tidak boleh dipicu user profil lain.

Status fix upstream

Saat artikel ini ditulis, ada beberapa jalur perbaikan yang masih terbuka.

PR #80238 mengusulkan perubahan sempit: jika profile scope aktif dan multiplex digunakan, key yang tidak ada harus mengembalikan default. Ia tidak boleh jatuh lagi ke os.environ global.

PR #80360 mengarahkan pembacaan gate kedua melalui helper yang sudah scope-aware dan menambah regression coverage untuk Discord serta QQ. Perubahan lanjutannya juga menyentuh busy session, startup resume, dan callback adapter yang berjalan di luar secret scope profil.

Sementara itu, PR #76166 membawa pendekatan yang lebih luas: policy Discord dan provenance profil transport dipertahankan melewati adapter admission, gate kedua, pairing store, restored session, component callback, dan voice callback.

Belum ada satu pun dari jalur itu yang boleh diperlakukan sebagai patch stabil hanya karena code-nya tersedia di GitHub. Sampai maintainer memilih, merge, menguji, dan merilis perbaikan, release tag 0.20.0 tetap perlu dianggap terdampak pada skenario multiplex tersebut.

Mitigasi paling aman sekarang

1. Jangan multiplex profil dengan trust boundary berbeda

Mitigasi terbaik adalah memisahkan profil Discord sensitif ke proses atau instance Hermes yang berbeda. Dengan begitu, setiap proses punya environment, state, dan lifecycle sendiri.

Prioritaskan pemisahan untuk kombinasi seperti:

• bot komunitas dan bot internal;
• bot read-only dan bot yang punya terminal atau write access;
• bot client A dan bot client B;
• bot publik dan bot admin;
• profil staging dan profil produksi.

Pemisahan proses memang menambah operational overhead, tetapi boundary-nya jauh lebih mudah diaudit daripada mengandalkan fallback config dalam satu process-global environment.

2. Audit semua sumber allowlist

Catat policy per profil dari seluruh sumber yang dipakai:

• YAML atau config.extra;
• environment variable Discord;
• environment gateway umum;
• flag allow-all;
• allowed roles dan channels;
• pairing state;
• username-to-ID resolution.

Cari nilai global yang masih terisi walau profil penerima tidak mendefinisikannya. Dalam bug ini, nilai non-kosong dari profil lain justru dapat mencegah policy lokal profil penerima dievaluasi.

3. Jalankan test silang dua profil

Jangan hanya menguji bahwa user A dapat memakai profil A. Buat matriks negatif:

1. user A diterima profil A;
2. user A ditolak profil B;
3. user B diterima profil B;
4. user B ditolak profil A;
5. hasil tetap sama ketika urutan startup profil dibalik;
6. allow-all pada satu profil tidak membuka profil lain;
7. restored session dan callback tetap memakai policy profil asal.

Test negatif lintas profil adalah bukti yang lebih penting daripada startup sehat.

4. Fail closed bila ownership profil ambigu

Jika log atau session source tidak menunjukkan profil transport yang jelas, jangan teruskan request ke agent context yang lebih sensitif. Ambiguitas ownership seharusnya menghasilkan penolakan, bukan fallback ke nilai global.

5. Jangan cherry-pick PR terbuka langsung ke semua produksi

Jika pemisahan proses belum memungkinkan dan patch harus dipasang sebelum release resmi, pilih satu kandidat fix, review diff, jalankan test dua profil, lalu deploy ke canary. Pastikan ada rollback.

Jangan menggabungkan beberapa PR yang tumpang tindih tanpa memahami boundary yang mereka ubah. Patch sempit pada _auth_env() mungkin menutup reproducer utama, tetapi belum tentu mencakup restored session, delayed callback, voice path, atau pairing ownership.

Checklist sebelum multiplex diaktifkan lagi

Sebelum dua profil Discord dengan trust berbeda kembali disatukan, pastikan:

1. profil B tidak pernah membaca allowlist environment profil A;
2. policy adapter profil B tetap dipakai ketika key scoped tidak ada;
3. startup order tidak mengubah hasil otorisasi;
4. allow-all, role, channel, dan pairing state terisolasi per profil;
5. slash command serta component callback mengikuti policy profil penerima;
6. session yang dipulihkan tetap membawa ownership transport asal;
7. background delivery dan voice callback tidak kehilangan profile scope;
8. test single-profile tetap lolos;
9. fix sudah masuk release resmi atau build internal telah melewati canary;
10. log menyediakan profile ID yang cukup untuk audit keputusan akses.

Keputusan operasional

Hermes Agent 0.20.0 tetap bisa dipakai untuk deployment Discord satu profil dengan testing normal. Yang perlu dihentikan adalah asumsi bahwa gateway.multiplex_profiles sudah aman untuk menggabungkan profil dengan boundary akses berbeda hanya karena gate adapter telah diperbaiki.

Rekomendasi Rama Digital: pisahkan profil Discord sensitif ke instance terpisah sampai fix end-to-end masuk release resmi. Jika multiplex harus dipertahankan sementara, audit process-global allowlist, jalankan matriks test silang, dan kurangi tool permission pada profil yang berisiko.

Sumber primer: release Hermes Agent 0.20.0, issue #80026, PR #75970, PR #76166, PR #80238, dan PR #80360.