Cara Tim Keuangan Menerapkan Aplikasi Buatan AI Tanpa Membocorkan Data Keuangan

Ketika perusahaan keamanan RedAccess mencari aplikasi yang dibuat dengan alat pemrograman AI dan dipublikasikan di hosting alat tersebut, mereka menemukan lebih dari 5.000 aplikasi yang nyaris tanpa keamanan atau autentikasi. Di antara tangkapan layar yang dibagikan kepada Wired terdapat “berbagai catatan penjualan dan keuangan dari sejumlah perusahaan lain”. Aplikasi buatan AI untuk tim keuangan bisa berada di alamat terbuka serupa, dengan buku besar, penggajian, dan hasil yang belum diumumkan di dalamnya.

CEO Replit, Amjad Masad, menjawab bahwa “Aplikasi publik yang dapat diakses di internet merupakan perilaku yang diharapkan”. Ia benar tentang mekanismenya. Menurut saya, paparan itu berasal dari pengaturan visibilitas dan tinjauan yang dilewatkan, keduanya dapat ditangani oleh pembuat alat.

TL;DR

• Alat keuangan buatan AI dapat membocorkan data melalui enam kesalahan penerapan yang bisa ditangani pembuatnya: tautan publik, kata sandi dan kunci dalam kode atau riwayat percakapan, akses administrator ke basis data, pencatatan tanpa pemberi persetujuan kedua, data yang dikirim ke layanan luar, dan perubahan perhitungan tanpa catatan.
• Setiap kesalahan memiliki perbaikan, kebanyakan melalui alat AI yang sama, serta pemeriksaan nyata untuk membuktikannya, seperti penulisan yang ditolak basis data atau kata sandi lama yang tidak lagi berfungsi.
• Secara default, simpan alat keuangan di jaringan privat. Tambahkan login perusahaan saat orang di luar keuangan perlu mengaksesnya, dan serahkan ke TI jika alat membukukan tanpa pemberi persetujuan kedua, menyentuh data kartu, atau memasok angka untuk laporan keuangan dalam lingkup SOX.
• Wilayah server menentukan lokasi penyimpanan utama VPS, tetapi cadangan, log, dan layanan pihak ketiga bisa membuat salinan di tempat lain. Kepatuhan keseluruhan merupakan pertanyaan terpisah. Bawa kerangka wilayah Anda kepada tim kepatuhan.

Kesalahan Penerapan yang Membocorkan Data Keuangan

Alat keuangan buatan AI dapat membocorkan data melalui enam kesalahan: tautan publik, kredensial dalam kode atau percakapan, akses admin padahal cukup baca-saja, pembukuan tanpa persetujuan kedua, pengiriman ke layanan luar, dan perhitungan yang berubah tanpa catatan. Demo mendorong setiap pilihan default ini.

Setiap perbaikan di bawah memiliki prompt untuk alat AI pembuat aplikasi; ubah bidang dalam kurung siku sebelum menempelkannya. Prompt ini merupakan titik awal yang belum diuji, ditulis untuk artikel ini. Pernyataan AI bahwa perubahan sudah dilakukan tidak membuktikan apa pun; pemeriksaan di bawahnya yang membuktikan. Jalankan terhadap kode dan data contoh atau sintetis, jangan pernah menempelkan catatan nyata atau kunci aktif ke percakapan.

Membiarkan Alat pada Tautan Publik Pembuat Aplikasi AI

Dasbor perkiraan kas yang dibiarkan publik di hosting pembuat AI dapat dibuka siapa pun yang mengetahui alamatnya, termasuk umur utang usaha, anggaran dibanding realisasi, dan hasil kuartal sebelum diumumkan. Laporan Wired tentang temuan RedAccess menjelaskan bahwa peneliti menemukannya melalui pencarian sederhana Google dan Bing pada domain vendor AI.

Sebagian aplikasi hanya meminta login dengan alamat email apa pun. Login yang menerima email apa pun bukan kontrol akses.

Keluarkan data nyata dari hosting vendor. Sampai alat berjalan di server yang Anda kendalikan, dibahas pada bagian berikut, buat dan demonstrasikan dengan data sintetis atau sandbox atau perusahaan uji ERP, jika tersedia, bukan ekspor nyata. Terapkan ulang setelah perubahan, karena alamat hosting menyajikan versi yang terakhir diterapkan.

Buat data sintetis untuk aplikasi ini yang sesuai dengan tabel dan kolom yang dibacanya: [daftar tabel dan kolom, misalnya vendors, invoices, journal_lines].

Gunakan nama vendor dan pelanggan rekaan, rekening bank rekaan, serta jumlah dalam [mata uang] yang berperilaku seperti pembukuan nyata: setiap jurnal seimbang, dan total buku pembantu cocok dengan [akun kontrol utang / piutang].

Arahkan aplikasi ke data ini, bukan ekspor nyata, dan daftarkan setiap file atau pengaturan yang diubah.

Jangan meminta catatan nyata kepada saya.

Pastikan berhasil: buka alamat hosting vendor di browser tanpa login, atau minta rekan di luar keuangan. Pastikan hanya menampilkan data sintetis, halaman login, atau tidak ada apa pun. Cari tiga nama vendor atau pelanggan dari ERP nyata dalam file data dan repositori; jangan ada kecocokan. Terakhir, jalankan neraca saldo atau ringkasan aplikasi dan pastikan total debit sama dengan kredit.

Meninggalkan Kredensial ERP, Feed Bank, dan Basis Data dalam Kode atau Percakapan

Jika kredensial aktif disimpan di sana, siapa pun yang membaca riwayat, repositori, atau konfigurasi MCP mungkin dapat menggunakannya untuk mengakses ERP, basis data keuangan, atau integrasi feed bank. MCP adalah konektor agar alat AI seperti Claude dapat berbicara langsung dengan ERP atau basis data, dan konfigurasinya merupakan tempat lain untuk kata sandi.

State of Secrets Sprawl 2026 dari GitGuardian menemukan 24.008 rahasia unik terpapar dalam konfigurasi MCP, 14% berupa string koneksi PostgreSQL. Pada commit GitHub publik, laporan yang sama menemukan commit dengan Claude Code sebagai penulis bersama membocorkan rahasia sekitar dua kali tingkat dasar, sementara faktor manusia tetap penting.

Menghapus pesan tidak membatalkan paparan: pemilik salinan percakapan, repositori, atau riwayat tetap memiliki nilainya. Untuk setiap kata sandi, kunci, atau token yang pernah berada di sana, terbitkan yang baru di konsol admin ERP, basis data, atau penyedia feed bank, lalu nonaktifkan yang lama. Itulah rotasi kredensial.

Aplikasi kemudian membaca kredensial saat mulai dari variabel lingkungan, pengaturan bernama di luar kode yang disediakan lapisan penerapan, yaitu alat yang membangun dan menjalankan aplikasi di server. HashiCorp Vault menjadi langkah lanjut jika beberapa alat berbagi rahasia yang perlu dirotasi dari satu tempat.

Salinan kata sandi tim sebaiknya berada di pengelola untuk manusia seperti Vaultwarden; aplikasi yang berjalan membaca nilainya dari lingkungan. Mulailah dengan menemukan setiap rahasia yang ditanam langsung dalam kode AI.

Audit proyek ini untuk rahasia yang ditanam langsung. Temukan setiap kata sandi, kunci API, token akses, dan string koneksi, termasuk .env, notebook, konfigurasi MCP, serta kode yang terhubung ke [nama ERP / penyedia feed bank / basis data keuangan].

Ganti setiap nilai dalam kode dengan variabel lingkungan bernama dan berikan daftar namanya.

Pastikan file berisi nilai nyata tidak di-commit ke repositori, dan daftarkan setiap commit riwayat yang memuatnya.

Tampilkan lokasi saja. Jangan cetak nilai rahasia.

Pastikan berhasil: coba kata sandi atau token lama sendiri atau melalui TI; harus ditolak. Cari nilai lama dalam file proyek saat ini; tidak boleh ada. Nilai yang masih dalam riwayat hanya berhenti memberikan akses setelah Anda memastikan bahwa nilainya telah dicabut atau kedaluwarsa.

Menggunakan Login Administrator Pembuat Saat Alat Hanya Perlu Membaca

Dasbor umur piutang tidak boleh mengubah buku besar. Jika menggunakan login admin pembuat, alat mewarisi hak akun itu. Kunci rahasia Supabase atau kunci lama service_role memberikan akses tinggi dan melewati Row Level Security, sehingga tidak untuk akses baca-saja biasa. Laporan satu jadwal umur piutang dapat memaparkan seluruh buku besar, termasuk tabel penggajian.

Sisi penulisan membuatnya mahal. Pemindaian Symbiotic Security terhadap 1.072 aplikasi buatan AI berbasis Supabase menemukan 172 yang memungkinkan siapa pun menghapus catatan tanpa autentikasi, 172 yang memungkinkan siapa pun mengubah catatan yang sudah ada, dan 39 dengan tabel yang sepenuhnya dapat dibaca oleh siapa pun yang memegang kunci publik.

Berikan kredensial baca-saja terbatas pada tabel yang dibutuhkan. Dalam ERP atau basis data, buat pengguna integrasi khusus dengan akses baca hanya ke objek laporan. Di Supabase, aktifkan Row Level Security, aturan basis data untuk baris yang dapat dilihat tiap permintaan, pada semua tabel terekspos yang digunakan, dan tinjau grant tabel: grant menentukan apakah peran dapat select, insert, update, atau delete. Aplikasi keuangan baca-saja tidak memerlukan penulisan yang tidak digunakan. Kunci publishable boleh dalam kode browser jika RLS dan hak minimum benar. Kunci rahasia dan service_role lama tetap di server, untuk tugas backend yang benar-benar perlu hak tinggi dan menegakkan otorisasinya sendiri.

Catatan: kunci publishable Supabase atau kunci lama anon dalam JavaScript halaman adalah normal. Dokumentasi kunci API Supabase menyebutkan bahwa aksesnya hanya sesuai Row Level Security. Kunci rahasia melewatinya, sehingga tidak boleh muncul dalam apa pun yang dikirim ke browser.

Daftarkan setiap pembacaan dan penulisan aplikasi ke [nama ERP atau basis data], menurut tabel atau objek.

Ubah agar hanya membaca [tabel yang diperlukan] menggunakan kredensial baca-saja terpisah dari variabel lingkungan, tidak pernah login saya.

Jika memakai Supabase, aktifkan Row Level Security pada setiap tabel terekspos yang digunakan. Daftarkan grant select, insert, update, dan delete untuk anon dan authenticated. Hapus hak tulis yang tidak diperlukan; jika aplikasi produksi lain bergantung padanya, tandai tanpa mengubah. Buat kebijakan agar pengunjung tanpa login tidak membaca apa pun, dan pengguna masuk hanya membaca [aturan, misalnya baris pusat biaya mereka]. Pastikan tidak ada kunci rahasia atau service_role lama dalam file yang dikirim ke browser.

Daftarkan kebijakan yang dibuat.

Pastikan berhasil: coba satu penulisan dengan kredensial alat, seperti mengedit catatan uji; harus ditolak. Untuk Supabase, minta baris tabel keuangan tanpa login; hasil kosong atau kesalahan yang diharapkan.

Membiarkan Alat Membukukan tanpa Pemberi Persetujuan Kedua

Pengimpor jurnal yang langsung membukukan atau pembuat file pembayaran yang langsung mengirim ke bank membuat penggunanya menjadi penyusun dan penyetuju sekaligus. Satu bug menggandakan akrual sebulan. Satu bidang berubah mengirim pembayaran vendor ke rekening keliru. Pemisahan tugas yang ditolak keuangan antara dua orang ini juga berlaku untuk perangkat lunak buatan AI.

Kerusakan tidak berhenti di aplikasi. Batch keliru masuk ke buku, membutuhkan jurnal koreksi dan penjelasan saat penutupan. Jika alat memakai login pribadi pembuat, setiap jurnal ganda memakai namanya.

Alat AI membaca dan menyiapkan; pembukuan dan pelepasan pembayaran melalui persetujuan ERP oleh orang berbeda dari operator alat. Setiap mesin akuntansi yang pernah saya kerjakan memperlakukan jurnal dan persetujuannya sebagai dua kejadian dengan dua pemilik. Alat buatan AI layak mendapat perlakuan sama.

Ubah setiap pembukuan langsung menjadi draf atau impor yang disiapkan dan menunggu persetujuan dalam ERP. Alat tetap menangani pemetaan, validasi, dan pembuatan batch, sementara persetujuan tetap bersama persetujuan penutupan lainnya. Jika ERP tidak memiliki tahap persetujuan impor, hasilkan file untuk ditinjau orang kedua terhadap ringkasan batch lalu diimpor sendiri oleh orang itu.

Alat yang harus membukukan otomatis, membuat file pembayaran, atau mengubah rekening vendor berada di bawah TI menurut bagian berikut.

Daftarkan setiap tempat aplikasi membuat, mengedit, atau membukukan [jurnal / tagihan / pembayaran] dalam [nama ERP].

Ubah setiap tempat menjadi draf atau impor yang perlu disetujui dalam [nama ERP] sebelum dibukukan. Jika ERP tidak punya persetujuan impor, hasilkan file dan jangan membukukan apa pun.

Hapus jalur kode yang membukukan atau melepas pembayaran tanpa persetujuan tersebut.

Untuk setiap batch, buat ringkasan jumlah baris, total debit, dan total kredit.

Daftarkan bagian yang masih langsung membukukan agar saya tinjau.

Pastikan berhasil: jalankan batch contoh. Tidak boleh ada pembukuan sebelum pengguna kedua menyetujui di ERP. Bandingkan ringkasan dengan batch ERP: jumlah baris, total debit, dan kredit harus tepat sama. Selisih satu baris berarti rekonsiliasi gagal, bukan pembulatan.

Mengirim Data Keuangan ke Layanan di Luar Kendali Anda

Fitur komentar varians yang mengirim seluruh buku besar ke API AI menyerahkan setiap baris kepada pihak ketiga. Dua jalur lebih senyap adalah skrip analitik yang melaporkan kunjungan ke vendor, serta pelacak kesalahan atau log dengan isi permintaan lengkap, tempat baris gaji, rekening pelanggan, dan angka belum dirilis bisa berakhir.

Untuk alat internal keuangan, jangan kirim hasil belum dirilis dan gaji ke pihak ketiga kecuali layanan serta aliran data tepatnya telah disetujui melalui proses vendor, keamanan, dan kepatuhan. Untuk yang lain, daftarkan semua tujuan dan kirim hanya bidang yang dibutuhkan. Penyimpanan atau pelatihan oleh layanan harus diperiksa penandatangan perjanjian berdasarkan ketentuan vendor. Untuk mengukur pemakaian, alat analitik self-hosted seperti Umami menyimpan kunjungan di server sendiri.

Daftarkan semua tempat aplikasi mengirim data di luar [server kita], termasuk API AI, analitik, pelacakan kesalahan, email, webhook, dan file log.

Untuk setiap tujuan, daftarkan tepat bidang yang diterima.

Tandai apa pun berisi [jumlah gaji / rekening bank / hasil belum dirilis / nama pelanggan].

Untuk tiap item, tunjukkan cara mengirim lebih sedikit bidang atau tidak sama sekali, dan ubah hanya setelah saya konfirmasi.

Pastikan berhasil: picu setiap fitur sekali dengan data contoh berisi rekening palsu yang dikenali dan jumlah gaji palsu. Cari keduanya pada pelacak dan log; tidak boleh ada. Untuk jalur API AI, catat isi permintaan keluar selama uji tersebut, cari dua nilai yang sama; keduanya tidak ada dan hanya bidang disetujui yang muncul. Matikan pencatatan ini sesudahnya.

Mengubah Perhitungan Tanpa Catatan dan Rekonsiliasi

Dalam kalkulator akrual atau validator waterfall pendapatan, kode adalah kontrol. Ubah satu rumus dan angka penutupan ikut berubah; tanpa kontrol versi tidak ada yang tahu siapa mengubah apa dan kapan.

Dalam diskusi r/ClaudeAI milik kantor CPA mengenai alat internal dengan Claude Code, seorang komentator menyebut batasnya: “‘akuntan + claude code’ berjalan sampai persyaratan jejak audit muncul. Itulah batas sebenarnya.”

Kunci perilaku saat ini sebelum mengubah. Setelah keluaran terkunci, logika bisa membaik tanpa total bergeser diam-diam. Simpan kode dalam kontrol versi yang mencatat penulis dan tanggal setiap perubahan.

Tulis tes dengan file contoh tetap dan bandingkan baseline tercatat agar setiap perubahan harus lolos rekonsiliasi sebelum dirilis. Tes terkunci juga melindungi kesalahan tercatat, jadi cocokkan total baseline dengan total ERP periode itu sebelum mempercayainya.

Minta orang kedua meninjau setiap perubahan perhitungan dan rekonsiliasi setiap eksekusi produksi dengan total ERP.

Masukkan proyek ke kontrol versi jika belum dan daftarkan file berisi logika perhitungan.

Tulis tes menjalankan aplikasi pada [file contoh] dan catat keluaran saat ini: jumlah baris dan total menurut [akun / entitas / periode].

Sebelum menyimpan keluaran, tunjukkan total agar saya cocokkan dengan [nama ERP] untuk [periode].

Setiap perubahan total tersebut harus membuat tes gagal.

Jangan mengubah logika perhitungan saat menulis tes.

Pastikan berhasil: sengaja ubah satu perhitungan, seperti pembulatan, dan pastikan tes gagal. Batalkan perubahan dan pastikan semua tes lolos kembali.

Privat Secara Default, Login Perusahaan untuk Lebih Banyak Orang, TI untuk Buku Besar

Data nyata tidak pernah dibiarkan pada hosting AI. Untuk menerapkan alat khusus keuangan dengan aman, gunakan server yang Anda kendalikan dan hanya dapat diakses melalui jaringan privat. Tambahkan login perusahaan untuk orang lain dan serahkan ke TI jika salah satu kondisi berikut benar.

VPS adalah server virtual sewaan dengan sistem operasi dan perangkat lunak yang Anda kendalikan. Jaringan privat, tailnet menurut Tailscale, menghubungkan perangkat disetujui. Tetap blokir akses masuk publik ke aplikasi, misalnya dengan firewall, dan buka hanya antarmuka VPN atau tailnet. Penyedia identitas menyimpan akun perusahaan; reverse proxy di depan aplikasi memaksa setiap permintaan melewati login.

Hosting alat AI tidak masuk tabel karena alasan pada kesalahan pertama. Begitu pula platform perusahaan seperti Northflank, yang cocok bagi organisasi besar dengan anggaran untuk vendor platform dan tinjauannya. Kontraknya berlebihan untuk alat departemen dengan beberapa pengguna.

Menurut pengalaman saya, Tailscale lebih cepat diterapkan dibanding pilihan jaringan privat lainnya, tetapi Tailscale menghosting sendiri layanan koordinasi. WireGuard adalah pilihan yang sepenuhnya self-hosted.

Alasan jaringan privat menjadi default: alat yang tidak merespons dari internet tidak ditemukan lewat pencarian atau diserang pada halaman login. Login buatan AI bergantung pada kode di belakangnya. Jika perlu akses di luar jaringan privat, login perusahaan menambah lapisan autentikasi terkelola di depan, sehingga menjadi tingkat kedua.

Saat pemilik anggaran membutuhkan akses, ganti login alat dengan login perusahaan, single sign-on (SSO). Orang memakai akun yang sudah ada; menonaktifkannya memblokir login baru. Atur pencabutan sesi, back-channel logout, atau masa sesi cukup pendek agar sesi lama tidak bertahan. Prompt memakai OIDC, standar yang didukung Authentik dan Keycloak.

Ganti login aplikasi dengan login perusahaan lewat [Authentik / Keycloak / penyedia identitas kita] menggunakan OIDC.

Baca grup setiap pengguna dari login.

Izinkan [halaman penggajian] hanya untuk anggota [nama grup], dan tegakkan di server pada tiap halaman, ekspor, serta endpoint API, bukan hanya menu.

Tolak permintaan tanpa login valid.

Pastikan berhasil: login dengan akun uji di luar grup dan minta halaman terbatas serta ekspor atau API secara langsung; keduanya harus ditolak. Nonaktifkan akun di penyedia identitas dan pastikan tidak memulai sesi baru. Pastikan sesi yang ada dicabut atau berakhir dalam batas waktu yang ditetapkan.

Sebagian alat tidak boleh tetap di tim. Serahkan ke TI atau rekayasa jika salah satu kondisi ini benar:

1. Membukukan ke buku besar atau sistem catatan resmi lain tanpa persetujuan manusia dalam ERP.
2. Membuat file pembayaran, melepas pembayaran, atau mengubah rekening vendor.
3. Keluarannya memasok laporan keuangan entitas terdaftar SEC dan bisa masuk kontrol internal pelaporan keuangan (ICFR). Bicarakan dengan audit internal sebelum dipakai saat penutupan; bagi emiten tunduk pada SOX Section 404(b), auditor eksternal mungkin menguji kontrol relevan.
4. Menyimpan, memproses, atau mengirim data kartu pembayaran.
5. Menilai kelayakan kredit individu.
6. Tidak ada yang bertanggung jawab atas patch, tinjauan akses, dan penghentian alat.

Kondisi keenam lebih penting dari kelihatannya. Dengan self-hosting Anda bertanggung jawab atas pembaruan, cadangan, dan pemantauan. Alat tanpa pemeliharaan lebih aman bersama TI. TI mungkin lambat; itulah biaya tata kelola yang diperlukan.

Untuk tingkat 1 dan 2, server, lapisan penerapan, jaringan privat, dan identitas untuk tingkat 2 harus tersedia sebelum alat dibuka. Tim tanpa insinyur harus menyiapkannya sendiri. Linux VPS kami memberikan root. Coolify dan WireGuard tersedia sebagai penerapan satu klik; Tailscale memakai penginstal resmi satu perintah, sedangkan Authentik memakai stack resmi Docker Compose. Waktu tim dapat dipakai untuk perbaikan, bukan membangun stack dari nol. Lokasi kami mencakup Frankfurt dan Amsterdam di UE, London di Inggris, dan sejumlah kota AS, sehingga Anda bisa memilih wilayah penyimpanan utama VPS; penerimaannya tetap dinilai kepatuhan.

Aturan yang Ditinjau Bersama Tim Kepatuhan, per Wilayah

Kerangka berlaku tergantung data serta lokasi perusahaan dan orang terkait. Tabel gaji pegawai UE dan jadwal pendapatan untuk laporan perusahaan tercatat AS bisa mengikuti kerangka berbeda.

Artikel ini bukan nasihat hukum. Tabel berikut menyebut kerangka untuk tim kepatuhan, tanpa menentukan apakah berlaku bagi Anda.

Untuk SOX, AS 2201 adalah standar PCAOB bagi atestasi auditor yang dirujuk Sarbanes-Oxley Section 404(b). Standar ini menyebut kontrol jurnal dan penyesuaian dalam pelaporan akhir periode sebagai kontrol yang dinilai terkait risiko penipuan. Di luar wilayah ini, mulai dari situs regulator perlindungan data nasional. Lokasi server menentukan penyimpanan utama, bukan lokasi semua cadangan, log, atau salinan pihak ketiga, dan tidak memenuhi kerangka di atas dengan sendirinya.

Pertanyaan yang Sering Diajukan

Apakah Vibe Coding Aman untuk Alat Keuangan?

Bisa, setelah celah demo ditutup; saya melihat bukti lebih sebagai masalah penerapan daripada kode. Alat keuangan lebih berisiko dari proyek pribadi karena membaca ERP dan bisa menulis buku. Jika membukukan tanpa persetujuan kedua, menangani pembayaran, atau data kartu, serahkan ke TI.

Apa Itu Shadow AI dalam Keuangan?

Shadow AI adalah alat AI atau aplikasi buatan AI pada data perusahaan tanpa sepengetahuan atau persetujuan TI, seperti dasbor perkiraan ERP yang belum dilihat TI. Cost of a Data Breach Report 2025 IBM menemukan biaya kebocoran rata-rata US$670.000 lebih tinggi pada organisasi dengan banyak shadow AI dibanding sedikit atau tidak ada, menurut pengumuman IBM.

Apa yang Ditunjukkan kepada Audit Internal atau Auditor Eksternal?

Bawa empat hal sebelum dipakai dalam penutupan: lokasi dan akses, riwayat perubahan dengan tes keluaran terkunci, persetujuan pembukuan ERP, dan bukti rekonsiliasi setiap batch terhadap total ERP. Auditor menentukan kebutuhannya; ini memberi dasar penilaian konkret.

Siapa Memiliki Alat Keuangan Buatan AI Setelah Pembuatnya Pergi?

Tunjuk pemilik di keuangan dan kontak teknis sebelum peluncuran. Gunakan kredensial layanan, bukan login pembuat, dan login perusahaan untuk akses. Menonaktifkan akun pegawai keluar memblokir login baru; sesi lama dicabut atau berakhir sesuai kebijakan. Penghentian berarti menonaktifkan kredensial, menyimpan yang diwajibkan retensi, menghapus sisanya, dan mematikan alat.