NIST AI Agent Standards Initiative: Cakupan CAISI

Setiap beberapa minggu muncul istilah baru di diskusi keamanan agent: CAISI, NCCoE, concept paper NIST. Kebanyakan komentar yang saya temukan bersifat sekunder, jadi pada 17 Oktober 2026 saya membaca halaman NIST dan PDF concept paper baris demi baris, lalu mencatat hanya apa yang tertulis di sana.

Post ini membahas apa itu initiative-nya, apa yang diminta tiap dokumen publik, standar apa yang disebut paper identitas, apa yang masih belum pasti, dan sebuah agent register kecil yang bisa Anda buat sebelum ada yang final. Setiap klaim bisa ditelusuri ke halaman NIST di bagian sumber.

Apa yang NIST umumkan pada 17 Februari 2026

Center for AI Standards and Innovation (CAISI) di NIST mengumumkan AI Agent Standards Initiative pada 17 Februari 2026, bersama Information Technology Laboratory (ITL) NIST, National Science Foundation dan mitra antarlembaga lainnya. Pengumuman itu menggambarkan agent sebagai sistem yang dapat mengambil tindakan secara otonom, dan menyebut risiko yang ingin dihindari: ekosistem yang terfragmentasi serta adopsi yang melambat jika agent kurang andal dan tidak interoperable.

Initiative ini punya tiga pilar. Pertama, pengembangan standar agent yang dipimpin industri, serta kepemimpinan AS di badan standar internasional. Kedua, pengembangan dan pemeliharaan protokol open-source untuk agent yang dipimpin komunitas. Ketiga, riset keamanan dan identitas AI agent, agar use case baru dan adopsi yang tepercaya di berbagai sektor bisa berjalan.

Bacalah sebagai kerangka program, bukan aturan. Pengumuman itu tidak mewajibkan apa pun kepada siapa pun. NIST menyebut akan memakai convening, RFI, listening session dan pendekatan lain, dan bahwa riset, guideline serta deliverable lanjutan akan diumumkan dalam beberapa bulan ke depan, tanpa tanggal. Semua yang konkret sejauh ini ada di tiga dokumen terkait yang dibahas berikutnya.

Kalender: apa yang diminta, dan kapan

Halaman hub initiative mendaftar masukan publik yang dibuka. Saya membuka satu per satu dan membandingkan tanggalnya, karena halaman hub dan halaman detail tidak sepenuhnya sama.

Dua hal penting jika Anda mengutipnya. Halaman hub terakhir diperbarui 14 Agustus 2026 tetapi masih menampilkan deadline musim semi, jadi deadline yang tercantum bukan bukti bahwa periodenya masih terbuka. Dan selisih 20 Maret dengan 31 Maret ada di halaman NIST sendiri. Saya laporkan keduanya, tidak memilih salah satu.

RFI CAISI: apa yang ditanyakan soal pengamanan agent

Request for information CAISI, terbit 12 Januari 2026, meminta masukan dari industri, akademisi dan komunitas keamanan tentang pengamanan sistem AI agent. Fokusnya risiko yang muncul ketika output model digabung dengan fungsi software, bukan kerentanan software secara umum. Halaman itu menyebut respons akan menjadi masukan untuk voluntary guidelines dan best practices di masa depan serta riset keamanan agent CAISI.

Rilisnya merangkum lima area masukan. Responden didorong membawa contoh konkret, studi kasus dan rekomendasi yang bisa ditindaklanjuti.

• Ancaman keamanan khas pada sistem AI agent, dan bagaimana ancaman itu berubah seiring waktu
• Metode meningkatkan keamanan selama development dan deployment
• Kekuatan dan celah pendekatan cybersecurity yang ada ketika diterapkan pada agent
• Cara mengukur keamanan agent dan mengantisipasi risiko selama development
• Intervensi di lingkungan deployment, termasuk membatasi dan memantau akses agent

Ancaman yang disebut adalah indirect prompt injection, ketika model memproses data adversarial; model yang tidak aman, misalnya akibat data poisoning; dan tindakan berbahaya tanpa penyerang, seperti specification gaming atau objective yang tidak selaras. RFI juga menyebut kelemahan konvensional seperti authentication yang bisa dieksploitasi atau manajemen memori, tetapi menyatakan itu tumpang tindih dengan software lain dan bukan fokus utama. Halaman rilis tidak memuat pertanyaan satu per satu. Saya tidak membaca teks Federal Register, jadi tidak mengutipnya.

Concept paper NCCoE tentang identitas dan otorisasi agent

Pekerjaan identitas adalah dokumen terpisah. Ini draft concept paper bertanggal Februari 2026 dari National Cybersecurity Center of Excellence (NCCoE) NIST, berjudul Accelerating the Adoption of Software and AI Agent Identity and Authorization, dengan penulis Harold Booth, Bill Fisher, Ryan Galluzzo dan Joshua Roberts. Paper ini menyatakan melengkapi tetapi terpisah dari RFI CAISI.

Premisnya sengaja sederhana. Paper bertanya apakah NCCoE perlu menjalankan proyek yang menerapkan standar identitas dan best practices yang sudah ada pada software dan AI agent, dan menyebut masukan akan menentukan scope, kelayakan dan nilainya, serta apakah demonstrasi atau output lain yang paling cocok. Langkah berikutnya yang disebut adalah draft project description dan call for collaborators. Jika proyek jalan, deliverable-nya practice guide yang dibangun di lab NCCoE dengan teknologi komersial, dirilis bertahap seperti proyek Mobile Driver's License baru-baru ini.

Paper mendefinisikan arsitektur agentic sebagai arsitektur yang menerima instruksi, mengambil konteks dari resource lain secara dinamis, memproses hasilnya, berpotensi mengambil tindakan dan mengembalikan respons. Lima area minat menyusul: identification sistem AI dan software, authorization, access delegation, logging dan transparency, serta pelacakan data flow agar provenance prompt dan input bisa menjadi dasar keputusan policy.

Pengecualiannya sama pentingnya dengan scope. Retrieval-augmented generation dan arsitektur yang hanya memakai LLM dengan data trainingnya berada di luar scope, begitu juga identifikasi agent dari sumber eksternal yang tidak tepercaya; paper berfokus pada use case enterprise yang kontrol dan visibilitasnya lebih besar. Tiga use case disebut: agent untuk efisiensi staf, agent untuk pekerjaan keamanan, dan agent untuk pipeline pengembangan dan deployment software.

Standar yang dipertimbangkan paper

Bagian 2 paper mendaftar apa yang sedang dipertimbangkan proyek. Kolom kanan adalah pembacaan saya tentang posisi tiap standar dalam stack agent, bukan pemetaan dari NIST.

Paper juga menyebut NIST akan menerapkan SP 800-207 Zero Trust Architecture, SP 800-63-4 Digital Identity Guidelines dan NISTIR 8587 Protecting Tokens and Assertions from Forgery, Theft, and Misuse. Tidak ada kriptografi baru di sini. Taruhannya, standar identitas yang ada sudah menutup sebagian besar masalah, dan pertanyaan terbukanya adalah bagaimana standar itu disesuaikan untuk agent.

Ubah pertanyaan paper menjadi agent register

Paper menutup note to reviewers dengan pertanyaan yang dikelompokkan menjadi identification, authentication, authorization, auditing dan non-repudiation, serta prompt injection. Ini bagian yang paling bisa dipakai ulang, karena Anda bisa menjawabnya untuk agent Anda sendiri hari ini. Register dan checker di bawah adalah sketsa saya, bukan skema NIST dan bukan uji kepatuhan. Tiap field dipetakan ke pertanyaan yang diajukan paper.

// agents.json: one entry per agent. Field names are mine; the comments
// name the question in NIST's concept paper each field answers.
[
  {
    "id": "agent://billing/invoice-reconciler",   // Identification: what metadata identifies an agent?
    "purpose": "match bank lines to open invoices",
    "boundary": "billing-prod VPC, one service account",  // tied to software or organisational boundaries?
    "credential": {
      "type": "workload-identity",                // Authentication: what is strong auth for an agent?
      "subject": "svc-invoice-reconciler",
      "expiresAt": "2026-11-17T00:00:00Z",        // key management: issuance and update
      "revokedBy": "platform-oncall"              // key management: revocation
    },
    "scopes": ["invoices:read", "ledger:propose"], // least privilege when actions are not predictable
    "onBehalfOf": "finance-lead@example.com",     // delegation: on-behalf-of scenarios
    "humanApproval": ["ledger:post"],             // human-in-the-loop authorization
    "dataSources": ["bank-feed", "erp-invoices"], // tracking data flows and provenance
    "logSink": "append-only-audit-bucket"         // auditing: actions and intent logged
  }
]

// check-agent-register.mjs: node check-agent-register.mjs agents.json
import { readFileSync } from "node:fs";

const REQUIRED = [
  "id", "purpose", "boundary", "credential.type", "credential.subject",
  "credential.expiresAt", "credential.revokedBy", "scopes", "onBehalfOf",
  "dataSources", "logSink",
];
const pick = (obj, path) => path.split(".").reduce((o, p) => o?.[p], obj);

let failures = 0;
for (const agent of JSON.parse(readFileSync(process.argv[2], "utf8"))) {
  const missing = REQUIRED.filter((f) => {
    const v = pick(agent, f);
    return v === undefined || v === "" || (Array.isArray(v) && v.length === 0);
  });
  // Wrong: the agent borrows the person's own token, so it cannot be revoked
  // or audited separately from them. Right: a distinct credential subject.
  if (agent.credential?.subject === agent.onBehalfOf) {
    missing.push("credential.subject must differ from onBehalfOf");
  }
  if (missing.length) {
    failures++;
    console.error(agent.id + ": " + missing.join(", "));
  }
}
process.exit(failures ? 1 : 0);

Satu aturan yang berpendirian di checker: credential subject sebuah agent harus berbeda dari manusia yang diwakilinya. Itu kebijakan saya, diambil dari pertanyaan paper tentang mengikat identitas agent dengan identitas manusia untuk otorisasi human-in-the-loop. Record yang gagal biasanya agent yang berjalan di token pribadi seseorang, yang tidak bisa di-revoke dan diaudit secara terpisah.

// One log line per action. The paper asks for actions AND intent, bound
// back to the human authorization, so all three travel in the same record.
{
  "ts": "2026-10-19T02:14:07Z",
  "actor": "svc-invoice-reconciler",
  "onBehalfOf": "finance-lead@example.com",
  "tool": "ledger.propose",
  "intent": "match bank line 4471 to invoice INV-2291",
  "approvedBy": null,
  "inputs": ["bank-feed", "erp-invoices"]
}

Blok kedua menunjukkan bentuk log record yang saya tuju, karena paper bertanya bagaimana agent dapat mencatat tindakan dan intent secara terverifikasi dan bagaimana tindakan terikat kembali ke otorisasi manusia. Apakah record seperti ini tamper-proof bergantung pada ke mana Anda mengirimnya. Sink append-only adalah batas minimum, dan paper tidak mengklaim sudah menyelesaikannya.

Apa yang masih belum pasti

Tidak ada yang saya baca yang merupakan standar, kewajiban atau guideline final. Dokumennya berupa pengumuman, request for information, draft concept paper dan ajakan listening session. Paper sendiri menyatakan proyek mungkin tidak berbentuk seperti sketsanya, dan demonstrasi mungkin bukan outputnya.

Beberapa hal tidak bisa saya pastikan. Saya tidak bisa membuka halaman proyek NCCoE, yang mengembalikan HTTP 403 ke fetcher saya, jadi tidak tahu apakah draft project description atau call for collaborators sudah terbit sejak April. Saya tidak menemukan ringkasan respons RFI. Komentar sekunder menyebut interoperability profile yang direncanakan akhir 2026, tetapi tidak ada halaman NIST yang saya baca yang mencantumkannya, jadi saya tidak memasukkannya. Pernyataan paper tentang MCP dan OAuth adalah potret Februari; periksa spesifikasi otorisasi MCP terbaru sebelum menyalinnya.

Trade-off saya adalah membangun berdasarkan konsep yang disebut paper, yaitu identity, delegation, authorization ber-scope dan logging, karena itu pertanyaan yang sama yang akan diajukan auditor mana pun, sambil memegang istilahnya dengan longgar sampai NIST menerbitkan project description atau guideline.

Yang dikerjakan pada hari Senin

Tidak ada dari ini yang perlu menunggu NIST. Lima langkah ini hanya memakai pertanyaan yang diajukan paper sendiri.

1. Data setiap agent dan apa yang bisa dijangkaunya memakai register di atas. Mulai dari tiga use case yang disebut paper: produktivitas staf, pekerjaan keamanan dan pipeline deployment.
2. Beri tiap agent credential sendiri, terpisah dari credential siapa pun, dan catat manusia yang diwakilinya. Ini menjawab pertanyaan on-behalf-of dan human-in-the-loop dari paper.
3. Tulis siapa yang me-revoke credential agent dan bagaimana caranya, lalu uji sekali. Paper bertanya soal issuance, update dan revocation key agent.
4. Catat actor, on-behalf-of, tool dan intent yang dinyatakan untuk setiap tindakan, ke sink yang tidak bisa diubah agent.
5. Subscribe ke halaman hub initiative dan cek ulang sebelum mengutip tanggal. Tulis tanggal pengecekan di dokumen Anda sendiri, seperti yang saya lakukan di sini.

Periode komentar yang saya baca sudah ditutup, jadi saluran praktisnya adalah halaman hub, tempat NIST menyebut deliverable lanjutan akan muncul. Jika organisasi Anda bergerak di kesehatan, jasa keuangan atau pendidikan, ajakan listening session ditujukan kepada Anda, tetapi tanyakan ke CAISI apakah masih menerima masukan.

Aturan yang saya ambil dari membaca halaman primernya: perlakukan pekerjaan NIST soal AI agent sebagai peta pertanyaan yang harus dijawab, belum sebagai standar untuk dipatuhi. Identity, delegation, authorization ber-scope dan logging adalah bagian yang stabil. Tanggal, deliverable dan nama akan bergeser, jadi kutip halaman yang Anda baca beserta hari Anda membacanya.