—·
Panduan praktis untuk membuktikan kepercayaan AI dalam alur kerja agent yang sensitif keamanan: provenance kriptografis, konteks terautentikasi, pembatasan kapabilitas, dan verifikasi AIBOM berkelanjutan.
Pukul 2.14 dini hari, sebuah agent di dalam SOC memunculkan tool call yang membuka akses ke sistem tiket. Pagi datang dengan template postmortem yang tenang: “Permintaan sudah kami catat.” Namun dalam alur kerja LLM yang bersifat agentic, tim keamanan sering menemukan bahwa log standar tidak menjawab pertanyaan inti: model persis apa yang dipakai, prompt persis apa dan konteks apa yang diambil (retrieved), serta batas kebijakan persis mana yang aktif pada saat tindakan dilakukan? Celah bukti inilah alasan mengapa kepercayaan terhadap AI yang sensitif keamanan tidak bisa diperlakukan semata-mata sebagai persoalan pencatatan.
Celah itu bersifat struktural. Sistem agentic dapat mengubah prompt selama pemakaian tool, menyerap dokumen hasil retrieval, dan mengarahkan eksekusi melalui lapisan orkestrasi. Setelah kejadian, “apa yang terjadi” menjadi sebagian tidak deterministik—kecuali organisasi membangun lini bukti yang memenuhi kualitas forensik, dari tahap penyerapan (ingestion) hingga eksekusi. Sekumpulan benang riset tentang agentic bills of materials (AIBOMs) dan zero-trust proofs tentang perilaku AI bertemu pada satu kesimpulan: kepercayaan membutuhkan artefak provenance end-to-end, bukan narasi retrospektif. (arxiv.org/abs/2603.10057).
Agar editorial ini berpijak pada standar yang bisa diverifikasi, bukan pada prinsip yang abstrak, pikirkan tiga fondasi yang sudah mulai matang:
Tekanan untuk mempercayai AI agentic bukanlah gagasan yang abstrak. Tekanan ini sudah tampak dalam cara pemerintah dan lembaga keamanan memperlakukan “minimum elements” serta ekspektasi bukti bagi software supply chains.
Sebagai respons terhadap Executive Order 14028, NTIA menerbitkan “Minimum Elements for a Software Bill of Materials (SBOM)” pada 12 Juli 2021. Dokumen itu mengaitkan atribut SBOM dengan otomasi dan respons terhadap kerentanan—secara efektif menjadikan data provenance sebagai prasyarat pengadaan dan ketergantungan operasional. (ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom).
CISA kemudian melanjutkan program SBOM, termasuk kerja untuk panduan “Minimum Elements” yang diperbarui melalui proses public-comment untuk 2025 Minimum Elements for a Software Bill of Materials (SBOM). Pentingnya siklus pembaruan ini adalah sinyal bahwa kematangan SBOM diperkirakan terus berkembang, bukan berhenti membeku pada satu skema. (cisa.gov/news-events/news/cisa-issues-draft-software-bill-materials-guide-public-comment, cisa.gov/sbom).
NIST SP 800-207 mendefinisikan Zero Trust Architecture (ZTA) dan menyediakan model-model umum penerapan, di mana kepercayaan tidak diasumsikan dari lokasi jaringan. Sebaliknya, pendekatannya bergantung pada verifikasi berkelanjutan untuk identitas, akses, dan perilaku. Kerangka konseptual inilah yang diperlukan ketika “client”-nya adalah agent LLM dan “server”-nya adalah antarmuka tool. Kepercayaan harus dibangun ulang per tindakan, per permintaan, dan per batas. (csrc.nist.gov/pubs/sp/800/207/final, nist.gov/publications/zero-trust-architecture-0).
NIST merilis Generative Artificial Intelligence Profile (NIST AI 600-1) pada 26 Juli 2024 sebagai pendamping khusus Generative AI untuk AI Risk Management Framework (AI RMF 1.0). Dokumen ini mengidentifikasi 12 risiko yang unik untuk, atau diperparah oleh, generative AI, serta menyediakan 200+ suggested actions. Angka-angka itu penting secara operasional: “kepercayaan” harus direkayasa lintas banyak objektif kontrol, bukan sekadar pemantauan model. (nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence).
Jadi apa: Perlakukan “trust evidence” sebagai antarmuka kepatuhan yang terus berevolusi, lengkap dengan kriteria penerimaan yang bisa diuji. Pipeline assurance harus meng-versi (a) skema provenance yang diwajibkan dan (b) langkah verifikasi yang membuktikannya. Secara konkret, ketika panduan diperbarui, organisasi perlu mampu menjawab tiga pertanyaan ini dalam satu garis waktu insiden: (1) field bukti mana yang diwajibkan pada saat itu, (2) bagaimana setiap field divalidasi (misalnya verifikasi signature, rekalkulasi digest, pengaitan log mediasi), dan (3) apa yang dimaksud “replayability” untuk rilis tersebut—bukan sekadar “log sudah kami simpan.” Targetnya adalah mengubah “bukti” menjadi sesuatu yang bisa diperiksa, di-diff, dan diuji regresinya seperti CI oleh seorang reviewer.
Pencatatan standar bisa diperlukan, tetapi sering tidak cukup karena umumnya menangkap peristiwa, bukan lini bukti dengan kualitas yang teruji. Sistem agentic tidak berjalan seperti graf panggilan yang lurus. Ia memiliki loop umpan balik (output model menjadi input), tool calls (output tool menjadi konteks), serta keputusan orkestrasi (agent memutuskan tool apa yang dipanggil dan kapan).
Dua bentuk keruntuhan pembuktian yang spesifik kerap muncul:
Meski prompt awal pengguna disimpan, prompt efektif yang benar-benar dipikirkan model bisa bergeser setelah retrieval, setelah output tool, dan setelah overlay kebijakan sistem. Artinya, audit log mungkin mencatat “pesan asisten” final—tetapi tidak merekam prompt/konteks terautentikasi yang persis menghasilkan setiap tool invocation. Dalam istilah provenance kriptografis, yang dibutuhkan bukan hanya pernyataan integritas untuk keadaan akhir, melainkan untuk langkah-langkah antara.
Arsitektur zero-trust menyatakan tidak ada asumsi trust berdasarkan lokasi sesuatu dijalankan. Pada AI agentic, “di mana” sering stabil, tetapi “siapa” dan “niat apa” dapat berubah per tindakan. Ketika tool call terjadi, yang harus diverifikasi adalah (a) permintaan tindakan agent terotorisasi, (b) input untuk tindakan itu terlindungi integritas (authenticated context), dan (c) eksekusi dimediasi sehingga agent tidak dapat mengeskalasi privilese secara diam-diam.
Riset tentang AIBOMs dan evaluasi reproduksibilitas agentic secara eksplisit membingkai trust sebagai bergantung pada kemampuan merekonstruksi lingkungan dan dependensi runtime dengan penalaran yang peka kebijakan. Ini sejalan dengan problem pembuktian: bila konteks eksekusi tidak bisa direkonstruksi, klaim tidak bisa diverifikasi setelah kejadian. (arxiv.org/abs/2603.10057).
Jadi apa: Naikkan rancangan assurance dari “catat semuanya” menjadi “ikat semuanya.” Setiap tindakan yang menyeberangi batas trust harus ditautkan ke lineage yang dicek integritasnya: identitas model, lineage prompt/konteks, identitas tool, serta batas kebijakan yang aktif saat runtime.
Provenance model dan integritas supply chain sering dibicarakan seolah hanya satu lapisan. Padahal, diperlukan tiga lapisan provenance, karena setiap lapisan menjawab pertanyaan yang berbeda.
Ini adalah identitas supply chain dari model itu sendiri. Dibutuhkan pengenal yang bisa diverifikasi untuk artefak model yang dipakai saat runtime: nama model, versi atau digest, serta attestasi provenance dari proses build internal (atau bukti yang dipublikasikan vendor). Tanpa ini, insiden “prompt sama, bobot model berbeda” tidak dapat dibedakan dari insiden yang bermula dari prompt injection.
Lineage prompt/konteks menjawab: byte persis apa yang dilihat model? Ini mencakup instruksi sistem, dokumen yang diambil (retrieved), output tool yang dirangkum atau disisipkan ke konteks, serta overlay kebijakan apa pun. Untuk konteks yang sensitif keamanan, constructed prompt sebaiknya diperlakukan sebagai artefak perantara yang memiliki jaminan integritas.
Dalam alur agentic, artefak perantara adalah medan pertarungan yang sebenarnya: cuplikan retrieval yang di-cache, respons tool, penulisan memori, dan rencana eksekusi. Rantai integritas kriptografis (hash chain) atau attestasi bertanda tangan (pernyataan integritas) yang dihasilkan pada fase build atau runtime memungkinkan verifikasi bahwa artefak perantara tidak diubah antara “generasi yang dipercaya” dan “konsumsi saat tool-use.” Benang riset AIBOM menekankan propagasi klaim keter-eksploitasian kontekstual dengan menggabungkan bukti eksekusi runtime dan penggunaan dependensi, alih-alih memeriksa prompt secara terpisah. (arxiv.org/abs/2603.10057).
Ilustrasi praktis tentang cakupan “authenticated context” dapat dilihat pada pertahanan vendor terhadap indirect prompt injection pada sistem agent. Microsoft mendeskripsikan indirect prompt injection sebagai serangan di mana konten pihak ketiga (misalnya dokumen atau email) menyisipkan instruksi tersembunyi yang mungkin dieksekusi AI. Pendekatan “Prompt Shields” mereka dirancang untuk mendeteksi dan memblokir prompt injection sebelum mencapai foundation model pada Azure AI Content Safety. Bahkan bila pagar pengaman vendor dipandang sebagai defense-in-depth, kerangka mereka menunjukkan realitas operasional: batas trust model ditembus oleh konteks dari luar sistem of record organisasi. (microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks/, azure.microsoft.com/en-us/products/ai-services/ai-content-safety).
Jadi apa: Untuk setiap tindakan agent pada workflow yang sensitif keamanan, wajibkan pengikatan integritas antara (1) digest artefak model, (2) digest authenticated constructed prompt/konteks, dan (3) digest argumen tool call. Bila pengikatan itu tidak bisa dihasilkan, investigasi, rollback, maupun pembuktian kepatuhan tidak akan bermakna.
Zero-trust architecture adalah doktrin keamanan jaringan, tetapi pemetaannya ke AI agentic sangat jelas karena “attack surface” merupakan antarmuka antara input yang tidak tepercaya dan kapabilitas berprivilegio. Model ZTA NIST SP 800-207 mengasumsikan verifikasi berkelanjutan, bukan trust implisit. Itu menjadi aturan desain untuk LLM agents dan antarmuka tool mereka. (csrc.nist.gov/pubs/sp/800/207/final).
Capability scoping adalah cara mengubah kebijakan menjadi kode. Sebuah “capability” adalah izin spesifik untuk melakukan operasi, misalnya “membaca tiket X” atau “membuat insiden Y.” Least privilege berarti memberi hanya kumpulan kapabilitas terkecil yang diperlukan untuk tugas, dan dilakukan secara terpisah untuk setiap batas.
Pada penerapan agentic, scoping harus ada pada tiga titik:
Authenticated prompts/context adalah bukti asal-usul (proof-of-origin). Alih-alih mempercayai bahwa prompt yang disajikan ke model adalah “yang dibangun,” organisasi menambahkan metadata integritas dan identitas (digest dan signature). Mediasi eksekusi yang diverifikasi adalah gerbang runtime yang menegakkan otorisasi bahkan bila output model dipengaruhi secara adversarial.
Ini penting karena perilaku agent bisa bergeser. Zero-trust architecture mengharapkan verifikasi berkelanjutan dan mengasumsikan kemungkinan kompromi. Pada AI agentic, itu berarti otorisasi per tindakan dan pengecekan integritas, bukan “percaya sekali” saat sesi dimulai. (csrc.nist.gov/pubs/sp/800/207/final).
Jadi apa: Implementasikan tool agent sebagai layanan terautentikasi secara terpisah di balik lapisan mediasi yang memeriksa dua hal: (a) otorisasi agent atas capability yang diminta dan (b) integritas lineage prompt/konteks yang menghasilkan permintaan tersebut.
SBOM (Software Bill of Materials) membuat supply chains terlihat dengan cara mencantumkan komponen software serta relasi di antaranya. AIBOM memperluas gagasan tersebut ke sistem yang diberdayakan AI, di mana dependensi tidak hanya mencakup kode yang dikompilasi: model, embeddings, tool plugins, lapisan orkestrasi, batas kebijakan, dan dependensi konteks runtime.
Rangkaian akademik memperkenalkan agentic AIBOMs sebagai “agentic Artificial Intelligence Bills of Materials,” yakni memperluas SBOM menjadi artefak provenance aktif melalui penalaran otonom yang dibatasi kebijakan. Gagasan utamanya adalah menghasilkan bukti ketergantungan kontekstual dan pemantauan drift, serta penalaran kerentanan yang ditautkan ke bukti eksekusi. (arxiv.org/abs/2603.10057).
Secara paralel, OWASP memiliki “AI SBOM Initiative” yang menjelaskan perluasan transparansi dan keamanan untuk AI supply chains lewat konsep AIBOM serta menekankan pendekatan terbuka dan distandardisasi. Walau inisiatif ini masih berkembang, keberadaan upaya ekosistem menandai arah yang praktis: AIBOM kemungkinan membutuhkan skema dan tool generasi yang mirip praktik SBOM. (owaspaibom.org/, genai.owasp.org/ai-sbom-initiative/).
Agar AIBOM tidak menjadi “dokumen yang tidak pernah diverifikasi,” petakan ke kontrol yang sudah dijalankan untuk SBOM:
Benang riset agentic AIBOM secara eksplisit merujuk pada reproducibility evaluation dan runtime dependency drift monitoring agents sebagai bagian dari arsitektur. Ini mendukung sikap operasional: jalankan pengumpulan bukti yang berkelanjutan dan bandingkan dengan graf dependensi yang diharapkan—bukan hanya mengarsipkan artefak. (arxiv.org/abs/2603.10057).
Jadi apa: Perlakukan AIBOM sebagai graf dependensi yang hidup, dengan output provenance yang bisa diverifikasi. Tim keamanan seharusnya meminta rilis agentic mengirimkan paket bukti (evidence bundle) yang mengikat policy, identitas model, dan dependensi tool/plugin ke verifikasi runtime.
Playbook ini mengubah konsep trust menjadi alur kerja yang dapat diterapkan serta diaudit oleh engineer dan operator keamanan.
Pada tahap ingestion/build, dibuat artefak provenance:
Gunakan disiplin SBOM sebagai templat untuk “field yang siap otomasi,” karena SBOM minimum elements dirancang untuk mendukung respons terhadap kerentanan dan otomasi. Laporan minimum-elements dari NTIA menjadi asal kebijakan bagi tujuan otomasi operasional itu. (ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom, ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf).
Buatnya testable: untuk setiap rilis agent, simpan “evidence bundle manifest” dengan field skema yang di-versi (misalnya model_digest, prompt_context_digest, policy_id, tool_capability_ids, signature_chain, build_environment_fingerprint). Reviewer harus bisa memvalidasi manifest secara offline dengan meng-hash ulang artefak yang dirujuk dan memverifikasi rantai signature—sebelum log runtime pernah ada.
Saat runtime, tool tidak seharusnya “tersedia karena agent bisa memanggilnya.” Tool harus dipagari oleh capability scoping:
Kaitkan ke ZTA: verifikasi identitas dan akses secara berkelanjutan, bukan mempercayai status sesi. (csrc.nist.gov/pubs/sp/800/207/final).
Detail operasional yang wajib ada dalam design reviews: lapisan mediasi minimal harus menerima tool identifier, capability identifier, constructed-context digest, dan tool-call argument digest—serta harus mencatat “mediation decision record” yang menautkan capability yang diotorisasi ke digest-digest tersebut. Tanpa penautan ke digest, penegakan akan berubah menjadi event log, bukan pembuktian.
Untuk setiap aksi tool agent, hasilkan evidence record yang mencakup:
Inilah lapisan “proof” yang tidak dapat diperoleh hanya dari log standar. Bila lineage bisa diverifikasi, organisasi juga dapat mendeteksi celah integritas yang tampak seperti prompt injection atau kontaminasi supply chain.
Mekanisme verifikasi yang perlu diimplementasikan: perlakukan constructed prompt/context sebagai artefak perantara dengan representasi deterministik (atau langkah canonicalization). Lalu pada runtime, rekalkulasi prompt_context_digest dari artefak perantara yang tersimpan dan pastikan cocok dengan digest yang ditegaskan pada mediation decision record. Bila digest tidak cocok, sistem harus “fail closed” (menolak tool call) atau menandai tindakan sebagai “unprovable” lalu mengisolasinya (quarantine).
Pemulihan harus berkualitas bukti, artinya organisasi mampu:
Ini selaras dengan pemikiran agentic AIBOM: bukti runtime dan pemanfaatan dependensi memberi daya bagi penalaran kerentanan dan pemantauan drift. (arxiv.org/abs/2603.10057).
Buat kriteria rollback secara eksplisit: replay hanya boleh berhasil bila (1) lapisan mediasi menyetujui jalur capability yang sama, (2) model digest identik, dan (3) reconstructed prompt/context digest sama dengan digest pada evidence bundle. Jika tidak, recovery menghasilkan “replay divergence report” yang menjelaskan tepat di mana rekonstruksi gagal—apakah mismatch kebijakan, perubahan prompt/context, atau dependency drift.
Sistem agentic bergerak cepat, dan insiden nyata menunjukkan bagaimana batas trust runtuh saat bukti tidak lengkap atau mediasi tidak ada.
OpenAI mempublikasikan pembaruan tentang pengerasan ChatGPT Atlas terhadap prompt injection dan mendeskripsikan keberhasilan deteksi setelah pembaruan keamanan. Peristiwa ini relevan bukan sebagai “teknologi selebritas,” melainkan sebagai demonstrasi konkret tentang kategori risiko prompt injection dalam agentic browsing dan automasi tindakan. (openai.com).
OpenAI juga menerbitkan panduan untuk merancang agent agar tahan prompt injection, termasuk strategi mitigasi seperti Safe Url untuk mencegah transmisi informasi sensitif yang dipelajari secara tidak diinginkan. (openai.com).
Penanda timeline:
Pelajaran: Guardrails mengurangi risiko, tetapi tidak menggantikan provenance dan mediasi. Tim tetap perlu menuntut authenticated prompts/context lineage serta tool mediation agar hasil mitigasi menjadi bukti yang bisa dipertanggungjawabkan, bukan sekadar cerita.
Blog keamanan Microsoft (29 Juli 2025) menjelaskan indirect prompt injection sebagai salah satu teknik yang banyak dipakai dan memperkenalkan “Prompt Shields” sebagai API terpadu dalam Azure AI Content Safety. Ini merupakan pernyataan vendor yang kredibel tentang bagaimana pertahanan runtime diintegrasikan sebelum input mencapai foundation model. (microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks/).
Timeline:
Pelajaran: Indirect prompt injection mengubah konten retrieval atau konten pihak ketiga menjadi pembawa instruksi. Karena itu, “authenticated context” seharusnya meluas melampaui prompt pengguna, mencakup setiap input konteks eksternal yang digunakan agent.
MITRE ATLAS mempublikasikan PDF “OpenClaw Investigation” yang menguraikan antarmuka kontrol OpenClaw yang terekspos hingga mengarah pada akses kredensial dan eksekusi, termasuk teknik indirect prompt injection yang memerdaya agent agar diam-diam memanggil tool eksekusi tanpa batas. Dokumen itu memaparkan penyalahgunaan kontrol token OpenClaw dan memuat konteks bertanggal (1 Februari 2026). (mitre.org/sites/default/files/2026-02/PR-26-00176-1-MITRE-ATLAS-OpenClaw-Investigation.pdf).
Timeline:
Pelajaran: Tim dengan mentalitas AIBOM harus memodelkan dan memverifikasi “control interfaces” seperti token serta siklus hidup plugin/skill sebagai dependensi kelas pertama—bukan detail implementasi. Ini adalah capability scoping dan kegagalan mediasi yang dibuat terlihat.
Narasi Maret 2026 memaparkan insiden bertipe supply-chain “AI-driven” di mana paket npm berbahaya dikirim setelah rangkaian crafted prompt injection, lalu memasang OpenClaw pada mesin developer untuk periode tertentu dan kemudian ditambal cepat. Ini bukan nasihat utama pemerintah yang muncul dalam sumber-sumber yang dihimpun, sehingga perlakukan sebagai studi kasus yang berbasis hipotesis sampai divalidasi dengan postmortem vendor atau otoritatif. Meski demikian, kisah ini mencerminkan arah rantai trust: prompt injection dapat berubah menjadi pengaruh supply chain bila batas instalasi dan eksekusi agent tidak dikunci. (cremit.io/blog/ai-supply-chain-attack-clinejection).
Timeline:
Pelajaran: AIBOM tidak hanya harus menangkap model dan tool, tetapi juga lifecycle hooks serta jalur instalasi yang memungkinkan agent memperoleh kemampuan baru. Replay berkualitas bukti harus menjawab: “Kemampuan apa saja yang terpasang, kapan, dan dalam kondisi terautentikasi seperti apa?”
Jadi apa: Jangan perlakukan kasus-kasus ini sebagai “cerita generik prompt injection.” Jadikan sebagai persyaratan kualitas bukti: setiap penyeberangan batas (ingestion konteks, tool invocation, instalasi capability) harus menghasilkan lineage yang bisa diverifikasi dan dapat di-replay.
Praktisi di lingkungan enterprise ter-regulasi dan pemerintahan membutuhkan kerangka kerja yang mengubah persyaratan menjadi gerbang operasional. NIST AI Risk Management Framework (AI RMF 1.0) menyediakan sumber daya sukarela untuk mengelola risiko AI. (nist.gov). NIST Generative AI Profile menambahkan kategori risiko spesifik generatif serta suggested actions. (nist.gov).
Dari sisi infrastruktur, NIST SP 800-207 menjadi jangkar untuk zero trust architecture. (csrc.nist.gov). Dari sisi supply chain, SBOM minimum elements menciptakan preseden kebijakan untuk “minimum provenance fields” dan otomasi. (ntia.doc.gov).
Wawasan implementasi yang kunci adalah kerangka trust harus bisa dieksekusi dalam pipeline penerapan:
Jadi apa: Bangun satu pipeline evidence yang memetakan objektif kontrol AI RMF ke titik mediasi ZTA dan artefak lineage AIBOM. Bila pemetaan hanya berupa spreadsheet, masalah “proof” akan gagal ketika insiden menuntut rekonstruksi.
Arah operasional sudah jelas: “AI trust” akan bergeser dari tata kelola kualitatif menuju verifikasi provenance berkualitas bukti. Generative AI Profile NIST sudah mengkuantifikasi set kontrol yang luas, kebijakan SBOM menuntut provenance yang siap otomasi, dan riset agentic AIBOM berfokus pada bukti dependensi runtime serta evaluasi reproduksibilitas.
Mulai dari rilis agent enterprise berikutnya, tetapkan gerbang review keamanan hanya menerima:
Dengan kata lain, jadikan “AIBOM proof-of-lineage” sebagai kriteria rilis—bukan artefak yang muncul hanya saat insiden.
Menjelang Q4 2026, setidaknya tiga hal diperkirakan menjadi standar pada penerapan agent enterprise:
Prakiraan ini bertumpu pada cadence evolusi panduan yang terlihat: SBOM minimum elements diformalkan pada 12 Juli 2021, lalu diperbarui melalui siklus panduan berkelanjutan dari CISA; sementara Generative AI Profile NIST dirilis pada 26 Juli 2024 dengan keluasan kuantitatif pada risiko/aksi. (ntia.doc.gov).
Kalimat penutup (berorientasi aksi): Jadikan setiap tindakan agent dapat dibuktikan dengan meminta AIBOM lineage dan eksekusi tool yang dimediasi zero-trust sebelum rilis—dan organisasi tidak lagi memperlakukan “trust” sebagai kisah postmortem.