Identitas, Izin, dan Jejak Audit Agen AI: Contoh Catatan Tindakan

Mulai dari catatan tindakan yang mudah ditelusuri

Identitas, izin, dan jejak audit agen AI menjadi berguna ketika peninjau dapat mengikuti satu tindakan dari permintaan hingga hasilnya. Pernyataan “agen sudah selesai” belum cukup. Anda perlu mengetahui siapa meminta pekerjaan, identitas apa yang bertindak, akses yang digunakan, keputusan persetujuan, serta bukti hasil pada sumber daya tujuan.

Berikut contoh ilustratif untuk catatan manual, bukan format ekspor bawaan produk. Seorang anggota tim meminta agen membaca dokumen “Agenda rapat tim” untuk menyiapkan usulan balasan. Agen tidak diberi izin mengubah dokumen atau mengirim balasan. Lima kelompok bidang berikut menjaga batas itu tetap terlihat.

Misalnya, beri permintaan rujukan manual REQ-01, tindakan baca ACT-01, dan penyusunan usulan ACT-02. Ketiganya terkait, tetapi hasilnya berbeda. Bukti akses dokumen mendukung tindakan baca; keberadaan usulan teks mendukung penyusunan. Keduanya tidak membuktikan ada pesan terkirim.

Orang yang meminta tugas juga belum tentu orang yang menyetujui akses. Catat peran itu secara eksplisit agar peninjau tidak menyimpulkan bahwa permintaan pengguna otomatis memberikan seluruh kewenangan. Identitas yang disebut dalam percakapan hanyalah label sampai terhubung dengan identitas pelaksana yang dapat diperiksa.

Simpan rujukan yang cukup untuk menelusuri kejadian tanpa menyalin seluruh dokumen atau rahasia. Bila bukti tidak tersedia, tulis “belum terverifikasi” beserta pemeriksaan berikutnya, bukan mengisi keberhasilan berdasarkan respons model.

Pilih identitas dan cakupan izin perusahaan

Dalam panduan otorisasi Microsoft Entra Agent ID, identitas agen dapat memakai izin yang didelegasikan atau izin aplikasi. Pada jalur delegasi, agen bertindak atas nama pengguna dalam batas izin yang berlaku. Pada jalur aplikasi, administrator memberikan izin kepada identitas aplikasi. Peminta pekerjaan, identitas pengakses sumber daya, dan pemberi persetujuan dapat berbeda.

Untuk tugas membaca satu dokumen, mulai dari izin baca pada sumber daya yang diperlukan. Izin menulis luas atau peran administrator tidak dibutuhkan hanya untuk menyusun usulan teks. Kredensial yang dapat dipakai pada layanan tertentu juga tidak dengan sendirinya membentuk sistem tata kelola identitas.

Peran sumber daya Azure, peran direktori, dan izin Microsoft Graph mengatur sumber daya berbeda. Cocokkan izin dengan tempat data berada serta operasi yang diperlukan. Dokumentasi Entra membatasi peran dan izin API berprivilege tinggi untuk identitas agen; jangan menganggap semua akses pengguna atau administrator dapat langsung diberikan kepada agen.

• Tentukan apakah agen perlu bertindak atas nama pengguna atau menggunakan izin aplikasi.
• Identifikasi sumber daya tujuan dan operasi minimum yang diperlukan.
• Periksa siapa yang berwenang memberikan akses dan siapa pemilik atau sponsor agen.
• Catat masa berlaku atau jadwal peninjauan jika kebijakan organisasi mensyaratkannya.
• Pisahkan pemberian akses koneksi dari keputusan atas tindakan berdampak berikutnya.

Persetujuan OAuth terhadap akses layanan bukan persetujuan atas setiap pengiriman atau perubahan berikutnya. Untuk contoh dokumen tadi, akses baca tidak membenarkan tindakan mengirim usulan balasan. Perluasan tugas harus ditinjau sebagai perubahan cakupan, bukan dianggap kelanjutan otomatis.

Saat pemilik pekerjaan atau tugas berubah, tinjau koneksi yang masih aktif. Keamanan AI Agent Perusahaan: Cara Menilai Agent Ponsel yang Lokal dan Terkendali membahas kebutuhan organisasi yang lebih luas. Contoh Entra di sini menjelaskan tata kelola perusahaan, bukan integrasi Entra pada FoneClaw.

Hubungkan bukti identitas dengan hasil tindakan

Panduan Microsoft Entra tentang catatan masuk dan audit agen menjelaskan bahwa kejadian audit dapat memuat agentType dan blueprintId untuk membantu menghubungkan aktor atau target dengan rancangan agen. Aktivitas rancangan agen muncul sebagai kejadian aplikasi, identitas agen sebagai kejadian prinsipal layanan, dan akun pengguna agen sebagai kejadian pengguna.

Dengan setidaknya peran Reports Reader, peninjau dapat membuka Microsoft Entra ID > Pemantauan dan kesehatan > Catatan masuk, lalu menggunakan filter agen. Kueri Microsoft Graph untuk catatan agen yang dirujuk dalam dokumentasi menggunakan jalur /beta; sesuaikan penggunaan dengan kebijakan serta ketersediaan organisasi.

Catatan masuk menjawab pertanyaan akses: identitas mana mencoba masuk, melalui jalur apa, dan bagaimana hasil autentikasinya. Audit identitas membantu menelusuri perubahan identitas atau izin. Keduanya belum membuktikan dokumen apa yang benar-benar dibaca, isi balasan, atau penerima pesan.

Hubungkan bukti dengan rujukan permintaan, identitas pelaksana, sumber daya tujuan, dan waktu. Untuk REQ-01, peninjau dapat mencocokkan akses identitas dengan tindakan baca dokumen yang tercatat pada aplikasi. Kemudian periksa rujukan usulan teks untuk ACT-02. Bila sistem tidak menyediakan ID yang dapat dihubungkan langsung, catat keterbatasan korelasi tersebut.

Waktu yang berdekatan saja tidak cukup untuk memastikan dua kejadian berasal dari tugas sama, terutama jika satu agen melayani beberapa permintaan. Periksa identitas dan target bersama-sama. Simpan pula sumber bukti agar peninjau tahu apakah status berasal dari sistem identitas, hasil alat, atau pemeriksaan aplikasi.

Jika autentikasi berhasil tetapi bukti operasi tujuan hilang, hasil tindakan tetap belum pasti. Jika aplikasi tujuan menunjukkan penolakan, jangan menggantinya dengan status berhasil hanya karena masuk ke layanan sukses. Catat kedua hasil pada lapisannya masing-masing dan batasi akses terhadap catatan sesuai kebijakan organisasi.

Catat empat hasil tanpa menyamakan persetujuan dan eksekusi

Empat catatan berikut adalah contoh yang dapat Anda gunakan untuk peninjauan manual. ID hanya penanda ilustratif. Isi hasil harus mengikuti bukti pada tugas Anda, bukan disalin seolah-olah kejadian ini sudah berlangsung.

Berhasil untuk operasi baca

Pada REQ-01 / ACT-01, cakupan hanya membaca dokumen tertentu. Catat identitas pelaksana, rujukan koneksi baca, dan keputusan kebijakan yang berlaku. Jika aplikasi tujuan mencatat akses yang sesuai dan usulan tersedia, tulis operasi baca terverifikasi serta rujukan usulannya. Jangan menambahkan “balasan terkirim”; pengiriman berada di luar cakupan contoh.

Keberhasilan juga perlu dibatasi pada sumber daya yang benar. Respons berdasarkan dokumen lain tidak memenuhi tugas meskipun akses layanan berhasil. Peninjau perlu mencocokkan dokumen tujuan, bukan sekadar menerima status umum.

Menunggu persetujuan tindakan tulis

Pada REQ-02 / ACT-01, pengguna meminta pembuatan acara kalender dengan detail yang sudah lengkap. Jika kebijakan memerlukan persetujuan dan keputusan belum diberikan, tulis “menunggu persetujuan”. Catat target kalender dan tindakan yang diusulkan; jangan menulis acara sudah dibuat.

Setelah persetujuan diberikan, status berpindah ke tahap yang relevan, bukan langsung menjadi berhasil. Masih perlu diketahui apakah alat dijalankan dan apakah acara tersimpan dengan detail benar.

Ditolak dan tujuan diperiksa

Pada REQ-03 / ACT-01, upaya tulis ditolak karena cakupan atau kebijakan tidak mengizinkannya. Catat alasan yang benar-benar ditampilkan, keputusan penolakan, dan apakah ada upaya eksekusi. Jika pemeriksaan tujuan memastikan perubahan tidak terjadi, catat “ditolak; tujuan tidak berubah”. Bila tujuan belum diperiksa, jangan mengklaim keadaan akhirnya sudah diketahui.

Hasil tulis sebagian atau belum pasti

Pada REQ-04 / ACT-01, permintaan tulis sudah dimulai tetapi respons terputus. Catat tahap terakhir yang diketahui dan status “hasil belum pasti”. Acara mungkin sudah tersimpan meskipun pesan penyelesaian tidak diterima. Periksa kalender berdasarkan judul, waktu, dan target sebelum mencoba ulang.

Jika acara ditemukan, cocokkan seluruh detail dan lanjutkan hanya pekerjaan yang tersisa. Jika tidak ditemukan, dokumentasikan pemeriksaannya sebelum mengulangi tindakan sesuai kebijakan. Jangan menggunakan ketiadaan respons sebagai bukti bahwa penulisan tidak terjadi.

Gunakan pertanyaan yang sama untuk tugas di ponsel

Di FoneClaw, permintaan “Tampilkan status baterai dan mode hemat daya” merupakan contoh yang mudah diperiksa. Alat device_battery_status membaca status Android tanpa mengubah setelan. Dalam catatan manual, tulis peminta, konfigurasi model yang digunakan, keadaan alat, kebijakan persetujuan, serta nilai yang dikembalikan dan dibandingkan dengan tampilan perangkat.

Label risiko dan persetujuan bawaan membantu memahami alat, tetapi mode persetujuan global serta pengaturan per alat menentukan perilaku aktual. Tidak munculnya permintaan persetujuan bukan bukti kegagalan, dan munculnya persetujuan bukan bukti tindakan selesai. Catat perilaku yang benar-benar berlaku pada sesi tersebut.

Bandingkan dengan calendar_create_event, yang mengubah kalender Android. Sebagai contoh permintaan, pengguna memilih 12 Oktober 2026 pukul 09.00–10.00 pada zona waktu perangkat, tanpa pengingat. Bila waktu selesai atau pilihan pengingat belum diberikan, kumpulkan detail itu terlebih dahulu. Jangan menebaknya dari judul rapat.

Setelah eksekusi sesuai kebijakan yang aktif, periksa actualStart dan actualEnd yang dikembalikan alat, lalu buka acara pada kalender tujuan. Cocokkan judul, tanggal, waktu mulai, waktu selesai, dan pengingat dengan permintaan. Waktu yang direncanakan model tidak menggantikan waktu aktual yang dibuat.

Izin Android, status alat FoneClaw, dan kredensial penyedia model adalah kontrol berbeda. API Key model tidak memberikan izin kalender Android. Model yang dipilih menafsirkan tugas; alat yang aktif menjalankan langkah yang didukung. Model daring dapat memproses konteks di luar perangkat meskipun tindakan kalender berlangsung di ponsel.

Halaman fitur FoneClaw menjelaskan cakupan tindakan yang didukung. Catatan manual ini membantu pemeriksaan tugas, tetapi percakapan ponsel bukan bukti audit tahan perubahan atau ekspor audit perusahaan bawaan.

Uji penolakan, cabut akses, dan periksa keadaan tersisa

Untuk memeriksa pembatasan tanpa mengubah data penting, Anda dapat menonaktifkan satu alat baca yang tidak diperlukan lalu meminta pembacaan yang sesuai. Ini usulan pemeriksaan pada konfigurasi Anda, bukan hasil pengujian kami. Catat keadaan alat sebelum perubahan agar dapat dipulihkan bila tugas memang memerlukannya.

Pengamatan yang dicari adalah alat tidak menjalankan pembacaan baru dan hambatan ditampilkan sesuai kontrol yang berlaku. Jawaban model yang tampak menyebut status baterai belum cukup; periksa apakah hasil alat baru benar-benar tersedia atau jawaban hanya mengulang informasi lama. Status baca tidak semestinya menyebabkan perubahan setelan perangkat.

Jika pembatasan tidak berperilaku seperti yang diharapkan, berhenti dan tinjau alat aktif serta kebijakan terkait. Jangan langsung memperluas izin. Jika pemeriksaan berhasil, simpan catatan penolakan dan aktifkan kembali alat hanya untuk kebutuhan yang jelas.

Cabut koneksi atau izin yang tidak lagi digunakan, tinjau pemilik identitas, serta rotasi kredensial bila terungkap. Bedakan apa yang dicabut: akses penyedia model, izin sumber daya perusahaan, izin Android, atau kemampuan alat. Mencabut satu lapisan tidak otomatis mencabut semuanya.

Pencabutan membatasi akses berikutnya; ia tidak menghapus pesan atau acara yang sudah dibuat. Setelah menghentikan akses, periksa keadaan aplikasi tujuan dan tentukan perubahan mana yang perlu ditangani tersendiri. Untuk penulisan yang belum pasti, lakukan pemeriksaan ini sebelum mencoba ulang agar tidak menciptakan duplikasi.

Tinjau pula pengecualian persetujuan, pembaca catatan, dan masa simpan sesuai kebijakan sendiri. Saat kemampuan berasal dari skill, Keamanan Skill AI Agent: Mengapa Phone Agent Perlu Cek Izin Saat Berjalan membantu menilai akses saat eksekusi. Untuk konteks tersimpan yang memengaruhi keputusan berikutnya, baca Peracunan Memori Agen AI di Ponsel. Catatan yang lengkap harus tetap membedakan izin, keputusan, upaya, dan keadaan akhir yang sudah diperiksa.