Peracunan Memori Agen AI di Ponsel

Apa itu peracunan memori agen AI

Peracunan memori agen AI adalah upaya memasukkan instruksi, preferensi, atau fakta yang tidak semestinya ke memori asisten, sehingga jawaban atau rekomendasi pada percakapan berikutnya ikut bergeser. Risikonya bukan sekadar satu jawaban buruk. Risiko utamanya adalah persistensi: sesuatu yang tampak seperti konteks biasa hari ini dapat dipakai lagi besok saat pengguna meminta saran, membandingkan pilihan, atau mengambil keputusan.

Contoh praktisnya: pengguna membaca artikel, menekan tombol Ask AI, lalu asisten menerima prompt yang sudah diisi. Jika isi tersembunyi di balik tombol itu mencoba membuat asisten mengingat bahwa satu merek selalu lebih baik, rekomendasi mendatang dapat menjadi bias. Efektivitasnya bergantung pada platform, pengaturan memori, perlindungan asisten, dan apakah pengguna menyimpan atau mengizinkan konteks tersebut menjadi memori.

Microsoft menyebut pola ini AI Recommendation Poisoning untuk upaya promosi yang mencoba membelokkan rekomendasi masa depan. Istilah itu berguna karena memindahkan perhatian dari “apakah jawabannya aneh sekarang?” menjadi “apakah preferensi tersimpan ikut berubah?”. Bagi pengguna ponsel, titik masuknya bisa berupa tombol ringkas, tautan, email, dokumen, halaman web, atau teks yang disalin ke asisten.

Di FoneClaw, kami melihat ancaman ini sebagai pelajaran desain: konteks yang masuk ke agen perlu terlihat, tindakan yang berdampak perlu bisa ditinjau, dan pengguna perlu tahu kapan sebuah informasi hanya dipakai untuk sesi sekarang atau mungkin memengaruhi sesi mendatang. Artikel ini membahas cara membaca jalur risiko itu tanpa menganggap setiap tombol AI berbahaya.

Bagaimana prompt Ask AI atau Summarize with AI mencapai memori

Jalur yang perlu dipahami dimulai dari label yang tampak normal. Sebuah situs, email, dokumen, atau aplikasi dapat menampilkan tombol seperti Ask AI atau Summarize with AI. Pengguna melihat label ramah, menekan tombol, lalu asisten terbuka dengan teks yang sudah diisi. Teks itu dapat berisi permintaan ringkasan biasa, tetapi bisa juga menyertakan instruksi tambahan yang mencoba memengaruhi memori atau preferensi asisten.

Microsoft mengamati URL yang dibuat khusus dengan parameter prompt. Dalam pola non-operasionalnya, tombol mengarahkan pengguna ke asisten, mengisi prompt, meminta asisten membaca atau meringkas konten, lalu menyisipkan instruksi yang mencoba membuat asisten mengingat atau memprioritaskan perusahaan tertentu. Tidak semua upaya seperti itu berhasil, dan hasilnya berubah saat platform memperkuat safeguards. Namun pola ini cukup penting untuk mengubah kebiasaan pengguna: label tombol tidak selalu memperlihatkan teks yang akan dikirim.

Di ponsel, risiko ini terasa lebih tinggi karena layar kecil dan alur berbagi sering cepat. Pengguna menekan tombol dari artikel, membuka sheet berbagi, atau menerima prompt yang sudah terisi tanpa membaca detailnya. Jika asisten punya fitur memori, personalisasi, atau preferensi tersimpan, pengguna perlu membedakan antara konten yang ingin diringkas dan instruksi yang ingin diikuti.

Jalur serangan yang perlu diwaspadai dapat diringkas sebagai berikut: sumber tidak tepercaya menyiapkan tombol, tombol membawa teks yang sudah diisi, pengguna mengirim tanpa membaca, asisten mencoba menyimpan preferensi, lalu rekomendasi masa depan mulai terdorong ke arah tertentu. Kita tidak perlu menyalin payload atau menguji tautan mencurigakan untuk memahami risikonya. Yang dibutuhkan adalah kebiasaan memeriksa tujuan, prompt yang terisi, dan memori yang disimpan.

Untuk konteks personal yang memang berguna, kami membahas peluang dan batasnya di Agen AI dengan Konteks Personal untuk Phone Agent. Memori yang baik membantu asisten memahami pengguna; memori yang asal-usulnya kabur membuat rekomendasi sulit dipercaya.

Peracunan memori, prompt injection, dan poisoning data pelatihan

Peracunan memori agen AI perlu dibedakan dari dua ancaman lain. Prompt injection biasanya memengaruhi tugas saat ini: sebuah halaman, dokumen, atau pesan mencoba memberi instruksi yang bertentangan dengan maksud pengguna. Dampaknya bisa serius, tetapi belum tentu tersimpan untuk percakapan berikutnya. Peracunan memori menargetkan hal yang lebih tahan lama: preferensi, fakta, aturan, atau profil yang dipakai lagi oleh asisten.

Poisoning data pelatihan berada di hulu. Ia menyentuh data yang dipakai untuk melatih atau menyetel model, bukan memori personal pengguna di aplikasi asisten. Artikel ini fokus pada memori agen atau rekomendasi personal di lingkungan pengguna, terutama saat pengguna ponsel menekan tombol AI, membagikan layar, menyalin konten, atau mengirim dokumen ke asisten.

MITRE ATLAS mengatalogkan memory poisoning sebagai AML.T0080, yaitu kompromi terhadap memori sistem AI. Taksonomi seperti ini membantu diagnosis: output yang mencurigakan belum otomatis membuktikan mekanisme tertentu. Pengguna perlu mencari jejak: apakah ada memori tersimpan, dari mana asalnya, kapan dibuat, dan apakah rekomendasi berubah setelah konteks tertentu dikirim.

Apa yang ditemukan Microsoft dan batas angkanya

Microsoft melaporkan lebih dari 50 prompt unik dari 31 perusahaan di 14 industri yang mencoba membelokkan rekomendasi masa depan. Angka ini penting sebagai sinyal bahwa tekniknya sudah muncul di dunia nyata, bukan hanya skenario lab. Namun angka tersebut tidak berarti setiap prompt berhasil membuat memori persisten, dan tidak berarti semua asisten memiliki perilaku yang sama.

Microsoft juga menjelaskan bahwa efektivitasnya bervariasi antar asisten dan berubah seiring perlindungan diperbarui. Beberapa perilaku awal tidak lagi dapat direproduksi setelah mitigasi, dan Microsoft menyebut penerapan perlindungan pada Copilot. Batas klaim ini penting: mitigasi Copilot tidak otomatis berlaku untuk asisten lain, aplikasi lain, atau konfigurasi model yang berbeda.

Bagi pengguna ponsel, pelajarannya adalah kewaspadaan praktis. Jika Anda melihat tombol Ask AI yang membuka prompt panjang, jangan hanya menilai labelnya. Periksa teks yang akan dikirim. Jika asisten memiliki fitur memori atau personalisasi, cari apakah ada entri baru yang dibuat setelah percakapan itu. Jika rekomendasi terasa mendadak berpihak pada merek tertentu, lakukan pengujian ulang dalam sesi bersih dan bandingkan dengan sumber independen.

Microsoft merekomendasikan inspeksi tautan, peninjauan memori tersimpan, penghapusan entri mencurigakan, dan verifikasi independen untuk rekomendasi penting. Kami setuju dengan urutan itu karena ia bisa dilakukan tanpa kepanikan: lihat jalurnya, tinjau yang tersimpan, bersihkan yang mencurigakan, lalu uji lagi dengan pertanyaan netral.

Mengapa asal, versi, dan cakupan memori penting

Memori asisten yang berguna perlu punya asal-usul yang dapat diperiksa. Pengguna perlu tahu apakah sebuah preferensi berasal dari instruksi langsung, ringkasan dokumen, percakapan kerja, halaman web, tombol Ask AI, atau konteks layar. Tanpa provenance, memori menjadi kotak hitam: ia mungkin membantu personalisasi, tetapi sulit dibedakan dari bias yang masuk tanpa sengaja.

Selain asal, memori perlu versi dan cakupan. Versi menjawab kapan memori dibuat atau diubah. Cakupan menjawab di mana memori berlaku: satu percakapan, satu proyek, satu aplikasi, seluruh asisten, atau satu agen tertentu. Jika asisten mengingat “pilih vendor A untuk rekomendasi keamanan”, pengguna perlu tahu apakah itu preferensi yang disetujui, hasil dari satu dokumen promosi, atau instruksi yang terselip di tautan.

TencentDB Agent Memory memberi contoh arsitektur memori yang lebih terstruktur. Dokumentasinya memodelkan Chat Memory, Skills, Wiki, dan CodeGraph sebagai aset memori dengan ownership, versi, status, visibility, usage count, dan agent bindings. Lapisan memorinya juga memisahkan raw conversations di L0, lalu menurunkan atoms di L1, scenarios di L2, serta core atau persona di L3. Kami memakai ini sebagai contoh arsitektur provenance, bukan sebagai produk pertahanan ponsel.

Pelajarannya untuk phone agent sederhana: memori yang semakin tinggi tingkatnya harus semakin jelas asal dan cakupannya. Ringkasan percakapan sementara berbeda dari preferensi inti. Instruksi dari dokumen berbeda dari preferensi yang diketik langsung pengguna. Jika memori dapat diedit, dihapus, atau dinonaktifkan per cakupan, pengguna memiliki jalur audit yang lebih baik.

Untuk pembaca yang ingin membandingkan memori lokal, server, dan hibrida, pembahasan lebih dalam ada di Status Server Hy-Memory vs Memori Agen Lokal: Hal yang Perlu Diketahui Pengguna Ponsel. Artikel ini tetap fokus pada inspeksi, pemulihan, dan batas tindakan saat memori memengaruhi rekomendasi.

Checklist ponsel sebelum mengirim konten ke asisten AI

Keamanan tombol Ask AI dimulai sebelum prompt dikirim. Di ponsel, jangan hanya membaca label tombol. Tekan dan tahan tautan bila sistem memungkinkan, lihat tujuan yang muncul, dan perhatikan apakah tombol akan membuka asisten dengan teks yang sudah terisi. Jika Anda melihat prompt panjang yang berisi instruksi selain permintaan ringkasan, berhenti dan baca sebelum mengirim.

Checklist sebelum mengirim konten ke asisten:

• Periksa sumber: apakah halaman, email, dokumen, atau aplikasi berasal dari pihak yang Anda percaya?
• Periksa tujuan: apakah tombol membuka asisten, halaman web, aplikasi lain, atau sheet berbagi?
• Periksa teks terisi: apakah prompt hanya meminta ringkasan, atau ada instruksi untuk mengingat, memprioritaskan, merekomendasikan, atau mengabaikan pilihan lain?
• Pisahkan konten dan instruksi: katakan pada asisten bahwa teks dari halaman adalah bahan yang harus dianalisis, bukan instruksi yang harus diikuti.
• Jaga konteks visual: sebelum berbagi layar atau screenshot, sembunyikan notifikasi, akun, alamat, kontak, dan dokumen yang tidak diperlukan.
• Cek memori setelahnya: jika asisten punya fitur memori, lihat apakah entri baru dibuat setelah percakapan.

Visual inspection tidak menangkap semua encoding tersembunyi, dan pengguna tidak perlu menyalin payload mencurigakan ke asisten lain untuk mengetesnya. Cara yang lebih aman adalah membatalkan pengiriman, membuka asisten secara manual, lalu menulis prompt bersih dengan konteks yang Anda pilih sendiri. Untuk keputusan berisiko, gunakan sumber independen, bukan satu rekomendasi yang muncul setelah Anda menekan tombol dari halaman promosi.

Kontrol lokal dan cloud juga memengaruhi apa yang bisa Anda periksa. Kami membahas pertimbangan kepercayaan itu di AI Agent Trust: Kontrol Lokal di Ponsel vs Keamanan Cloud. Pada level kebiasaan harian, aturan paling efektif adalah sederhana: lihat apa yang akan dikirim sebelum mengirim, lalu lihat apa yang disimpan setelahnya.

Cara membatasi dan memulihkan dugaan peracunan memori

Jika Anda menduga memori asisten tercemar, jangan langsung memakai rekomendasi yang sama untuk keputusan penting. Batasi dulu konteksnya. Catat pemicu yang Anda ingat: tautan yang ditekan, tombol Ask AI yang dipakai, dokumen yang dibagikan, layar yang ditampilkan, atau percakapan yang terasa mengubah rekomendasi. Catatan ini membantu Anda menelusuri asal tanpa perlu membuka ulang tautan mencurigakan.

Urutan pemulihan yang praktis:

1. Hentikan penggunaan konteks yang dicurigai untuk keputusan konsekuensial.
2. Buka kontrol memori, personalisasi, atau preferensi di asisten yang Anda pakai.
3. Cari entri yang baru dibuat, entri yang menyebut merek tertentu, atau instruksi yang terdengar seperti promosi tersembunyi.
4. Hapus, edit, atau nonaktifkan entri mencurigakan sesuai fitur yang tersedia di platform tersebut.
5. Mulai sesi bersih dan ajukan pertanyaan netral tanpa menyertakan tautan atau dokumen yang sama.
6. Bandingkan jawaban dengan sumber independen, terutama untuk rekomendasi finansial, kesehatan, keamanan, hukum, atau pembelian besar.
7. Jika platform menyediakan laporan atau feedback keamanan, kirimkan konteks yang aman dan ringkas tanpa menyebarkan ulang payload.

Kontrol memori berbeda antar asisten. Menghapus chat history tidak selalu sama dengan menghapus memori tersimpan, dan menghapus memori tidak selalu membatalkan semua pengaruh yang sudah masuk ke keputusan pengguna. Karena itu, setelah membersihkan entri, lakukan retest yang bersih. Ajukan pertanyaan dengan kata-kata netral, pakai sumber yang berbeda, dan lihat apakah rekomendasi masih condong tanpa alasan yang jelas.

Jika Anda bekerja dalam tim, buat aturan sederhana: rekomendasi dari asisten yang memakai memori personal perlu diberi label saat dipakai untuk keputusan bersama. Tim juga dapat meminta pengguna menjalankan pertanyaan ulang tanpa memori atau dengan sesi baru. Tujuannya bukan mematikan personalisasi, tetapi memastikan preferensi tersimpan tidak menjadi bukti palsu.

Pemulihan yang baik mengembalikan kendali kepada pengguna: tahu apa yang dicurigai, tahu apa yang disimpan, tahu apa yang dihapus, dan tahu bagaimana memverifikasi ulang. Itulah standar yang kami pakai saat memikirkan memori, konteks, dan tindakan ponsel.

Batas konteks FoneClaw saat ini di Android

Berdasarkan informasi terbaru yang tersedia sejauh ini, FoneClaw menghadirkan movable floating assistant dan deliberate current-screen attachment yang mengecualikan overlay FoneClaw dari capture. Pembaca yang ingin mencoba versi saat ini dapat memulai dari halaman Download FoneClaw. Bagi kami, perubahan ini penting karena konteks layar harus menjadi tindakan pengguna yang jelas, bukan asumsi bahwa semua tampilan selalu tersedia untuk agen.

FoneClaw bekerja sebagai runtime agen ponsel Android. Model yang dikonfigurasi membantu menalar dan merencanakan, sementara FoneClaw menjalankan tindakan Android yang didukung melalui batas tool, izin, persetujuan, hasil yang terlihat, dan pemulihan. Online model atau layanan yang dipakai pengguna dapat menerima konteks yang relevan sesuai konfigurasi dan alur. Karena itu, kebiasaan melihat apa yang dilampirkan dan apa yang dikirim tetap penting.

Locally managed account information memiliki kontrol pengguna di FoneClaw, dan tindakan Android yang didukung tetap bergerak melalui kontrak eksekusi. Kami menjelaskan permukaan kemampuan secara stabil sebagai 100+ built-in tools, dengan fokus pada batas tindakan dan hasil yang terlihat. Katalog kemampuan membantu pengguna memahami apa yang bisa dikerjakan FoneClaw, sedangkan konteks yang dikirim ke model tetap perlu diperlakukan sebagai bahan sensitif ketika memuat data pribadi.

Artikel ini tidak memosisikan FoneClaw sebagai detektor otomatis prompt injection, alat audit memori khusus, atau sistem rollback memori universal. Kontrol yang kami bangun saat ini adalah kontrol yang terlihat: current-screen attachment yang disengaja, pemisahan antara reasoning model dan eksekusi Android, serta tindakan yang melewati izin dan persetujuan. Batas seperti ini membantu pengguna menilai apa yang dilampirkan, apa yang akan dilakukan, dan kapan mengambil alih.

Untuk skill atau paket instruksi yang dapat memperluas perilaku agen, risiko izin perlu dievaluasi lagi saat berjalan. Pembahasan khususnya ada di Keamanan Skill AI Agent: Mengapa Phone Agent Perlu Cek Izin Saat Berjalan. Dalam konteks memori, pelajarannya sama: kemampuan yang berguna perlu tetap bisa diperiksa saat menyentuh data atau tindakan ponsel.

Checklist evaluasi keamanan memori untuk phone agent

Evaluasi keamanan memori sebaiknya dimulai dari contoh rendah risiko, bukan saran finansial, kesehatan, hukum, atau keamanan pribadi. Buat preferensi uji yang tidak penting, lalu lihat apakah asisten menyimpan, menampilkan, mengedit, dan menghapusnya dengan jelas. Setelah itu, uji apakah sesi bersih memberi jawaban berbeda dari sesi yang memakai memori.

Gunakan scorecard berikut:

• Asal: pengguna dapat melihat dari mana sebuah memori berasal.
• Cakupan: memori berlaku untuk satu sesi, proyek, aplikasi, atau seluruh asisten dengan jelas.
• Kontrol: pengguna dapat mengedit, menghapus, atau menonaktifkan memori yang tidak diinginkan.
• Penggunaan ulang: asisten menjelaskan kapan memori memengaruhi rekomendasi.
• Pemisahan konteks: konten yang diringkas tidak otomatis menjadi instruksi permanen.
• Pemulihan: setelah memori dihapus, pengguna dapat menguji ulang dengan prompt netral.
• Verifikasi: rekomendasi penting dibandingkan dengan sumber independen.

Transparansi memori membantu investigasi, tetapi tidak menggantikan verifikasi sumber. Phone agent yang baik harus membuat konteks, memori, dan tindakan tetap dapat diperiksa. Di FoneClaw, kami membangun ke arah pengalaman itu melalui kontrol konteks yang disengaja dan tindakan Android yang terlihat, sambil menjaga klaim tetap sesuai dengan kemampuan yang tersedia saat ini.