Belajar Hermes AI Agent - Secure Agent Deployments

#Pendahuluan

Di episode 11 kalian mengamankan bagian dalam agent: membatasi akses tool, menyimpan API keys dengan aman, dan membangun audit trail dengan policy enforcement. Sekarang masalahnya bergeser: agent yang tadi hidup di mesin lokal harus pindah ke cloud atau edge, dan di sana ia menjadi bagian dari infrastruktur yang bisa diserang siapa pun. Episode 12 ini membawa kalian dari "agent yang benar" ke "agent yang benar dan aman di production".

Roadmap episode ini: memilih target deployment cloud atau edge, mengelola secrets dengan penyimpanan eksternal, menyusun network policies dan service authentication, lalu memastikan HTTPS dan webhook endpoint yang aman.

#Memilih Target Deployment: Cloud atau Edge

Sebelum menata keamanan, tentukan dulu di mana agent tinggal. Pilihan ini menentukan permukaan serangan:

• Cloud (server/container) — mudah diskalakan, punya ekosistem keamanan dewasa (IAM, VPC, monitoring). Cocok untuk agent dengan banyak tool dan traffic tak terduga.
• Edge — dekat dengan user, latensi rendah, data bisa diproses lokal. Cocok untuk agent yang menangani data sensitif yang tidak boleh keluar region, tapi resource terbatas dan patch lebih susah.

Yang penting bukan mana yang "paling aman", melainkan mana yang sesuai dengan workload kalian. Agent yang memegang data pasien jelas tidak boleh ditaruh di edge device milik orang lain tanpa sandbox ketat; agent rekomendasi produk justru nyaman di edge karena latensinya kritis.

Apa pun targetnya, satu prinsip tetap berlaku: jalankan agent sebagai user non-root, di dalam container yang tidak punya hak berlebihan.

FROM node:22-alpine AS runtime
WORKDIR /app
COPY out ./out
COPY package.json bun.lock ./
RUN bun install --production
USER node
EXPOSE 3000
CMD ["bun", "run", "start"]

Dengan USER node, proses agent tidak punya izin menulis ke direktori sistem. Kalau container-nya berhasil dibobol, penyerang tidak langsung punya akses root ke host. Build dan uji image-nya lokal dulu sebelum dikirim ke registry dengan docker build -t agent-image ..

#Secrets Management

Pelajaran dari episode 11: jangan pernah menaruh nilai asli secrets di kode atau di image. Nilai itu harus datang dari environment saat runtime. Tapi di production, menaruh semuanya di environment variable juga kurang — setiap orang yang bisa membuka container bisa membacanya.

Gunakan penyimpanan secrets eksternal dan injeksi saat deploy:

• Cloud-native: AWS Secrets Manager, GCP Secret Manager, atau Azure Key Vault.
• Self-hosted: OpenBao atau Vault (lihat series secret management di blog ini).
• Kubernetes: external-secrets untuk menyinkronkan secrets dari vault ke cluster.

Template yang kalian commit di repository hanya menyimpan nama variabelnya:

HERMES_AGENT_ID=agent-checkout
LLM_API_KEY=
DATABASE_URL=
WEBHOOK_SECRET=
OBSERVABILITY_TOKEN=

Saat container jalan, nilai diisi oleh orchestrator atau init process. Rotasi juga jadi jauh lebih mudah: ganti nilai di vault, restart agent, tidak ada kode yang berubah. Untuk secrets yang dipakai agent memanggil LLM provider, pertimbangkan juga scoped keys — token yang hanya boleh memanggil satu endpoint dan punya kuota sendiri.

#Network Policies & Service Authentication

Agent di production tidak boleh bisa mengobrol dengan semua orang. Batasi siapa yang bisa memanggilnya, dan ke mana ia boleh keluar.

Network policies di Kubernetes mengatur arah dan tujuan traffic. Contoh: agent hanya boleh keluar ke port 443 (HTTPS) dan dilarang menjangkau IP internal:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress
spec:
  podSelector:
    matchLabels:
      app: hermes-agent
  policyTypes: ["Egress"]
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8
              - 192.168.0.0/16
              - 169.254.0.0/16
      ports:
        - port: 443
          protocol: TCP

Ini sekaligus memblokir SSRF: kalau agent punya tool yang menarik URL, ia tidak bisa menyelinap ke metadata service (169.254.169.254) karena IP link-local ada di daftar pengecualian.

Service authentication memastikan pemanggil itu memang berhak. Dua lapis yang umum:

• mTLS — kedua sisi membuktikan identitas lewat sertifikat. Bagus untuk komunikasi antar service internal (agent ke tool service).
• Token / API key per service — setiap konsumen agent (bot, dashboard, service lain) diberi kredensial sendiri yang bisa dicabut dan dilacak.

Jangan pernah membiarkan agent terbuka polos di jaringan internal hanya karena "di dalam VPC aman". Satu container yang ter-compromise cukup untuk menghantam seluruh cluster.

#Enforcing HTTPS

Semua traffic keluar-masuk agent harus terenkripsi. HTTPS itu bukan opsional lagi; HTTP polos berarti siapa pun di jaringan bisa membaca percakapan agent — termasuk prompt yang mungkin berisi data user.

Dua hal yang harus diperhatikan:

1. Terminate TLS di reverse proxy — Caddy, nginx, atau service mesh. Agent sendiri fokus ke logika, TLS dihandle di layer depan.
2. Redirect semua traffic HTTP ke HTTPS dan tolak request non-TLS bila memungkinkan.

Kalau kalian menerima traffic dari internet, gunakan juga allowlist origin dan batas ukuran body untuk memblokir request mencurigakan sebelum sampai ke agent:

ingress:
  tls:
    enabled: true
  rateLimit: 100
  windowSeconds: 60
  allowedOrigins:
    - https://app.example.com
  maxBodyBytes: 1048576

#Webhook Endpoint yang Aman

Agent sering jadi sisi penerima webhook — misalnya event dari payment gateway atau CI. Webhook itu bisa dipanggil siapa pun yang tahu URL-nya, jadi kalian harus membuktikan bahwa pengirimnya asli. Standarnya: tanda tangan HMAC di header, dihitung dari raw body dan shared secret.

import crypto from "node:crypto";
 
export function verifyWebhook(rawBody, signature, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)
    .digest("hex");
  const a = Buffer.from(signature ?? "");
  const b = Buffer.from(expected);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

Poin penting: verifikasi harus dilakukan pada raw body sebelum parsing JSON, karena parsing mengubah representasi string dan tanda tangan jadi tidak cocok. Gunakan timingSafeEqual untuk perbandingan — jangan === biasa — supaya penyerang tidak bisa menebak secret lewat timing attack. Pastikan juga event webhook idempotent: proses ulang event yang sama tidak boleh menggandakan efeknya.

#Penutup

Episode 12 membawa agent kalian keluar dari laptop dan masuk ke infrastruktur nyata. Kalian memilih antara cloud dan edge berdasarkan kebutuhan, menjalankan agent sebagai user non-root, memindahkan secrets ke penyimpanan eksternal, membatasi egress dan pemanggil dengan network policies serta service authentication, memaksa HTTPS, dan melindungi webhook endpoint dengan verifikasi HMAC yang aman.

Inti yang harus dibawa pulang:

• Permukaan serangan berbeda di cloud dan edge — pilih target berdasarkan workload, bukan tren.
• Secrets hidup di penyimpanan eksternal, bukan di image atau environment yang bisa dibaca sembarang orang.
• Network policies membatasi egress sekaligus menutup celah SSRF ke metadata service.
• Service authentication wajib, termasuk antar service internal — jangan percaya "aman di dalam VPC".
• Webhook harus diverifikasi dengan HMAC atas raw body dan dibandingkan memakai timingSafeEqual.

Episode 13 berikutnya kita balik ke sisi pemakai: User Authentication & Persona — skenario multi-user, perilaku agent per user, persona dan role-based access, serta privasi data pengguna. Sampai jumpa!