Risiko, Security, dan Governance AI Second Brain

Sebuah agent menerima email vendor, menyimpulkan ada perubahan rekening, lalu menyimpan nomor baru ke memory. Minggu berikutnya, informasi itu dipakai ketika menyiapkan pembayaran. Tidak ada satu langkah yang terlihat dramatis. Justru itu masalahnya: error kecil menjadi persisten, lalu mendapat kesempatan memengaruhi action berikutnya.

Second brain memperbesar manfaat konteks, tetapi juga memperpanjang umur kesalahan. Sistem ini membaca banyak sumber, menyimpan pilihan informasi, dan kadang terhubung ke tools. Security tidak bisa ditambahkan setelah demo berhasil.

Fondasi: lindungi aliran, bukan hanya database

Risiko muncul sepanjang lifecycle: capture, selection, storage, retrieval, context assembly, action, dan deletion. Enkripsi storage penting, tetapi tidak mencegah agent berizin mengambil memory client A untuk pekerjaan client B. Kontrol harus mengikuti data dari sumber sampai dampak action.

Governance berarti keputusan yang eksplisit tentang pemilik data, tujuan penggunaan, masa simpan, hak akses, kualitas, perubahan, dan akuntabilitas. Security menyediakan kontrol teknis. Safety membatasi dampak ketika model salah atau lingkungan dimanipulasi. Ketiganya bertemu di policy dan audit.

1. Memory poisoning

Dokumen, email, halaman web, dan hasil tool adalah input tidak tepercaya. Penyerang dapat menyisipkan klaim palsu atau prompt injection agar agent menganggap instruksi eksternal sebagai policy. Jika hasil itu masuk long-term memory, serangan bertahan setelah sumber awal tidak lagi terlihat.

Pisahkan data dari instruksi. Procedural memory hanya boleh ditulis oleh role terbatas. Memory faktual perlu provenance, schema validation, dan confidence. Informasi sensitif seperti rekening, permission, atau policy tidak boleh berubah berdasarkan satu pesan tanpa verifikasi ke source berwenang.

2. Data basi dan konflik

Harga, jabatan, status proyek, serta consent berubah. Timestamp saja tidak cukup jika retrieval tetap memilih versi lama. Gunakan valid-from, expiry atau review date, authority, dan relasi superseded-by. Untuk data transaksi, baca ulang source of truth saat action akan dilakukan.

Konflik harus terlihat. Jangan meminta model "memilih yang paling masuk akal" di antara dua policy. Sistem perlu aturan otoritas dan eskalasi manusia.

3. Kebocoran lintas tenant dan scope

Semantic search mudah mengambil teks mirip dari namespace yang salah jika filter diterapkan terlambat. Authorization harus terjadi sebelum kandidat masuk konteks, bukan setelah model melihatnya. Terapkan tenant isolation, least privilege, dan pemisahan environment.

Shared memory perlu alasan bisnis spesifik. Berbagi "best practice umum" berbeda dengan berbagi percakapan client. Default yang sehat adalah privat, lalu buka akses minimum sesuai kebutuhan.

4. Prompt injection lewat retrieval

RAG dapat mengambil dokumen yang berisi "abaikan instruksi sebelumnya" atau perintah untuk mengirim rahasia. Model mungkin gagal membedakan konten referensi dan instruksi. Tandai trust boundary, sanitasi format, batasi tool, dan gunakan policy di luar prompt untuk action kritis.

Jangan mengandalkan kalimat system prompt sebagai satu-satunya pertahanan. Permission tool harus ditegakkan oleh aplikasi dan kredensial yang memang sempit.

5. Excessive agency

Agent yang dapat membaca kalender tidak otomatis perlu menghapus acara. Tool contract harus kecil, parameter tervalidasi, dan credential scoped. Pisahkan read, draft, dan execute. Action finansial, destructive, eksternal, atau privacy-sensitive membutuhkan approval yang menyebut objek dan dampaknya.

Approval generik "izinkan agent bekerja" tidak cukup. Pengguna perlu tahu tindakan spesifik yang akan dilakukan. Untuk operasi penting, sediakan idempotency, rollback bila mungkin, dan verifikasi hasil dari environment.

6. Observability yang tidak berguna

Log percakapan saja tidak menjawab mengapa action terjadi. Catat identity agent dan user, memory yang diambil, versi policy, tool call, perubahan state, approval, serta artifact. Jangan memasukkan secret mentah ke log.

Audit harus dapat direkonstruksi, bukan sekadar banyak. Tim incident perlu menelusuri: sumber mana yang meracuni memory, task apa yang menggunakan memory itu, dan action mana yang terdampak.

7. Retention dan hak menghapus

"Semakin banyak data semakin pintar" adalah alasan buruk untuk menyimpan data tanpa batas. Tetapkan purpose limitation dan retention berdasarkan kategori. Temporary task data bisa cepat habis; keputusan legal mungkin perlu masa simpan khusus.

Pengguna perlu melihat, memperbaiki, dan menghapus memory sesuai hak serta kewajiban yang berlaku. Backup, derived summary, embedding, dan cache juga masuk desain deletion. Menghapus baris utama tetapi membiarkan semua turunannya bukan penghapusan yang utuh.

8. Supply chain dan connector

Second brain bergantung pada model provider, embedding, connector, MCP server, plugin, dan library. Setiap komponen menambah trust boundary. Inventarisasi dependency, pin versi, periksa provenance, rotasi secret, dan pantau perubahan capability.

Connector sebaiknya tidak menerima credential super-admin bila hanya perlu membaca satu folder. Untuk tool pihak ketiga, uji bagaimana data diproses dan disimpan.

Fakta versus interpretasi

Fakta: NIST AI RMF menyediakan kerangka Govern, Map, Measure, dan Manage untuk risiko AI. NIST Generative AI Profile membahas risiko khusus generative AI. OWASP Top 10 for LLM Applications mencakup prompt injection, sensitive information disclosure, dan excessive agency.

Interpretasi praktis: kerangka tersebut tidak menentukan satu arsitektur second brain. Tim tetap perlu memetakan kontrol ke workflow, data, dan dampak organisasinya sendiri.

Fakta: MCP menstandarkan koneksi ke data dan tools. Interpretasi: interoperabilitas mempercepat integrasi sekaligus membuat inventaris permission makin penting. MCP bukan security boundary otomatis.

Contoh governance untuk agency

Tetapkan data owner per account. Semua memory wajib memiliki tenant ID dan sumber. Account team boleh membaca serta mengusulkan koreksi; procedural policy hanya dapat diubah operations lead. Agent content tidak punya tool untuk mengirim invoice. Agent finance tidak dapat membaca draft campaign tanpa kebutuhan.

Setiap minggu, review memory baru berisiko tinggi dan konflik yang belum selesai. Setiap bulan, sampling retrieval lintas client dan uji deletion. Ketika karyawan keluar, cabut identity dan token terpusat; jangan mengandalkan instruksi ke agent untuk "tidak membaca lagi".

Baseline sebelum production

Mulai dengan threat model dan data inventory. Tentukan action tier, owner, retention, serta incident response. Jalankan red-team untuk injection, cross-tenant retrieval, privilege escalation, dan stale policy. Pastikan kill switch menghentikan action tanpa menghapus bukti audit.

Production rollout sebaiknya bertahap: read-only, draft dengan review, lalu action sempit. Naikkan otonomi berdasarkan bukti evaluasi, bukan rasa percaya pada demo.

Threat model dari sebuah action nyata

Bayangkan agent finance diminta menyiapkan pembayaran vendor. Ia membaca email, mengambil data vendor dari memory, mengecek invoice, lalu membuat draft transfer. Pada setiap sambungan ada pertanyaan berbeda. Apakah email autentik? Apakah nomor rekening berasal dari sumber yang berwenang? Apakah invoice duplikat? Apakah user boleh melihat nominal? Apakah approval menyebut rekening dan jumlah yang tepat?

Kontrol paling kuat berada di luar bahasa natural. Rekening aktif dibaca dari master vendor yang perubahan datanya memakai verifikasi terpisah. Sistem pembayaran menolak invoice ID yang sudah diproses. Credential hanya dapat membuat draft, bukan melepas dana. Approver melihat diff terhadap data sebelumnya. Dengan begitu, satu retrieval buruk tidak langsung berubah menjadi kerugian.

Register risiko yang bisa dipakai tim kecil

Tidak perlu membeli platform GRC sebelum pilot. Spreadsheet dengan kolom aset, skenario, likelihood, impact, kontrol, owner, bukti uji, dan review date sudah cukup untuk memaksa percakapan konkret. Bedakan kontrol yang direncanakan dari kontrol yang benar-benar diuji. "Ada RBAC" bukan bukti sampai tes membuktikan user account A ditolak saat meminta data account B.

Pilih beberapa indikator yang bisa ditindaklanjuti: retrieval lintas scope, memory tanpa provenance, approval yang kedaluwarsa, serta action gagal yang diulang. Alarm harus menunjuk task dan artefak terkait, bukan hanya memberi angka anomali global.

Governance bekerja jika setiap risiko punya orang yang dapat mengambil keputusan. Security owner dapat menutup connector; data owner memutuskan validitas sumber; business owner menentukan apakah workflow layak dibuka kembali. Tanpa pembagian itu, audit log hanya menjadi arsip kebingungan.

Kesimpulan praktis

Risiko utama second brain bukan AI tiba-tiba menjadi makhluk otonom. Risiko yang lebih dekat adalah data salah yang bertahan, akses terlalu lebar, retrieval lintas scope, dan action tanpa verifikasi.

Kontrol intinya jelas: provenance, isolation, least privilege, lifecycle, approval, dan audit. Bila tim belum dapat menunjukkan siapa menulis memory, siapa membacanya, kapan ia kedaluwarsa, dan action apa yang dipicu, sistem belum layak memegang konteks bisnis penting.

Incident response khusus memory

Playbook incident perlu mampu menghentikan write dan action tanpa mematikan akses bukti. Ketika poisoning ditemukan, karantina memory terkait, cari semua turunannya, identifikasi task yang pernah mengambilnya, dan review action yang sudah terjadi. Menghapus satu record sumber belum cukup jika summary atau embedding masih aktif.

Sediakan identifier yang konsisten agar lineage dapat ditelusuri. Catat kapan memory dibuat, dari objek mana, transformasi apa yang dijalankan, dan memory baru apa yang diturunkan. Ini membuat blast radius dapat dihitung.

Setelah containment, perbaiki kontrol yang gagal: validation, authority rule, scope filter, atau approval. Jangan sekadar menambah prompt "lebih berhati-hati". Lalu jalankan ulang evaluation yang mereproduksi incident sebelum action dibuka kembali. Governance yang nyata terlihat ketika kondisi buruk terjadi, bukan saat dashboard semuanya hijau.

Referensi primer

• NIST -- AI Risk Management Framework
• NIST -- Generative AI Profile
• OWASP -- Top 10 for LLM Applications
• Model Context Protocol -- Security Best Practices
• OpenAI -- Memory and New Controls for ChatGPT

← Artikel sebelumnya · Hub Second Brain · Artikel berikutnya →