Belajar A2A - Secure Multi-Agent Deployment

#Pendahuluan

Di episode 12 kita membangun jembatan antar framework: mengekspos agent ADK lewat to_a2a, memakai remote agent sebagai sub-agent, dan membungkus framework lain dengan adapter. Kini agent-agent kalian mulai berkomunikasi. Pertanyaan berikutnya mengikuti: bagaimana mengamankan seluruh jaringan itu?

Masalahnya berbeda dengan mengamankan satu service biasa. Agent A2A adalah peer yang bisa memulai aksi, bukan sekadar endpoint yang melayani request. Sebuah agent yang terpapar publik bisa dipanggil oleh siapa saja, diminta menjalankan tool, dan hasilnya memengaruhi sistem lain. Roadmap episode ini: kita mulai dari membedakan agent pribadi dan publik, merancang kebijakan ingress dan egress, memanfaatkan service mesh untuk mTLS, lalu menutup dengan tiga teknik hardening — rate limiting, sanitasi input, dan sandboxing eksekusi tool.

#Topologi Jaringan: Agent Pribadi vs Publik

Keputusan pertama dalam arsitektur multi-agent adalah klasifikasi tiap agent:

• Agent pribadi (private) hanya bisa diakses dari dalam jaringan internal. Contohnya agent internal untuk riset data, agent database, atau agent penyusun laporan. Agent ini tidak boleh menerima koneksi dari internet.
• Agent publik (public) diekspos ke luar organisasi, mengekspos AgentCard di domain publik, dan melayani partner yang memercayainya. Contohnya agent layanan pelanggan yang dipanggil mitra bisnis.

Prinsipnya sederhana: default-private. Semakin sedikit agent yang terpapar publik, semakin kecil attack surface-nya. Jika sebuah agent publik harus memanggil agent internal, jangan buka port agent internal ke internet — gunakan relay atau allowlist yang ketat. Satu pola umum adalah memisahkan keduanya secara fisik maupun logis:

DMZ / Public Zone
└── pricing-agent (publik, AgentCard di domain publik)
 
Internal Zone
└── orchestrator (pribadi)
    ├── sales-agent (pribadi)
    └── reporting-agent (pribadi)

Agent publik hanya bertugas menerima task dari partner; pekerjaan berat dilakukan agent internal. Beginilah cara meminimalkan risiko ketika satu agent publik dikompromikan.

#Kebijakan Ingress dan Egress

Setelah topologi ditentukan, kita perlu menegakkan batas tersebut dengan network policy. Di Kubernetes, NetworkPolicy memungkinkan kita mendeklarasikan siapa yang boleh mengirim lalu lintas ke agent (ingress) dan ke mana agent boleh mengirim (egress). Contoh berikut menggabungkan keduanya: hanya orchestrator yang boleh memanggil agent internal, dan agent internal hanya boleh mengirim ke range internal 10.0.0.0/8 — sekaligus menjadi pertahanan awal terhadap SSRF. Terapkan dengan kubectl apply -f network-policy.yaml.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-policy
spec:
  podSelector:
    matchLabels:
      app: internal-agent
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orchestrator
      ports:
        - port: 8000
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - port: 443
        - port: 8000

#Service Mesh untuk Komunikasi Antar Agent

Ketika jumlah agent bertambah, mengelola sertifikat dan observability secara manual jadi tidak masuk akal. Di sinilah service mesh berperan. Service mesh seperti Istio atau Linkerd menyediakan:

• mTLS otomatis antar pod, tanpa mengubah kode aplikasi.
• Traffic routing dan retry di sisi jaringan.
• Telemetry yang konsisten untuk seluruh agent.
• Authorization berbasis identity di level mesh.

Ilustrasi alur mTLS di service mesh:

orchestrator ──TLS──▶ Envoy sidecar ──mTLS──▶ Envoy sidecar ──TLS──▶ sales-agent
     │                                                              │
     └───── otel telemetry & access log diteruskan ke mesh ─────────┘

Karena A2A berjalan di atas HTTP, service mesh "tidak peduli" isi payload JSON-RPC. Ia hanya melihat trafik HTTP biasa, sehingga integrasi service mesh tidak memerlukan perubahan di kode agent sama sekali. Keuntungan terbesarnya: identity berbasis mTLS menggantikan pengecekan IP ad hoc, dan lalu lintas antar agent otomatis terenkripsi.

#Hardening 1: Rate Limiting

Agent publik wajib dibatasi laju request-nya, baik untuk mencegah penyalahgunaan maupun melindungi LLM backend dari biaya membengkak. Rate limiting bisa dilakukan di reverse proxy atau di middleware aplikasi.

Contoh di Nginx, membatasi 10 request per detik per client dengan burst kecil:

nginx.conf — rate limit endpoint A2A

limit_req_zone $binary_remote_addr zone=a2a:10m rate=10r/s;
 
server {
    listen 443 ssl;
    location / {
        limit_req zone=a2a burst=20 nodelay;
        proxy_pass http://a2a-agent:8000;
    }
}

#Hardening 2: Input Sanitization

Input dari agent lain tidak boleh dipercaya mentah-mentah. Sebuah Message A2A berisi teks yang pada akhirnya diteruskan ke LLM, path file, atau perintah shell. Langkah sanitasi yang wajib:

1. Validasi ukuran dan tipe payload — batasi panjang teks per part, jumlah part, dan ukuran total message agar tidak ada denial-of-service lewat message raksasa.
2. Validasi tipe part — pastikan file part hanya berisi mimeType yang diizinkan dan URL yang masuk allowlist, bukan skema file:// atau IP internal.
3. Bersihkan instruksi — saat menyusun ulang prompt untuk LLM, pisahkan dengan jelas antara instruksi sistem dan konten dari message, lalu escape delimiter agar agent jahat tidak bisa menyuntikkan instruksi.

Contoh validasi sederhana di Python:

sanitize.py — validasi input message

MAX_TEXT_LEN = 20_000
ALLOWED_MIME = {"text/plain", "application/json", "image/png"}
 
def validate_message(part):
    if part.kind == "text" and len(part.text) > MAX_TEXT_LEN:
        raise ValueError("text part too large")
    if part.kind == "file":
        if part.mimeType not in ALLOWED_MIME:
            raise ValueError("mime type not allowed")
        if part.uri.startswith(("file:", "http://10.", "http://169.254.")):
            raise ValueError("uri not allowed")
    return True

Ingat: sanitasi input di sini bukan pengganti autentikasi, melainkan lapisan pertahanan kedua jika autentikasi lolos atau jika partner ternyata tidak tepercaya.

#Hardening 3: Sandboxing Eksekusi Tool

Bagian paling berbahaya dari sebuah agent adalah tool execution: menjalankan shell, memproses file, atau melakukan aksi sistem. Ketika agent menerima task, eksekusi tool sebaiknya terjadi di lingkungan yang terisolasi, bukan di proses utama server.

Beberapa pendekatan sandboxing:

• Container sekali pakai — tool dijalankan di container yang dihancurkan setelah selesai, tanpa network, dan dengan resource limit.
• gVisor / microVM — sandbox dengan isolasi kernel untuk beban kerja yang lebih berbahaya.
• Seccomp / AppArmor — membatasi syscall yang boleh dipakai proses agent.

Contoh menjalankan tool dalam container tanpa network dan dengan limit ketat:

docker run --rm \
  --network none \
  --read-only \
  --memory 512m \
  --cpus 1 \
  --cap-drop ALL \
  --pids-limit 64 \
  sandbox-runner \
  python run_tool.py

Kombinasi ideal: sandbox untuk isolasi eksekusi, egress policy untuk membatasi network, dan rate limit sebagai pengaman biaya. Ketiganya bekerja bersama menciptakan pertahanan berlapis.

#Penutup

Pada episode ini kita membangun lapisan infrastruktur untuk jaringan multi-agent yang aman. Kita mengklasifikasikan agent menjadi pribadi dan publik dengan prinsip default-private, menegakkan pembatasan lalu lintas lewat ingress dan egress policy, menyerahkan mTLS dan observability ke service mesh, lalu memperkeras tiap agent dengan rate limiting, sanitasi input, dan sandboxing eksekusi tool.

Inti yang harus dibawa pulang:

• Default-private: sedikit mungkin agent yang terpapar publik, dan agent publik hanya menjadi pintu menuju agent internal.
• Egress policy adalah pertahanan pertama terhadap SSRF dan prompt injection yang mencoba mengakses jaringan internal.
• Service mesh memberikan mTLS, routing, dan telemetry tanpa mengubah kode agent.
• Rate limiting harus berbasis identitas agent, bukan sekadar IP, agar adil bagi partner di balik NAT.
• Tool execution wajib dijalankan di sandbox yang terisolasi dari data produksi.

Langkah-langkah ini sudah membuat jaringan lebih sulit diserang. Namun keamanan sejati lahir dari berpikir seperti penyerang — memetakan ancaman sebelum menambal satu per satu.

Di episode 14 selanjutnya kita akan membahas Threat Modeling & Vulnerability Awareness: ancaman seperti spoofing agent card, prompt injection via messages, kebocoran data antar tenant, dan SSRF, beserta mitigasi signed security cards, mTLS/TLS, allowlist partner, dan audit trail. Sampai jumpa!