Skip to content
⚡ TENVO AI · LANGSUNG · v0.16.26 · TLS · Sertifikat per-perangkat · AGPL-3.0 · TINGKAT GRATIS · 30 PERANGKAT · INFRA HOSTING MANDIRI · GUNAKAN API KEY SENDIRI · MCP UNTUK CLAUDE & CURSOR
Kembali ke BlogEnterprise

log audit agen AI: apa yang harus dicatat

Tenvo Editorial Team9 menit baca
log audit agen AI: apa yang harus dicatat

Ketika aktor adalah agen otonom — bukan manusia — bidang audit biasa (username, IP, timestamp) tidak lagi cukup; Anda perlu merekam model, prompt, panggilan alat, seed keacakan, versi kode, dan siapa yang mendelegasikan otoritas.

Ketika agen otonom — bukan manusia — yang bertindak, bidang audit biasa (username, IP, timestamp) tidak lagi cukup. Anda tetap membutuhkan akuntabilitas, reproduktibilitas dan non-repudiation, tetapi catatan yang Anda simpan harus menangkap sekumpulan atribut yang berbeda: model, prompt, pemanggilan alat, seed keacakan, versi kode, dan manusia yang mendelegasikan otoritas. Artikel ini mencantumkan bidang yang harus ada pada log audit agen AI dan alasan mengapa masing‑masing diperlukan untuk keamanan, kepatuhan, dan respons insiden.

Mengapa bidang "pengguna" biasa gagal untuk agen AI

Log audit tradisional mengasumsikan satu aktor manusia di balik sebuah sesi: username, peran, IP, user agent string, dan deskripsi aksi. Itu berguna, tetapi melewatkan atribut yang khas untuk perilaku yang digerakkan AI:

  • Non-determinism: prompt dan konfigurasi model yang sama bisa menghasilkan keluaran berbeda kecuali Anda merekam sumber keacakan (seed, algoritma rand, temperature).
  • Multi-step chains: agen sering memanggil alat, API dan agen lain; Anda membutuhkan rantai kausal, bukan hanya satu entri aksi.
  • Evolving code and models: agen adalah kode + model + runtime. Sebuah username tidak memberi tahu Anda checkpoint model, container image digest atau kebijakan agen yang dipakai.
  • Delegation and approval: agen bisa bertindak atas nama manusia atau sistem lain; jejak audit harus menunjukkan siapa yang memberi otorisasi agen dan batasan apa yang diterapkan.

Singkatnya: gantikan model mental "seseorang menekan tombol" dengan "sebuah komputasi yang dapat direproduksi mengubah input menjadi output dan melakukan efek samping".

Bidang minimum yang harus dimiliki log audit agen AI

Perlakukan setiap entri log sebagai rekaman sebuah komputasi dan efek sampingnya. Setidaknya sertakan bidang‑bidang ini; jika lingkungan Anda memiliki kebutuhan hukum atau operasional, tambahkan item relevan (contoh dan alasan di bawah).

  • record_id — sebuah UUID stabil untuk entri audit (v4 atau v7) dan nomor urut untuk sesi.
  • timestamp — RFC3339 UTC; sertakan nomor urut monotonik untuk mendeteksi pengurutan ulang.
  • agent_id — pengidentifikasi logis untuk instance agen (bukan hanya pemilik manusia).
  • agent_version — commit hash, container image digest (mis. sha256:...) atau versi paket dari kode agen.
  • model_name & model_digest — pengidentifikasi model ditambah digest atau checksum dari bobot/checkpoint yang digunakan (atau string versi hosted-model).
  • runtime_config — parameter model: temperature, top_k/top_p, max_tokens, batas konkurensi, dan algoritma RNG.
  • prompt_template_id & prompt_hash — pengidentifikasi template prompt dan hash dari prompt yang telah di-resolve untuk menghindari menyimpan plaintext jika itu sensitif.
  • input_artifacts — referensi (URI) ke lampiran, file, atau data eksternal yang digunakan beserta checksum.
  • actions — daftar berurutan aksi yang dieksekusi agen, dengan timestamp, pengidentifikasi alat dan hasil (nama alat, versi, exit code, hash data yang dikembalikan).
  • external_calls — setiap panggilan API keluar dengan destinasi, host URL, request hash, response hash, dan latensi.
  • human_principal — siapa yang membuat/menyetujui agen atau permintaan (user id, peran, dan pernyataan delegasi).
  • authorization_context — id kebijakan, scope yang diizinkan, kedaluwarsa, dan token persetujuan atau audit id yang mengaitkan aksi ke alur persetujuan.
  • outcome — keadaan akhir atau efek samping: file yang ditulis, perintah yang dieksekusi, perubahan jaringan; sertakan object id dan checksum.
  • evidence_hash — digest dari payload rekaman penuh yang digunakan untuk deteksi pengubahan (simpan terpisah atau tandatangani; lihat bagian signing di bawah).
  • p2p_or_relay — apakah sesi peer-to-peer atau melalui relay, dan jika relay: region dan relay id.
  • log_integrity — metadata tanda tangan (key id, algoritma tanda tangan, signature) jika Anda menandatangani log.

Bidang‑bidang tersebut membentuk inti. Bergantung pada risiko dan regulasi, tambahkan beberapa lagi: container runtime id, versi kernel/hypervisor, hardware TPM attestation id, nomor seri sertifikat yang dipakai untuk TLS, dan pointer provenance dataset apa pun.

Contoh entri audit

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

Contoh di atas menyeimbangkan reproduktibilitas (model_digest, prompt_hash, runtime_config) dengan privasi (prompt disimpan sebagai hash). Jika Anda wajib menyimpan prompt penuh untuk alasan hukum, batasi akses dan catat setiap pembacaan prompt mentah secara terpisah.

Imutabilitas, penandatanganan dan kebijakan retensi

Auditor dan responder insiden perlu mempercayai bahwa log tidak dimanipulasi. Dua langkah praktis:

  • Storage append-only dengan snapshot tidak dapat diubah (object storage dengan versioning/WORM atau filesystem write-once). Simpan backup dingin terpisah di region berbeda.
  • Penandatanganan log: hitung evidence_hash setiap rekaman dan tandatangani dengan kunci log-signing khusus. Rotasi kunci sesuai jadwal dan simpan public key lama untuk verifikasi. Sertakan metadata tanda tangan (key id, algoritma, dan expiry) di dalam rekaman.

Retensi: tim operasional umum menyimpan log fidelity-tinggi online selama 90 hari untuk troubleshooting, mempertahankan metadata terindeks selama 1 tahun untuk kepatuhan dan menyimpan arsip tanda-tangan immutable 1–7 tahun tergantung regulasi. Pilih retensi bersama penasihat hukum — durasi yang tepat bervariasi menurut industri: finance dan healthcare sering kali beberapa tahun.

Privasi, redaksi dan kontrol akses

Log audit untuk agen dapat berisi rahasia: API keys, PII, dokumen yang dipindai, atau data kontraktual. Catat apa yang Anda butuhkan untuk reproduktibilitas dan jangan lebih. Kontrol praktis:

  • Kebijakan redaksi: simpan hash input sensitif (prompt_hash, file_hash) dan pindahkan plaintext ke vault terlindungi yang hanya dapat diakses saat insiden dan hanya dengan alur persetujuan yang dapat diaudit.
  • Least privilege: pisahkan peran untuk menulis log, membaca raw log, dan memverifikasi tanda tangan. Setiap pembacaan raw log itu sendiri harus diaudit.
  • Consent dan pemetaan: jika agen bertindak atas nama pengguna, simpan ikatan yang jelas (delegation token, persetujuan bertimestamp) sehingga Anda dapat mengatribusikan aksi ke human principal untuk keperluan hukum dan GDPR.

GDPR dan undang‑undang privasi lain memperlakukan log yang berisi data personal sebagai data personal; konsultasikan penasihat hukum tentang minimisasi, pembatasan tujuan dan dasar hukum penyimpanan. Jika ragu, hash atau redaksi dan catat akses ke materi yang tidak direduksi.

Mengapa menangkap detail model dan runtime (bukan metadata opsional)

Dua eksekusi agen dengan prompt yang sama bisa berbeda jika versi model, temperature, seed atau toolchain berbeda. Untuk rekonstruksi insiden Anda memerlukan:

  • Pengidentifikasi model dan digest — string versi hosted-model saja rapuh; checksum atau versi provider yang immutable lebih baik.
  • Commit kode agen atau image digest — bug yang diperkenalkan pada kode agen bisa mengubah perilaku lebih besar daripada perbedaan prompt.
  • Parameter runtime dan seed — untuk mereproduksi keluaran spesifik atau mengetahui apakah reproduksi mungkin dalam mode deterministik.
  • Versi alat dan respons — alat yang mengembalikan data berbeda mengubah hasil; simpan response hash dan endpoint.

Tanpa bidang‑bidang itu, Anda tidak dapat secara andal mengatakan apa yang dilakukan agen atau mengapa ia melakukannya.

Kontrol operasional: alert, sampling dan forensic mode

Mencatat semuanya dengan fidelitas penuh bisa mahal dan berisiko. Terapkan strategi bertingkat:

  • Sampling default: simpan metadata lengkap (hash, model names, daftar aksi) untuk setiap eksekusi, tetapi simpan prompt penuh dan respons alat hanya saat eksekusi memenuhi trigger (aksi berisiko tinggi, keluhan pengguna, skor pelanggaran kebijakan).
  • Forensic mode: pada alert (cek kebijakan gagal, keluhan eksternal), tangkap artefak mentah penuh ke forensic store yang disegel, akses-terkontrol dan buat snapshot tanda‑tangan immutable untuk penyidik.
  • Alert real-time: buat aturan untuk aksi berisiko tinggi (transfer bank, perintah privileged) dan hasilkan persetujuan otomatis atau blok human-in-the-loop sebelum efek samping terjadi.

Pilihan infrastruktur: managed relay vs self-hosting

Tempat Anda menyimpan dan mentransport log audit penting. Untuk remote-access dan tooling agen, relay terkelola Tenvo adalah rekomendasi default untuk kebanyakan tim: menyediakan klien native untuk Windows/macOS/Linux, klien browser dalam public beta, dan relay terkelola multi-region dengan logging dan tier retensi bawaan (Free $0 / Lite $2.99/mo / Pro $7.99/mo). Menggunakan managed relay mengalihkan pembaruan sertifikat, skala relay, patch on-call dan backup lintas-region.

Caveat relay penting: ketika sesi fallback ke relay, TLS terminates di relay, sehingga operator relay punya posisi untuk melihat sesi. Itu berarti Anda harus memperlakukan log yang di-host pada relay sebagai berpotensi dapat dilihat operator relay. Jika kebutuhan Anda melarang infrastruktur pihak-ketiga mengakses payload sesi (mis. kepatuhan tertentu atau batasan residensi data), self-hosting adalah pilihan yang tepat.

Self-host hanya jika Anda memiliki persyaratan tertulis: mandat regulasi yang melarang relay pihak-ketiga, jaringan terisolasi tanpa akses keluar, atau aturan residensi data yang ketat. Self-hosting membawa biaya: on-call, patching, custody kunci, pembaruan sertifikat, dan tidak ada failover multi-region otomatis kecuali Anda membangunnya — managed relay lebih murah jika Anda menghitung biaya operasional tersebut.

Model akses log audit dan respons insiden

Rancang siapa dapat melakukan apa terhadap log sebelum Anda membutuhkannya. Kontrol minimum:

  • Write-only untuk agen: layanan agen menambahkan ke log tetapi tidak dapat membaca raw log.
  • Peran baca tersegregasi: analis dapat membaca metadata; investigator membutuhkan privilege lebih tinggi untuk membuka artefak tersegel dan setiap pembukaan itu sendiri dicatat dan ditandatangani.
  • Attestasi otomatis: ketika investigator mengakses data tersegel, buat rekaman attestasi bertanda-tangan yang mengaitkan identitas investigator, waktu dan tujuan.

Selama insiden, Anda perlu merekonstruksi rantai kausal dengan cepat. Jika log Anda menyertakan model_digest, agent_version, prompt_hash, daftar aksi dan hash panggilan eksternal, biasanya Anda bisa mengidentifikasi akar penyebab dalam hitungan jam daripada hari.

Checklist untuk mulai (langkah praktis)

  • Definisikan JSON schema untuk rekaman audit agen Anda dan tegakkan itu saat penulisan. Sertakan bidang yang tercantum sebelumnya.
  • Implementasikan evidence_hash dan tandatangani setiap rekaman dengan kunci log-signing; simpan public key dalam keyset yang dapat ditemukan oleh auditor.
  • Tentukan retensi: 90 hari online untuk rekaman lengkap; 1–7 tahun diarsipkan tergantung regulasi.
  • Buat aturan redaksi: apa yang di-hash vs disimpan plaintext dan siapa yang dapat mengakses plaintext.
  • Tambahkan pemeriksaan kebijakan real-time dan persetujuan otomatis untuk aksi berisiko tinggi.
  • Jalankan tes reproduktibilitas mingguan: ambil sampel entri dan verifikasi Anda dapat mereproduksi hasil agen berdasarkan model, seed dan config yang tercatat.

Jika Anda sudah menggunakan remote desktop atau tooling agen dengan Tenvo, tinjau Designing a Compliant Remote Desktop Audit Logging Trail untuk pola logging yang berlaku pada sesi interaktif, dan konsultasikan ai agent remote desktop: policies, approvals, audit untuk alur persetujuan spesifik agen. Untuk gambaran lebih luas tentang bagaimana agen masuk ke tooling remote, lihat AI and remote desktop: how agents use remote tooling.

Mulai kecil: implementasikan schema, tegakkan penandatanganan, dan iterasi pada redaksi. Hasilnya adalah respons insiden lebih cepat, delegasi yang dapat diaudit dan postur kepatuhan yang dapat dipertahankan.

Download Tenvo untuk menguji logging dan perilaku managed relay secara lokal dan lihat bagaimana relay kami, tier harga (Free $0 / Lite $2.99/mo / Pro $7.99/mo) dan relay multi-region menyederhanakan operasi: Download.

Dapatkan Tenvo

Siap mencoba sendiri?

Gratis untuk 30 perangkat, tanpa kartu kredit. Siap dan tersambung dalam dua menit.