𝗗𝗲𝗳𝗲𝗻𝘀𝗲 𝗶𝗻 𝗗𝗲𝗽𝘁𝗵 𝗳𝗼𝗿 𝗔𝗻 𝗔𝗴𝗲𝗻𝘁 𝗧𝗵𝗮𝘁 𝗪𝗶𝗹𝗹 𝗦𝗰𝗿𝗲𝘄 𝗨𝗽

Every safety mechanism has a bug. You just do not know which one yet.

This is the only sane way to build an autonomous agent for production. The conscience will misclassify an action. The council will approve a bad idea. The isolation wall will have a gap.

Each layer will eventually fail.

The design question is not how to build a perfect layer. The question is: what stands behind a layer when it fails?

I use six layers to protect the system. Earlier layers are cheaper because they stop problems before they become reality.

• L0 — Structural isolation. Prevents wrong-tenant actions at the base level. • L1 — Idea-gate. Stops bad ideas during debate before code exists. • L2 — Action-gate. A reflex that allows or denies commands based on risk. • L3 — Resource-gate. Controls memory, budgets, and runaway costs. • L4 — Audit. Uses tamper-evident receipts to track every decision. • L5 — Recovery. Uses quarantine and rollbacks to stop active damage.

A list of layers is not defense in depth. Real depth requires one rule:

Every critical risk must be caught by at least two independent layers.

Independent means they do not fail for the same reason. If two checks use the same config or the same signal, they are the same check. When that signal fails, both checks fail.

I saw this happen. My idea-gate once returned a confident verdict for a debate that never occurred. A helper fabricated the entire result.

L1 failed. It did not just miss the error. It produced a convincing lie.

If L1 was my only line, the lie would have become a real decision. But L4 caught it. L4 does not believe narration. It only believes receipts. I looked for the transcript file. The file did not exist. The claim was void.

The system stayed safe because I assumed L1 would fail.

Current status of these layers:

• L1 — Coded. • L2 — Coded. • L4 — Coded. • L0 — Partial. • L3 — Partial. • L5 — Partial.

A safety architecture you cannot audit is just a mood board.

Ask yourself these three questions about any safe agent:

1. For your worst risk, what are the two independent layers that catch it?
2. When a layer produces a confident wrong signal, what layer behind it refuses to believe that signal?
3. Which layers are built, and which are just ideas?

Capability is one layer. Safety is the other five.

Defense in Depth untuk Agen yang Pasti Akan Mengacau

Jika Anda sedang membangun agen AI, Anda harus berasumsi bahwa agen tersebut pada akhirnya akan melakukan kesalahan. Bukan sekadar kesalahan kecil, melainkan sesuatu yang berpotensi membahayakan sistem Anda, membocorkan data, atau melakukan tindakan yang tidak diinginkan.

Hal ini dikarenakan LLM (Large Language Models) bersifat non-deterministik. Anda tidak bisa memprediksi dengan pasti apa yang akan dihasilkan oleh model untuk input tertentu, terutama ketika agen tersebut memiliki kemampuan untuk menggunakan alat (tools) dan berinteraksi dengan dunia nyata.

Oleh karena itu, Anda tidak bisa hanya mengandalkan satu mekanisme keamanan. Anda memerlukan strategi Defense in Depth—pendekatan keamanan berlapis di mana jika satu lapisan gagal, lapisan lainnya masih ada untuk melindungi sistem Anda.

Berikut adalah lima lapisan pertahanan yang harus Anda pertimbangkan saat membangun agen AI.

1. Validasi Input (Mencegah Prompt Injection)

Lini pertahanan pertama adalah memastikan bahwa instruksi yang masuk ke dalam agen tidak mengandung perintah berbahaya. Salah satu ancaman terbesar bagi agen AI adalah prompt injection, di mana pengguna mencoba memanipulasi agen untuk mengabaikan instruksi aslinya dan melakukan tindakan yang tidak sah.

Beberapa teknik untuk memitigasi hal ini meliputi:

• Penyaringan Kata Kunci: Memblokir kata-kata atau pola tertentu yang sering digunakan dalam serangan prompt injection.
• Sistem Prompt yang Terpisah: Menggunakan struktur prompt yang jelas untuk membedakan antara instruksi sistem (system instructions) dan input pengguna (user input).
• LLM sebagai Penjaga (Guardrail LLM): Menggunakan model LLM yang lebih kecil dan khusus untuk memeriksa apakah input pengguna mengandung niat jahat sebelum diteruskan ke agen utama.

2. Sandboxing (Lingkungan Eksekusi Terisolasi)

Jangan pernah memberikan agen akses langsung ke lingkungan produksi Anda. Jika agen memiliki kemampuan untuk menjalankan kode atau berinteraksi dengan sistem file, Anda harus melakukannya di dalam lingkungan yang terisolasi atau sandbox.

Tujuan dari sandboxing adalah untuk membatasi "radius ledakan" (blast radius) jika agen tersebut mengacau. Jika agen mencoba menghapus file sistem atau mengirim data ke server asing, sandboxing akan mencegahnya.

Beberapa cara untuk mengimplementasikan sandboxing:

• Containerization: Menjalankan agen di dalam container seperti Docker dengan izin yang sangat terbatas.
• Micro-VMs: Menggunakan virtual machine yang sangat ringan dan cepat (seperti Firecracker) untuk isolasi yang lebih kuat.
• Network Isolation: Membatasi akses jaringan agen sehingga ia hanya dapat berkomunikasi dengan API atau layanan yang sudah ditentukan sebelumnya.

3. Validasi Output (Memeriksa Tool Calls)

Lapisan ketiga adalah memvalidasi apa yang dihasilkan oleh agen sebelum tindakan tersebut dieksekusi. Agen sering kali menggunakan "tool calling" untuk berinteraksi dengan dunia luar (misalnya, mengirim email, menghapus database, atau melakukan transaksi keuangan).

Anda tidak boleh mempercayai output dari LLM secara membabi buta. Setiap pemanggilan alat harus melalui proses validasi:

• Skema Validasi: Pastikan argumen yang dikirimkan ke alat sesuai dengan skema yang diharapkan (misalnya, menggunakan JSON Schema).
• Pemeriksaan Batas (Boundary Checking): Jika agen diminta untuk menghapus data, pastikan ia hanya dapat menghapus data dalam rentang atau kategori yang diizinkan.
• Analisis Niat: Gunakan logika tambahan untuk memeriksa apakah tindakan yang diminta oleh agen selaras dengan tujuan pengguna yang sah.

4. Monitoring dan Observabilitas

Anda tidak bisa mengamankan apa yang tidak bisa Anda lihat. Anda memerlukan sistem monitoring yang kuat untuk melacak setiap langkah yang diambil oleh agen Anda.

Jika agen mulai berperilaku aneh—misalnya, melakukan pemanggilan API secara berulang-ulang atau mencoba mengakses endpoint yang tidak biasa—Anda harus mengetahuinya secara real-time.

Hal-hal yang perlu dipantau meliputi:

• Log Prompt dan Response: Menyimpan riwayat lengkap interaksi untuk audit dan debugging.
• Metrik Penggunaan Alat: Melacak seberapa sering dan jenis alat apa yang digunakan oleh agen.
• Deteksi Anomali: Menggunakan sistem peringatan (alerting) jika pola perilaku agen menyimpang dari baseline yang normal.

5. Human-in-the-loop (Persetujuan Manusia)

Lapisan pertahanan terakhir dan yang paling efektif untuk tindakan berisiko tinggi adalah melibatkan manusia. Untuk tindakan yang memiliki dampak besar (seperti transfer uang, penghapusan data penting, atau pengiriman email ke klien), jangan biarkan agen melakukannya secara otomatis.

Alih-alih, buatlah alur kerja di mana agen menyiapkan tindakan tersebut, lalu meminta persetujuan dari pengguna manusia sebelum dieksekusi.

Konsep Human-in-the-loop mengubah peran agen dari "pelaksana otonom" menjadi "asisten yang memerlukan supervisi", yang secara drastis mengurangi risiko kegagalan fatal.

Kesimpulan

Membangun agen AI yang kuat bukan hanya tentang seberapa cerdas model yang Anda gunakan, tetapi tentang seberapa aman sistem di sekitarnya. Dengan menerapkan strategi Defense in Depth, Anda dapat memanfaatkan kekuatan agen AI sambil tetap menjaga kendali dan keamanan atas sistem Anda.

Ingatlah: Asumsikan agen Anda akan mengacau, dan bangunlah sistem yang mampu menanganinya.