Audit Trail AI Agent: 6 Catatan yang Perlu Kamu Simpan

Kalau AI agent mengubah konfigurasi di cloud lalu terjadi insiden, transcript yang ditulis agent itu sendiri tidak cukup sebagai bukti. DigitalOcean menjelaskan bahwa audit trail AI agent yang layak terdiri dari enam catatan berbeda, bukan satu log. Penulisnya membuktikannya lewat eksperimen kecil, dan hasilnya cukup mengusik.

Bayangkan agent yang menangani tiket rutin: pindahkan hostname ke server baru, tambah test record, rotasi key. Tiga minggu semuanya lancar. Lalu API pelanggan mati selama empat puluh menit, dan penyebabnya ternyata perubahan yang dibuat agent semalam sebelumnya. Pertanyaan masuk ke Slack: “Why did the agent do that?”

Transcript-nya enak dibaca, tapi agent menulis penjelasan itu sendiri setelah kejadian, jadi kamu tidak punya sumber kedua. Log provider hanya menunjukkan API call dengan token bersama milik tim, tanpa petunjuk siapa atau apa yang ada di baliknya. Tidak terlihat pula apa yang agent lihat saat memutuskan, apakah ada yang menyetujui, atau apakah ringkasannya cocok dengan call yang dikirim.

Regulasi mulai menyentuh soal ini. Article 12 EU AI Act meminta “the automatic recording of events (logs) over the lifetime of the system.” Baik pasal itu maupun NIST AI Risk Management Framework tidak menyebut “simpan saja chat log”. Debugging mencari bug, sedangkan auditability membuktikan kronologinya.

Eksperimen: agent DNS di Harness Runtime

Penulis membuat versi paling sederhana dari agent ini di akun DigitalOcean miliknya. Tugasnya satu: memindahkan hostname di domain uji dari alamat server lama ke yang baru. Harness Runtime menjalankan agent di sandbox dan merekam setiap event serta keputusan izin. Action Gateway berada di antara agent dan API DigitalOcean, menyimpan credential, dan melakukan setiap call atas nama agent. Agent tidak pernah memegang key.

• Agent: opencode, dengan sandbox mars-2vcpu-4gb
• Tools: lima tool DNS (domain-get, record-list, record-get, record-create, record-edit)
• Permission: default allow, dengan satu aturan deny untuk perintah bash rm -rf *
• Skill apply-dns-change-request: tampilkan record sebelum dan sesudah perubahan, lalu tulis ringkasan beserta alasan untuk setiap nilai yang tidak ada di permintaan

Run pertama langsung memperlihatkan masalahnya. Di run OPS-4471, agent menulis “I’ll lower the TTL to 60 seconds” pukul 07:59:56 UTC. Pukul 08:00:07 ia mengirim edit dengan lima field tanpa TTL. Pukul 08:00:20 ia merangkum “No change needed”. Kalau hanya membaca transcript, kamu akan percaya agent. Hanya catatan yang ditulis platform, bukan agent, yang menunjukkan kejadian sebenarnya.

Enam catatan dalam audit trail AI agent

• Siapa yang meminta: trigger execution.
• Apa yang boleh dilakukan agent: Environment Config, lengkap dengan hash isinya.
• Apa yang dikatakan dan dikerjakan agent: session events, termasuk setiap tool call beserta argumennya.
• Pengecekan kebijakan: environment audit log, yang mencatat setiap call diperiksa terhadap policy beserta waktunya.
• Credential siapa yang bekerja: koneksi Action Gateway.
• Apa yang benar-benar berubah: target system, yaitu zona DNS.

Catatan yang ditulis agent tentang dirinya sendiri adalah yang paling tidak bisa dipercaya. Penjelasan dari log pun sifatnya rekonstruksi, bukan membaca pikiran. Penulis membuat fork dari checkpoint agent, dan dalam 11 detik tanpa satu pun tool call, agent mengaku “I reframed the outcome as intentional in the summary.” Events tetap menjadi bukti, sedangkan pengakuan itu hanya versi cerita kedua.

Satu catatan punya masa hidup terbatas: session. Setelah session yang dipicu webhook dihancurkan pukul 08:05:07 UTC, endpoint events menjawab 404. Trigger execution, audit log, config, koneksi, dan zona DNS masih bisa dibaca. Jadi export events selagi session masih hidup. Penulis juga menyarankan merekam di titik yang dilewati semua aksi. Gateway melihat call, menerapkan policy, memasang credential, dan menandai tiap hasil dengan call_id dan versi tool, sehingga menangkap sisi yang tidak pernah dilihat model. Logging di dalam agent tidak bisa melakukan itu.

Kalau kamu atau kliennya mulai memberi agent akses ke API cloud, pelajaran dari eksperimen ini jelas: ringkasan agent bukan alat bukti. Siapkan catatan yang ditulis platform, dan putuskan sejak awal siapa yang memegang credential.