Cara Mendesain Allowlist Action untuk AI Agent

Kalimat “agent hanya boleh melakukan hal yang aman” terdengar bagus di dokumen produk.

Masalahnya: apa definisi aman?

Kalau jawabannya diserahkan ke model setiap kali, kita belum punya policy.

Kita punya opini probabilistik.

Allowlist action mengambil pendekatan berbeda.

Daripada memberi agent ruang tindakan luas lalu mencoba mendeteksi yang berbahaya, kita menentukan lebih dulu action apa yang memang diizinkan, dalam kondisi apa, dengan parameter seperti apa, dan kapan manusia harus masuk.

Ini bukan konsep baru.

Firewall, API gateway, IAM, dan application security sudah lama memakai logika deny-by-default untuk area sensitif.

Agentic AI membuat konsep itu relevan lagi karena model mulai mengorkestrasi tindakan lintas sistem.

Dari “Bisa” Menjadi “Boleh”

Model mungkin bisa menyusun request untuk menghapus record.

Tetapi apakah boleh?

Model mungkin bisa menemukan endpoint transfer.

Tetapi apakah boleh?

Model mungkin bisa mengirim email.

Tetapi kepada siapa?

Security perlu memisahkan capability dan authority.

Allowlist adalah daftar action yang secara eksplisit tersedia untuk agent sesuai role dan context.

Yang tidak ada di daftar dianggap tidak diizinkan.

Bukan “mungkin aman”.

Bukan “coba tanya model”.

Tidak diizinkan.

Mulai dari Business Action, Bukan API Primitive

Kesalahan desain umum adalah memberi agent tool terlalu generik.

`execute_sql`
`call_api`
`run_shell`
`send_http_request`

Tool seperti ini powerful.

Tetapi policy sulit dibuat.

Lebih sehat membuat tool berdasarkan business action:

`create_support_draft`
`check_order_status`
`request_refund_approval`
`schedule_meeting`
`get_inventory`
`create_purchase_request`

Action jadi lebih mudah dipahami, diuji, dan diaudit.

Log “request_refund_approval” punya arti bisnis.

Log “POST /v2/endpoint” tidak langsung memberi konteks.

Narrow tool design juga mengurangi kemungkinan model mengkombinasikan primitive menjadi behavior yang tidak pernah direncanakan.

Allowlist Harus Parameter-Aware

Tool `send_email` mungkin ada di allowlist.

Tetapi tidak berarti semua email boleh.

Policy perlu melihat parameter:

recipient,
domain,
jumlah recipient,
attachment,
classification,
template,
sender identity.

Contoh rule:

boleh mengirim internal email otomatis maksimal lima penerima,
external email hanya draft,
attachment sensitif dilarang,
bulk send lebih dari 20 penerima butuh approval.

Ini lebih kuat daripada boolean “send_email allowed”.

Hal yang sama untuk payment:

currency,
amount,
recipient,
account,
country,
transaction type.

Action allowlist tanpa parameter constraint masih terlalu kasar.

Context Membuat Action yang Sama Punya Risiko Berbeda

Menghapus draft mungkin low risk.

Menghapus production data high risk.

Mengirim pesan ke diri sendiri berbeda dari mengirim ke seluruh database pelanggan.

Download public PDF berbeda dari export customer table.

Jadi allowlist bisa mempertimbangkan:

user role,
resource,
environment,
tenant,
amount,
sensitivity,
time,
location,
authentication strength,
dan recent approval.

Policy modern cenderung berbentuk:

boleh action A jika condition B, C, dan D.

Bukan hanya:

boleh action A.

Policy juga perlu punya lifecycle. Siapa owner-nya, kapan rule mulai berlaku, kapan terakhir direview, dan apa yang terjadi saat dependency berubah?

Misalnya agent diizinkan mengirim dokumen ke vendor tertentu. Enam bulan kemudian kontrak vendor berhenti, tetapi domain masih berada di allowlist. Secara teknis action tetap lolos. Secara bisnis sudah tidak sah.

Artinya allowlist bukan konfigurasi sekali jadi.

Ia perlu review, expiry untuk entry tertentu, change approval, dan audit terhadap permission yang tidak pernah lagi digunakan.

Inactive permission sering menjadi privilege debt. Tidak terlihat saat sistem berjalan normal, tetapi memberi attacker jalur tambahan ketika account atau workflow lain berhasil dikompromikan.

Deny by Default Mengurangi Surprise

Agent sering menghadapi situasi yang developer tidak prediksi.

Kalau rule adalah “semua boleh kecuali yang diblok”, daftar deny harus selalu mengejar behavior baru.

Allowlist membalik logika.

Agent hanya punya action yang sengaja disediakan.

Unknown action gagal tertutup.

Untuk sistem berisiko tinggi, fail closed lebih sehat.

Kalau model mencoba tool baru yang belum disetujui, runtime menolak.

Ini membuat perubahan capability menjadi explicit governance event.

Tool baru tidak otomatis masuk production hanya karena developer menambah endpoint.

Pisahkan Read dan Write

Banyak workflow bisa dimulai read-only.

Agent membaca status.
Meringkas.
Membandingkan.
Membuat rekomendasi.

Baru setelah value terbukti, tambahkan write action.

Ini mengurangi blast radius fase awal.

Read juga perlu permission, terutama untuk data sensitif.

Tetapi write action umumnya membawa consequence yang lebih langsung.

Maka tool design sebaiknya eksplisit:

`get_customer`
bukan `customer_admin`.

`draft_invoice`
bukan `invoice_manage`.

`propose_permission_change`
bukan `set_permission`.

Nama tool bukan security control.

Tetapi naming membantu menjaga mental model yang benar.

High-Risk Action Butuh Gate Tambahan

Tidak semua allowed action harus auto-execute.

Allowlist menentukan apakah action masuk ruang yang mungkin.

Approval menentukan apakah action tertentu boleh dilakukan sekarang.

Contoh:

Refund sampai Rp500.000 bisa otomatis jika rule lengkap.

Refund di atas itu perlu approval.

Delete file boleh dilakukan ke recycle bin.

Permanent delete butuh confirmation.

Publish ke staging otomatis.

Publish ke production butuh human approval.

OpenAI pada 2026 menekankan pembatasan risky actions dan sensitive data exposure dalam desain agent tahan prompt injection.

Ini relevan karena allowlist membuat serangan yang berhasil memanipulasi model tetap bertemu boundary berikutnya.

Agent mungkin ingin melakukan sesuatu.

Runtime tetap bisa bilang tidak.

Action Sequence Juga Perlu Dilihat

Masing-masing action bisa terlihat aman.

Urutannya bisa berbahaya.

Contoh:

read confidential file,
create external draft,
attach file,
send.

Kalau setiap step dianalisis terpisah, mungkin lolos.

Sebagai chain, terlihat seperti exfiltration.

Microsoft mendokumentasikan tool chain analysis sebagai salah satu pendekatan untuk melihat urutan tool yang berisiko dalam agent systems.

Allowlist yang matang dapat menambahkan sequence rule.

Misalnya:

data classified internal tidak boleh menjadi input untuk external send action.

Ini bentuk information flow control.

Sangat penting ketika agent melakukan multi-step workflow.

Allowlist Data Destination

Action bukan hanya “apa”.

Juga “ke mana”.

Untuk browser agent, domain destination perlu dibatasi.

Untuk file, folder destination.

Untuk message, recipient.

Untuk API, host.

Untuk payment, beneficiary.

Sistem bisa punya allowlist destination:

approved vendor domains,
corporate SaaS,
known payment provider,
internal workspace.

Unknown destination dapat memicu confirmation atau denial.

Ini efektif melawan prompt injection yang mencoba mengarahkan data ke endpoint baru.

Rate Limit dan Budget Adalah Bagian dari Allowlist

Agent yang punya action sah tetap bisa membuat damage jika mengulang terlalu banyak.

Kirim satu email aman.

Kirim 100 ribu email mungkin tidak.

Refund satu transaksi sesuai policy.

Refund ribuan dalam satu jam mencurigakan.

Tambahkan:

rate limit,
daily limit,
spending limit,
recipient limit,
concurrency limit.

Ini membuat policy mempertimbangkan volume.

Agentic automation mempercepat kerja.

Security perlu memastikan ia tidak mempercepat kesalahan pada skala yang sama.

Authentication dan Delegation

Allowlist harus terkait identity.

Agent bekerja atas nama siapa?

User tertentu?

Service account?

Team?

Organization?

Action yang diizinkan untuk finance manager belum tentu boleh untuk intern.

Kalau semua agent memakai satu superuser credential, allowlist di application layer bisa kehilangan fondasi identity yang kuat.

Delegated authorization lebih sehat.

Agent menerima scope sesuai user atau workflow.

Jika perlu elevation, ada explicit approval.

Identity tidak boleh hilang hanya karena interface berubah menjadi natural language.

Action Contract Harus Deterministik

Setiap tool sebaiknya punya schema dan validation ketat.

Enum.
Range.
Required fields.
Allowed format.
Resource ID.
Tenant ID.

Model tidak boleh mengirim parameter arbitrer lalu backend “mencoba mengerti”.

Semakin deterministik contract, semakin mudah security testing.

Contoh:

`issue_credit(amount, order_id, reason_code)`

lebih aman daripada:

`execute_customer_action(action_text)`.

Natural language bagus untuk user interface.

Backend authorization perlu struktur.

Preview sebelum Commit

Untuk action yang reversible atau meaningful, gunakan two-step flow.

Prepare.
Preview.
Commit.

Agent membuat candidate action.

System menampilkan konsekuensi.

User atau policy approve.

Baru commit.

Ini memberi ruang menangkap kesalahan parameter.

“Transfer Rp1.250.000 ke Vendor A” lebih mudah diperiksa daripada “lanjutkan transaksi”.

Preview bukan sekadar UX.

Ia security control.

Logging Harus Mencatat Policy Decision

Jangan hanya log tool call.

Log:

siapa meminta,
agent mana,
action,
parameter,
policy yang mengevaluasi,
hasil allow atau deny,
approval,
execution result.

Kalau action ditolak, itu juga valuable data.

Banyak deny pada action yang sama bisa menunjukkan:

prompt injection,
bug,
tool misuse,
atau policy terlalu ketat.

Observability membantu menyeimbangkan keamanan dan usability.

Test Allowlist dengan Model yang Sengaja “Nakal”

Jangan hanya test normal workflow.

Buat model mencoba:

action di luar daftar,
parameter di luar range,
cross-tenant resource,
unknown domain,
amount lebih besar,
bulk operation,
sequence exfiltration,
bypass confirmation,
dan repeated calls.

Kemudian lihat runtime.

Security berhasil jika runtime menolak walaupun model terus mencoba.

Ini penting.

Prompt engineering boleh gagal.

Policy seharusnya tetap bertahan.

Checklist Allowlist Action

Saat mendesain agent:

Apakah default-nya deny?
Apakah tool berbasis business action?
Apakah read dan write dipisah?
Apakah parameter divalidasi?
Apakah destination dibatasi?
Apakah tenant dan resource dicek?
Apakah high-risk action butuh approval?
Apakah sequence action dianalisis?
Apakah rate dan spending limit ada?
Apakah credential least privilege?
Apakah preview tersedia?
Apakah policy decision tercatat?
Apakah unknown tool selalu ditolak?
Apakah system aman jika model mengikuti malicious instruction?

Kalau allowlist hanya berupa daftar nama tool, belum cukup.

Allowlist Adalah Cara Mengubah Autonomy Menjadi Ruang yang Bisa Dipertanggungjawabkan

Tujuan agent bukan membuat software bebas aturan.

Tujuannya memberi software kemampuan menyelesaikan goal dengan lebih fleksibel.

Fleksibilitas itu tetap membutuhkan boundary.

Model boleh merencanakan dalam ruang yang luas.

Execution sebaiknya terjadi di ruang yang jauh lebih sempit dan eksplisit.

Ini bukan kontradiksi.

Justru desain seperti ini memungkinkan organisasi memberi agent tanggung jawab lebih besar secara bertahap.

Mulai read-only.

Tambah draft.

Tambah reversible action.

Tambah limited write.

Tambah high-risk action dengan approval.

Setiap tahap punya bukti, metric, dan control.

Autonomy yang sehat bukan binary.

Ia bertingkat.

Allowlist membuat tingkat itu dapat dikodekan.

Ketika prompt injection, hallucination, atau misunderstanding terjadi, model mungkin mengusulkan action yang salah.

Tetapi proposal tidak harus menjadi eksekusi.

Di situlah allowlist bekerja.

Ia tidak mencoba membuat model sempurna.

Ia memastikan ketidaksempurnaan model tidak otomatis berubah menjadi consequence yang tidak dibatasi.