Belajar Hermes AI Agent - User Authentication & Persona

#Pendahuluan

Di episode 12 agent kalian sudah aman di infrastruktur: secrets tersimpan eksternal, traffic lewat HTTPS, dan webhook diverifikasi. Tapi siapa yang memakai agent itu? Sampai sekarang kita menganggap ada satu pemakai yang sama di setiap percakapan. Episode 13 ini menghancurkan asumsi itu: kalian akan belajar skenario multi-user, perilaku agent yang menyesuaikan pengguna, persona dan role-based access, serta privasi data pengguna.

Roadmap episode ini: memetakan skenario multi-user dan state per user, mendefinisikan persona beserta kontrol akses berbasis role, lalu menata privasi data mulai dari PII hingga retensi.

#Skenario Multi-User

Agent produksi jarang dipakai satu orang. Bayangkan satu agent "checkout assistant" dipakai oleh semua customer, atau satu agent "ops" dipakai seluruh tim engineering. Setiap user punya konteks, preferensi, dan riwayat yang berbeda — dan kalian tidak boleh mencampurnya.

Kunci dasarnya: setiap turn harus tahu siapa pemanggilnya. Identitas ini jadi bagian dari context agent, dipakai untuk mengunci session, memory, dan hasil tool:

• Session keyed per user — memory dan riwayat percakapan disimpan dengan key yang memuat userId, bukan satu key global.
• Context per turn — tiap request membawa konteks user (identitas, role, preferensi) yang diisi sebelum agent mulai berpikir.
• Tool calls yang ber-identitas — tool yang menulis data harus menerima userId dari konteks, bukan dari asumsi global.

Alur autentikasi di depan agent terlihat seperti ini:

export function resolveUser(req) {
  const token = req.headers.authorization?.replace("Bearer ", "");
  const claims = verifyJwt(token);
  return {
    id: claims.sub,
    role: claims.role,
    sessionKey: `session:${claims.sub}`,
    preferredLang: claims.locale ?? "id",
  };
}

Token di sini dikeluarkan oleh identity provider (Keycloak, Authentik, Authelia — lihat series SSO di blog ini), dan agent mempercayai klaim di dalamnya. Agent sendiri tidak perlu mengelola password; tugasnya hanya memetakan klaim ke perilaku.

#Perilaku Agent per User

Setelah identitas jelas, agent bisa berperilaku berbeda antar user tanpa mengubah kode. Beberapa hal yang bisa dibedakan:

• Bahasa dan nada — user dengan preferensi bahasa tertentu disapa dengan bahasa itu.
• Riwayat dan konteks — user yang baru pertama kali bicara diberi penjelasan langkah demi langkah; user lama langsung ke inti.
• Personalisasi — rekomendasi memakai data user (riwayat pesanan, lokasi), bukan data global.

Contoh implementasinya adalah menyuntikkan profil user ke system prompt saat membangun prompt setiap turn:

export function buildSystemPrompt(user, persona) {
  return [
    persona.systemPrompt,
    `Kamu sedang melayani ${user.id} (role: ${user.role}).`,
    "Gunakan bahasa Indonesia kecuali user bicara bahasa lain.",
    user.frequentTopics?.length
      ? `User sering bertanya soal: ${user.frequentTopics.join(", ")}.`
      : "User baru pertama kali; jelaskan lebih detail.",
  ].join("\n");
}

Yang harus dijaga: personalisasi tidak boleh membuat agent membocorkan data antar user. Kalau tool mencari data user, ia harus selalu difilter dengan userId dari konteks — bukan dari teks prompt yang bisa dimanipulasi.

#Persona & Role-Based Access

Persona mendefinisikan kepribadian, gaya, dan batasan perilaku agent. Role-based access membatasi tool apa yang boleh dipakai berdasarkan role user. Keduanya digabung lewat definisi deklaratif:

personas:
  support:
    description: "Asisten support yang sabar, jelas, dan to the point"
    temperature: 0.4
    allowedTools:
      - search_knowledge_base
      - read_ticket
      - reply_ticket
    disallowedTools:
      - refund_order
      - grant_access
 
  admin:
    description: "Operator yang boleh mengubah konfigurasi dan akses"
    temperature: 0.2
    allowedTools:
      - search_knowledge_base
      - read_ticket
      - reply_ticket
      - refund_order
      - grant_access

Pemilihan persona dilakukan di runtime berdasarkan role user dan jenis request. Konsekuensinya penting: persona yang dipilih harus menolak tool di luar daftar allowedTools di level enforcement — bukan sekadar prompt. Seorang user ber-role support bisa saja menulis "lakukan refund", tapi agent tidak punya tool refund_order yang bisa dipanggil, jadi permintaan itu gagal secara struktural.

Role-based access juga mengontrol apa yang boleh dibaca user. Tool read_ticket harus memastikan user hanya membaca ticket miliknya sendiri, kecuali role-nya memang diizinkan melihat semua.

#Privacy Considerations untuk User Data

Agent memproses data pengguna yang sifatnya pribadi. Tiga area yang wajib dipikirkan sejak awal:

• Minimalkan PII di prompt — jangan masukkan data pribadi penuh ke system prompt kalau hanya butuh satu field. Pakai identitas internal (id, role) sebagai pengganti nama, email, atau alamat.
• Retensi data — definisikan berapa lama riwayat percakapan disimpan. Session yang idle dihapus, percakapan lama di-archive atau dianonimkan sesuai kebijakan. Jangan menyimpan selamanya hanya karena "murah".
• Isolasi dan enkripsi — data user disimpan terpisah per user dan dienkripsi saat istirahat. Jangan pernah menaruh PII di log atau di tool output yang tidak butuh.

Satu latihan sederhana: sebelum logging atau menyimpan, buang dulu field yang tidak diperlukan dari payload percakapan:

export function redact(conversation) {
  return {
    userId: conversation.user.id,
    role: conversation.user.role,
    messages: conversation.messages.map((m) => ({
      role: m.role,
      content: maskEmail(m.content),
    })),
  };
}

Menyimpan userId tetap diperlukan untuk kepentingan audit, tapi detail PII seperti email atau nomor telepon tidak perlu ikut tersimpan.

#Menghubungkan Semua Lapisan

Urutan yang benar di setiap turn:

1. Autentikasi — resolve user dari token (seperti resolveUser di atas).
2. Otorisasi — pilih persona sesuai role dan pastikan tool yang diminta ada di allowedTools.
3. Konteks — bangun system prompt dengan profil user dan persona.
4. Eksekusi — jalankan loop agent dengan tool yang dibatasi persona; tool menulis dan membaca data memakai userId dari konteks.
5. Persistensi — simpan riwayat dengan session key per user, lalui fungsi redaksi, lalu atur retensi.

Kalau kelima lapis ini runtut, agent yang sama bisa melayani ribuan user dengan perilaku berbeda tanpa membocorkan data antar mereka. Untuk mencoba alurnya di lokal, jalankan server agent dengan bun run dev dan kirim token user yang berbeda dari klien masing-masing.

#Penutup

Episode 13 mengubah agent dari "satu mesin untuk semua orang" menjadi "mesin yang tahu siapa yang sedang bicara". Kalian memetakan skenario multi-user dengan session per user, membedakan perilaku agent berdasarkan identitas, mendefinisikan persona dan role-based access yang membatasi tool secara struktural, serta menata privasi data dengan minimasi PII, kebijakan retensi, dan isolasi antar session.

Inti yang harus dibawa pulang:

• Identitas wajib di setiap turn — session, memory, dan tool call harus terikat pada userId dari konteks terautentikasi.
• Persona mengatur kepribadian, role mengatur izin — dan pembatasan tool harus di-enforce, bukan sekadar disarankan lewat prompt.
• Jangan pernah ambil data dari isi prompt — tool selalu memakai identitas dari context sebagai filter.
• Redaksi PII sebelum persistensi, dan tetapkan retensi yang jelas sejak awal.
• Enkripsi dan isolasi data antar user adalah harga mati, bukan fitur pelengkap.

Episode 14 berikutnya kita menyiapkan agent menghadapi kenyataan jaringan yang tidak sempurna: Resilience & Rate Limiting — menghadapi rate limit provider, circuit breakers, retry policies, dan graceful degradation. Sampai jumpa!