Belajar Hermes AI Agent - Security & Access Control
Episode 11 of 23

Belajar Hermes AI Agent - Security & Access Control

Mengamankan agent dari dalam: melindungi akses tool dan API keys, membatasi capability ke operasi yang aman, serta membangun audit trail dan policy enforcement untuk melacak dan mengendalikan setiap tindakan agent.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Di episode 10 kalian memberi agent kekuatan besar: workflow berantai, planning, dan retry otomatis. Semakin banyak kekuatan yang dimiliki sebuah sistem, semakin serius kewajiban mengamankannya. Episode 11 membalik perspektif — kita bukan menambah fitur, tapi menutup celah dan memasang pagar.

Roadmap episode ini: mengamankan akses tool dan API keys, membatasi capability agent ke operasi yang aman, lalu membangun audit trail dan policy enforcement.

Memetakan Ancaman Sebelum Mengamankan

Keamanan tidak dimulai dari tool, tapi dari pemetaan aset dan ancaman. Untuk agent, tiga aset terpentingnya adalah: secret (API keys), kemampuan eksekusi (tool dengan efek samping), dan data (memory dan hasil tool). Pertanyaan kunci untuk tiap aset: siapa yang boleh melihatnya, siapa yang boleh memicunya, dan apa yang terjadi kalau disalahgunakan.

threat-model.md
Aset        | Pelaku           | Risiko
------------+------------------+-----------------------------
API keys    | user, penyerang  | Pencurian, pemakaian di luar
Tool exec   | prompt injection | Eksekusi perintah berbahaya
Data memory | user lain        | Kebocoran data antar sesi

Catatan penting: pelaku terbesar bukan penyerang di internet, tapi input yang tak terduga — konten halaman web, dokumen, atau pesan user yang menyusupkan instruksi jahat ke dalam prompt (prompt injection, sudah disinggung di episode 5 dan 6). Semua pagar di episode ini dirancang dengan ancaman itu di kepala.

Mengamankan Akses Tool dan API Keys

Mulai dari yang paling bernilai: kredensial. Aturan pertama sudah diingatkan sejak episode 3 — nilai asli secret tidak pernah masuk kode atau config yang di-commit. Di production, secret disimpan di penyimpanan eksternal dan diinjeksikan saat runtime (detail lengkap di episode 12). Di local, pakai file dot-env yang masuk .gitignore.

Selain menyimpan dengan aman, batasi juga cakupan secret:

  • Scoped API keys — key dengan izin hanya untuk satu resource atau satu kuota. Agent yang cuma perlu membaca tidak diberi key berizin menulis.
  • Kredensial per tool, bukan per agent — database memakai user khusus read-only, API eksternal memakai token dengan scope minimal.
  • Jangan pernah log atau tampilkan nilai secret dalam output tool — mask kalau perlu direferensikan.
secret-helper.ts
import { loadSecret } from "@hermes/security";
 
const dbCred = await loadSecret("DATABASE_READONLY_URL");
const registry = await loadSecret("REGISTRY_TOKEN", { scopedTo: "registry.example.com" });

Helper loadSecret mengambil secret dari penyimpanan yang sudah dikonfigurasi, bukan dari kode. Buat kebiasaan: setiap kali kredensial baru ditambahkan, tanyakan dua hal — apakah scope-nya seminimal mungkin, dan apakah nilainya akan bocor kalau log agent terbaca.

Membatasi Capability ke Operasi yang Aman

Di episode 4 kalian belajar mengatur permission per tool. Di episode 11, terapkan disiplin itu sebagai kebijakan menyeluruh, bukan keputusan satu per satu. Prinsipnya: default deny. Semua yang tidak eksplisit diizinkan otomatis dilarang.

agents/ops.yml - kebijakan deny by default
security:
  default_deny: true
  allowed_operations:
    - db.query (read_only)
    - web.search
    - web.fetch (domains: ["*.example.com"])
  sandbox:
    backend: docker
    network: none
  secrets:
    env_allowlist: ["DATABASE_READONLY_URL"]

Blok sandbox di atas menjawab ancaman code execution dari episode 4: agent jalan di backend docker tanpa akses network, sehingga script yang dieksekusi tidak bisa menjangkau host atau internet. Kalau capability code_execution aktif, jalankan selalu di sandbox terisolasi — bukan di host utama. Nilai default_deny adalah saklar utama yang menyalakan mode aman secara keseluruhan.

Danger

Default deny bukan saran, melainkan fondasi. Sekali kalian mulai dengan allow-list, setiap tool baru otomatis membutuhkan keputusan eksplisit sebelum bisa dieksekusi — itulah yang diinginkan.

Audit Trail

Audit trail adalah catatan siapa melakukan apa, kapan, dan dengan hasil apa. Tanpa catatan ini, kalian tidak bisa memastikan insiden keamanan, mematuhi regulasi, atau mengevaluasi apakah kebijakan bekerja. Di Hermes, setiap pemanggilan tool direkam sebagai event dengan metadata lengkap.

audit-event.json
{
  "event": "tool.call",
  "agent": "ops-agent",
  "session": "ses-ops-8821",
  "user": "arman@example.com",
  "tool": "db.query",
  "args_hash": "a1b2c3...",
  "result": "success",
  "timestamp": "2026-08-03T10:15:30Z",
  "duration_ms": 320
}

Perhatikan args_hash — hash dari argumen pemanggilan, bukan nilai mentahnya. Ini menjaga nilai sensitif tidak masuk log sambil tetap memungkinkan verifikasi. Untuk operasi berisiko tinggi (pembayaran, hapus data, kirim email), simpan snapshot argumen lengkap di penyimpanan terpisah yang dilindungi.

Audit trail tidak berguna kalau tidak pernah dibaca. Jadikan review rutin — mingguan atau bulanan — untuk mencari anomali: tool yang dipanggil di luar jam kerja, permission denied yang sering ditembak, atau argumen mencurigakan. Pola ini akan berkembang jadi alerting otomatis di episode 20.

Policy Enforcement

Policy enforcement adalah layer yang menegakkan aturan di level runtime, bukan sekadar harapan di system prompt. Prompt bisa dibujuk, policy tidak. Hermes memuat policy dari config dan memaksanya di controller sebelum setiap aksi dieksekusi.

policies/access.yaml
policy: access-control
rules:
  - when: { tool: "http.post", target: "billing-api" }
    require: "user.confirmed_payment"
    else: deny
  - when: { tool: "db.query" }
    require: "tool.read_only == true"
    else: deny
  - when: { tool: "fs.write" }
    require: "user.role in ['admin']"
    else: deny

Setiap aksi melewati aturan ini di controller sebelum dieksekusi. Kalau kondisi tidak terpenuhi, aksi di-deny dan dicatat di audit trail — agent bahkan tidak sempat menjalankan tool-nya. Ini perbedaan krusial dengan permission statis: policy bisa mempertimbangkan konteks seperti peran user atau status konfirmasi, bukan hanya nama tool.

Info

Hubungkan policy dengan audit trail: setiap aksi yang di-deny direkam sebagai event terpisah. Pola pelanggaran yang sering muncul — misalnya agent mencoba fs.write berkali-kali — adalah sinyal untuk mengetatkan prompt atau menambah sandbox.

Penutup

Episode 11 menutup celah pada kekuatan yang kalian bangun di episode 10: secret diamankan dan di-scope seminimal mungkin, capability dibatasi dengan default deny, sandbox mengisolasi eksekusi berbahaya, audit trail merekam setiap aksi, dan policy enforcement menegakkan aturan di level runtime yang tidak bisa dibujuk lewat prompt.

Inti yang harus dibawa pulang:

  • Aset kunci agent adalah secret, kemampuan eksekusi, dan data — petakan ancamannya dulu sebelum mengamankan.
  • Secret disimpan eksternal dan di-scope per resource; kredensial per tool lebih aman daripada per agent.
  • Default deny dan sandbox adalah pasangan wajib untuk capability berbahaya seperti code execution.
  • Audit trail merekam siapa, apa, kapan, dan hasil apa — dengan argumen di-hash agar tidak bocor.
  • Policy enforcement bekerja di runtime dan bisa mempertimbangkan konteks, tidak seperti permission statis.

Di episode 12 agent kalian pindah ke dunia nyata: Secure Agent Deployments — deployment cloud atau edge, secrets management dan network policies, serta HTTPS dan webhook endpoint yang aman di production. Sampai jumpa!