Guardrails untuk Membatasi Tindakan AI Agent

Apa Itu Guardrails pada AI Agent?

Guardrails AI agent adalah kontrol berlapis yang menentukan apa yang dapat dilihat, dipilih, dijalankan, dan diubah oleh agent serta apa yang terjadi ketika perilakunya menyimpang. Guardrails bukan satu prompt, filter, atau approval. Ia mencakup capability, permission, validation, environment, monitoring, dan recovery.

Semakin besar kemampuan agent mengubah state, semakin besar konsekuensi ketika model salah, instruction ambigu, tool gagal, atau data eksternal berbahaya. Tujuan guardrails bukan menjamin agent tidak pernah salah, tetapi memperkecil peluang, blast radius, dan waktu pemulihan.

Mulai dari Risiko Excessive Agency

OWASP mendefinisikan excessive agency sebagai kondisi ketika aplikasi LLM dapat melakukan tindakan merugikan akibat functionality, permission, atau autonomy berlebihan. Ketiganya perlu diaudit sendiri.

Excessive functionality

Agent memiliki tool atau fungsi yang tidak dibutuhkan. Sistem yang hanya merangkum email tidak perlu kemampuan mengirim atau menghapus email.

Excessive permission

Tool yang diperlukan memakai credential terlalu kuat. Agent mungkin hanya butuh membaca satu tabel, tetapi koneksinya memiliki izin update dan delete ke seluruh database.

Excessive autonomy

Tindakan berdampak tinggi dapat dijalankan tanpa validation atau authorization independen. Capability dan permission mungkin dibutuhkan, tetapi eksekusinya seharusnya berhenti pada checkpoint.

Mematikan satu tool belum cukup bila tool lain bersifat open-ended. Audit perlu memetakan tindakan nyata yang mungkin dilakukan melalui setiap jalur.

1. Guardrails pada Scope dan Capability

Definisikan tujuan, objek, serta kondisi selesai secara sempit. Berikan hanya tools yang dibutuhkan untuk task tersebut.

Lebih aman menyediakan get_campaign_report daripada shell atau generic HTTP client yang dapat mengakses banyak resource. Tool granular memiliki contract yang dapat diuji: input, output, error, side effect, dan batasnya.

Pisahkan:

• read untuk mengambil informasi;
• draft untuk menyiapkan perubahan tanpa mengeksekusi;
• write untuk mengubah state;
• execute untuk menjalankan proses;
• destructive atau financial action untuk dampak khusus.

NIST menjelaskan bahwa tool use dalam agent systems memperluas tindakan di luar output text dan memerlukan komunikasi capability serta limitation yang jelas.

2. Guardrails pada Identity dan Permission

Agent bertindak menggunakan identity. Gunakan least privilege dan pertahankan konteks user yang meminta tindakan.

• Hindari shared administrator credential.
• Gunakan OAuth scope atau service role minimum.
• Batasi resource, tenant, row, folder, account, dan action.
• Pisahkan credential read dan write.
• Beri masa berlaku serta rotation yang sesuai.
• Jangan masukkan secret ke prompt atau log.

Authorization perlu diperiksa pada setiap execution oleh downstream system. Model dapat mengusulkan tool call, tetapi tidak boleh menetapkan sendiri bahwa user berhak menjalankannya.

3. Validasi sebelum dan setelah Tindakan

Sebelum execution, periksa:

• schema dan tipe parameter;
• allowlist target serta domain;
• jumlah, currency, batas biaya, dan business rule;
• current state agar action masih relevan;
• duplicate atau idempotency key;
• conflict dengan policy;
• kebutuhan approval.

Setelah execution, verifikasi state pada environment. Respons tool “success” atau klaim model belum tentu membuktikan perubahan yang benar. Periksa target, jumlah record, status, dan side effect.

Untuk tindakan yang dapat dibalik, siapkan preview, versioning, soft delete, atau rollback. Untuk yang tidak reversibel, naikkan standar authorization serta test.

4. Batasi Autonomy dan Resource

Agent loop perlu stopping condition dan budget:

• maximum steps dan retries;
• timeout;
• rate limit;
• token atau cost budget;
• jumlah record atau recipient;
• concurrency;
• circuit breaker;
• kill switch.

Batas tersebut mencegah satu error berkembang menjadi ribuan tindakan atau biaya besar. Gunakan human-in-the-loop pada boundary risiko, bukan sebagai persetujuan rutin setiap reasoning step.

5. Perlakukan Konten Eksternal sebagai Data

Email, website, document, ticket, dan tool output dapat memuat instruction yang mencoba mengalihkan agent. Prompt injection muncul karena natural-language instruction dan data diproses dalam context yang sama.

Mitigasi bersifat defense in depth:

• pisahkan system instruction, user request, dan external content;
• tandai provenance serta trust level;
• abaikan instruction dari source yang tidak berwenang;
• sanitasi format dan validate link atau attachment;
• batasi tool berdasarkan task, bukan isi dokumen;
• minta approval untuk high-impact action;
• uji indirect prompt injection.

OWASP Prompt Injection Prevention Cheat Sheet menekankan validation, least privilege, monitoring, serta human approval untuk tindakan destruktif sebagai lapisan yang saling melengkapi.

Tidak ada kalimat system prompt yang dapat menggantikan permission boundary.

6. Gunakan Isolation dan Containment

Jalankan code, browser, file processing, atau tool berisiko dalam environment terbatas. Batasi filesystem, network egress, process, credential, dan resource yang dapat dijangkau.

Containment mengurangi blast radius ketika pencegahan probabilistik gagal. Sandbox tetap membutuhkan konfigurasi, monitoring, patch, serta batas keluar yang benar. Ia bukan label keamanan otomatis.

Untuk data sensitif, pisahkan tenant dan environment. Pastikan artifact, cache, memory, dan log tidak bocor antar-user atau task.

7. Observability, Evaluation, dan Incident Response

Simpan audit trail yang cukup:

• requester dan authority;
• objective serta policy version;
• model, tools, dan permission;
• tool call, argument yang aman dicatat, serta result;
• approval atau override;
• state sebelum dan sesudah;
• latency, cost, error, retry, dan escalation.

Hindari mencatat credential atau personal data tanpa kebutuhan. Log harus membantu investigasi tanpa menciptakan kebocoran baru.

Uji success path dan failure mode: request ambigu, tool unavailable, malicious document, target salah, duplicate action, timeout, interrupted process, serta rollback. Pillar arsitektur AI agent menjelaskan bahwa evaluasi perlu memeriksa outcome, trajectory, dan impact.

Siapkan incident procedure: stop agent, revoke credential, isolate environment, preserve evidence, assess affected state, recover, notify owner, dan perbarui evaluation suite.

Checklist Minimum sebelum Agent Mendapat Write Access

• Objective dan prohibited actions terdokumentasi.
• Tool minimum serta permission minimum diterapkan.
• User authorization diperiksa downstream.
• Parameter dan business rule divalidasi.
• Preview dan approval tersedia untuk high-impact action.
• Step, rate, cost, dan scope dibatasi.
• Outcome diverifikasi pada environment.
• Audit trail, rollback, kill switch, dan incident owner tersedia.
• Adversarial serta regression test dijalankan.

Jika satu outcome belum dapat diverifikasi, pertahankan agent pada read-only atau draft mode.

Pertanyaan Umum

Apakah system prompt termasuk guardrail?

Ya, tetapi hanya satu lapisan probabilistik. Permission, authorization, validation, dan isolation harus ditegakkan di luar model.

Apakah approval manusia membuat write access aman?

Tidak otomatis. Reviewer dapat salah atau mengalami fatigue. Approval memerlukan preview yang jelas serta tetap dibatasi policy dan permission.

Apakah guardrails menghilangkan semua risiko?

Tidak. Guardrails mengurangi kemungkinan dan dampak serta mempercepat deteksi dan recovery. Risiko residual tetap perlu diterima, dialihkan, atau use case dihentikan.

Kesimpulan

Guardrails AI agent bekerja ketika kontrol ditempatkan di seluruh jalur dari objective hingga recovery. Batasi capability, permission, autonomy, data, environment, dan dampak; jangan menyerahkan enforcement kepada model.

Mulailah dengan read-only, outcome yang dapat diuji, serta blast radius kecil. Tambahkan kewenangan setelah evaluation membuktikan manfaatnya dan organisasi siap menangani kegagalan.