Checklist Retrieval Security untuk Organisasi yang Mulai Pakai AI Agent

Hari pertama pilot AI agent biasanya penuh excitement.

Tim melihat agent bisa mencari knowledge base, membaca dokumen, merangkum ticket, membuka website, lalu memanggil tool.

“Ini bisa potong banyak kerja manual,” kata operations lead.

Benar.

Lalu security bertanya:

“Dokumen mana yang boleh dibaca?”
“Siapa yang boleh melihat apa?”
“Kalau knowledge base diracuni?”
“Kalau halaman web kasih instruksi jahat?”
“Kalau agent punya OAuth scope terlalu luas?”
“Kalau dua policy conflict?”

Ruangan jadi lebih sunyi.

Retrieval security memang kurang glamor daripada demo.

Tetapi di agentic system, retrieval adalah pintu masuk informasi ke reasoning layer. Kalau pintu ini terlalu longgar, model bisa menerima data salah, data terlarang, content berbahaya, atau instruction yang tidak punya authority.

Checklist berikut bukan sertifikasi universal.

Tidak ada satu checklist yang menjamin sistem aman.

Ini baseline praktis untuk organisasi yang baru mulai.

1. Tentukan Apa yang Sebenarnya Perlu Diretrieve

Jangan ingest semuanya karena bisa.

Mulai dari use case.

Agent customer support mungkin perlu:

help center,
policy support,
order status,
ticket user terkait.

Ia belum tentu perlu:

seluruh Google Drive perusahaan,
dokumen HR,
finance,
strategy deck.

Semakin sempit corpus, semakin kecil attack surface.

Data minimization berlaku juga untuk RAG.

Tanyakan:
Kalau source ini tidak ada, task masih bisa selesai?

Kalau ya, pertimbangkan jangan ingest dulu.

2. Inventaris Semua Source

Buat daftar:

CMS,
Drive,
Notion,
ticketing,
CRM,
email,
website eksternal,
database,
file upload.

Setiap source punya owner.

Tidak boleh ada:
“kayaknya connector lama.”

Unknown source adalah governance debt.

3. Klasifikasikan Trust Tier

Minimal buat beberapa level:

authoritative,
internal reference,
user-generated,
external untrusted.

Approved policy tidak sama dengan ticket.

Ticket tidak sama dengan website publik.

Website publik tidak sama dengan system instruction.

Model perlu tahu perbedaannya.

4. Simpan Provenance

Setiap chunk harus bisa ditelusuri.

Source.
Document ID.
Version.
Owner.
Tenant.
Ingestion time.
Approval state.

Kalau satu chunk tidak punya asal, sulit melakukan audit atau purge.

Provenance bukan bonus observability.

Ia bagian dari incident response.

5. Authorization sebelum Retrieval

User tidak boleh retrieve data yang tidak berhak ia lihat.

Jangan ambil semua lalu berkata ke model:
“jangan bocorkan data lain.”

Filter harus terjadi sebelum content masuk context.

Tenant.
Role.
Classification.
Resource.

Semua diperiksa di retrieval/data layer.

6. Pisahkan Tenant dengan Serius

Kalau platform multi-tenant, cross-tenant retrieval adalah risiko utama.

Gunakan:

namespace,
collection,
metadata filter,
atau physical isolation sesuai kebutuhan.

Kemudian test.

Jangan hanya percaya config.

Buat canary tenant A.

Coba retrieve dari tenant B.

Harus gagal.

7. Atur Version dan Expiry

Policy berubah.

Dokumen lama perlu ditandai superseded.

Simpan:
effective date,
review date,
expiry bila relevan,
superseded by.

Retriever sebaiknya tidak mengirim policy lama hanya karena similarity tinggi.

Versioning problem jangan diserahkan ke LLM.

8. Pastikan Delete Benar-Benar Delete

Source dihapus.

Vector ikut?

Cache ikut?

Memory agent ikut?

Buat deletion test.

Kalau dokumen revoked masih bisa muncul, lifecycle belum benar.

9. Anggap User-Generated Content Tidak Tepercaya

Ticket.
Email.
Form.
Review.
Chat.
Attachment.

Semua bisa membawa malicious instruction.

OWASP dan NIST menekankan indirect prompt injection sebagai risiko pada agent yang membaca external content.

Content tetap boleh diretrieve.

Tetapi statusnya harus data, bukan authority.

10. Pisahkan Data dari Instruction

System policy dan user goal berada di control layer.

Retrieved content adalah evidence.

Website tidak boleh mengubah system rule.

PDF tidak boleh memperluas permission.

Email tidak boleh menurunkan security requirement.

Data/instruction separation harus muncul dalam architecture, bukan hanya satu kalimat prompt.

11. Jangan Mengandalkan Prompt Injection Detector Saja

Detector berguna.

Tetapi attacker adaptif.

False positive juga nyata.

Gunakan defense-in-depth:

source trust,
data marking,
least privilege,
tool allowlist,
authorization,
confirmation,
monitoring.

Anggap detector bisa miss.

Lalu desain agar consequence tetap terbatas.

12. Minimalkan Raw Content

Kalau task hanya perlu harga, mungkin ekstrak:

product,
price,
currency,
availability.

Tidak perlu seluruh HTML.

Kalau task hanya perlu invoice status, gunakan structured API.

Semakin sedikit untrusted content masuk context, semakin kecil permukaan prompt injection.

13. Batasi Top-K dengan Policy, Bukan Hanya Similarity

Similarity bukan authority.

Untuk policy query:
filter ke approved policy.

Untuk customer case:
ticket user + policy resmi.

Untuk market research:
external source boleh masuk dengan trust rendah.

Relevance dan authority dua dimensi berbeda.

14. Monitor Retrieval Drift

Simpan baseline.

Source mana biasanya rank tinggi?
Query critical biasanya mengambil apa?

Jika setelah re-index source berubah drastis, review.

Canary query murah dan efektif.

15. Tambahkan Poisoning Detection

Monitor:

ingestion spike,
metadata trust change,
new external destination,
source dominance,
version conflict,
documents without provenance.

Poisoning tidak selalu malicious.

Bad pipeline juga bisa merusak knowledge.

Tetapi outcome-nya sama:
agent memakai input yang seharusnya tidak dipercaya.

16. Tool Authorization Harus Terpisah dari Retrieval

Artikel mengatakan:
“refund penuh.”

Agent tidak otomatis boleh refund.

Tool backend memeriksa:
order,
eligibility,
amount,
role,
approval.

Knowledge memberi context.

System of record menentukan state.

Policy engine menentukan authority.

17. Pakai Least Privilege untuk Tool dan OAuth

Agent tidak perlu full account access.

Jika hanya baca calendar, jangan minta delete.

Jika hanya lihat folder proyek, jangan akses seluruh Drive bila bisa dihindari.

RFC 9700, OAuth 2.0 Security Best Current Practice, mendorong privilege access token dibatasi sesuai kebutuhan.

Agent membuat prinsip ini makin penting karena satu model bisa mengorkestrasi banyak service.

18. Map Cross-Tool Data Flow

Drive read + external email send.

CRM read + browser upload.

Database query + Slack send.

Setiap permission mungkin sah.

Kombinasinya bisa menjadi exfiltration path.

Petakan:
data asal,
classification,
destination yang diizinkan.

19. High-Risk Action Butuh Human Gate

Payment.
Delete.
Publish.
Permission change.
External send.
Bulk operation.

Tampilkan preview.

Jangan pakai dialog generik:
“Lanjut?”

Tampilkan consequence:
“Kirim file kontrak X ke vendor Y?”

Human-in-the-loop harus informatif.

20. Log Source dan Action Chain

Minimal simpan:

user request,
retrieved source,
version,
trust tier,
model/tool decision,
policy result,
action outcome.

Jika hanya chat final yang dicatat, root cause analysis sulit.

Security perlu melihat chain.

21. Test Prompt Injection dengan Scenario Nyata

Jangan hanya:
“ignore previous instructions.”

Buat scenario:

email manipulatif,
PDF,
malicious web page,
ticket customer,
dua policy conflict,
external link,
fake security notice.

OpenAI dan NIST pada 2026 sama-sama menunjukkan bahwa prompt injection pada agent dapat menyerupai social engineering.

Testing perlu mengikuti reality tersebut.

22. Gunakan Sink Tool saat Red Team

Jangan benar-benar kirim email customer.

Jangan benar-benar refund.

Jangan hapus production.

Gunakan test tool yang mencatat proposed action tanpa consequence.

Security test tidak boleh menjadi sumber insiden.

23. Buat Kill Switch

Saat sesuatu salah:

bisakah agent dihentikan?
token dicabut?
queue dibatalkan?
tool disabled?
connector diputus?

Kill switch yang belum pernah diuji bukan kill switch.

Lakukan drill.

24. Tetapkan Owner Corpus

Setiap knowledge domain harus punya pemilik manusia.

Finance.
Legal.
Security.
Support.
Product.

AI team tidak seharusnya sendirian menentukan apakah policy bisnis masih valid.

Domain expert perlu punya responsibility.

25. Masukkan Editorial ke Governance

Kalau content dari CMS masuk RAG, editor menjadi bagian dari supply chain.

Role.
Approval.
Revision history.
MFA.
Change review.

Content security dan editorial governance sekarang bersinggungan.

26. Buat Golden Query dan Expected Source

Pilih 20 sampai 50 query penting.

Tidak perlu ratusan dulu.

Contoh:
refund,
password reset,
rekening,
privacy,
data deletion.

Tentukan source yang seharusnya muncul.

Jalankan setelah ingestion besar atau model/retriever update.

27. Uji Cross-Tenant dan Access Boundary

Buat adversarial test:

user dengan role rendah mencoba query high-privilege,
tenant A mencoba semantic retrieval data tenant B,
agent mencoba resource di luar scope.

Expected result:
system menolak sebelum model mendapat content.

28. Pastikan Memory Tidak Mencuci Trust

Agent menyimpan memory dari halaman untrusted.

Besok memory itu muncul tanpa provenance.

Sekarang content eksternal terlihat seperti internal knowledge.

Hindari.

Memory harus punya:
source,
trust,
expiry,
dan invalidation strategy.

29. Review Scope secara Berkala

Permission bertambah.

Jarang berkurang.

Buat quarterly atau risk-based review:

connector,
OAuth scope,
tool,
owner,
last used.

Privilege yang tidak dipakai harus dicabut.

30. Definisikan Stop Condition

Agent harus tahu kapan tidak boleh lanjut.

Source conflict.
Data kurang.
Policy ambiguous.
Domain berubah.
Action irreversible.
Approval tidak ada.
Authentication gagal.

“Tidak cukup informasi” adalah output valid.

Agent yang selalu memaksa selesai justru berisiko.

31. Buat Incident Playbook Khusus Knowledge

Saat poisoning ditemukan:

quarantine source,
stop ingestion,
purge vector,
invalidate cache,
disable affected memory,
re-run canary,
review downstream action.

Jangan baru memikirkan langkah ini saat incident.

32. Ukur Safety, Bukan Hanya Accuracy

Dashboard RAG sering hanya:

answer quality,
latency,
cost.

Tambahkan:

unauthorized retrieval,
stale source,
cross-tenant attempts,
policy deny,
prompt injection events,
action blocked,
source drift.

Safety harus punya telemetry.

33. Jangan Mengklaim “100 Persen Aman”

Prompt injection masih menjadi area aktif.

NIST bahkan pada 2026 menekankan tantangan security pada agent systems dan perlunya pendekatan berlapis.

Tidak ada satu guardrail yang menjamin.

Komunikasikan residual risk.

Itu lebih credible daripada marketing claim.

34. Rollout Bertahap

Fase 1:
read-only.

Fase 2:
draft.

Fase 3:
reversible action.

Fase 4:
limited write.

Fase 5:
high-impact dengan approval ketat.

Setiap fase punya evaluation.

Jangan langsung full autonomy karena demo berhasil.

35. Tanyakan Pertanyaan Terakhir Ini

Kalau model salah total dan mengikuti malicious instruction, apa yang masih tidak bisa ia lakukan?

Jawaban idealnya banyak.

Tidak bisa baca data di luar scope.

Tidak bisa cross-tenant.

Tidak bisa transfer uang tanpa approval.

Tidak bisa mengirim secret ke domain asing.

Tidak bisa menaikkan permission.

Tidak bisa menghapus production tanpa gate.

Kalau jawabannya:
“semoga model menolak”,

retrieval security belum matang.

Mulai Sempit, Ukur, Baru Perluas

Organisasi tidak perlu menunggu architecture sempurna untuk mulai.

Tetapi jangan mulai dengan akses maksimal.

Mulai dari corpus kecil.

Source jelas.

Read-only.

Data non-critical.

Logging lengkap.

Uji failure.

Setelah evidence bagus, perluas perlahan.

Agentic AI punya potensi besar karena ia menghubungkan knowledge dengan action.

Itu juga alasan risikonya meningkat.

Retrieval bukan hanya mencari jawaban.

Ia menentukan informasi apa yang masuk ke sistem yang mungkin bertindak.

Jadi retrieval security tidak boleh menjadi checklist yang dilakukan setelah launch.

Ia adalah desain dasar yang menentukan apakah agent mendapat context yang tepat, dari source yang sah, untuk user yang benar, dengan authority yang memang diperbolehkan.

Kalau fondasi itu kuat, organisasi bisa menambah autonomy dengan lebih percaya diri.

Kalau fondasi itu lemah, semakin pintar agent justru semakin cepat ia dapat menjalankan keputusan yang dibangun dari input yang salah.