NIST AI Agent Standards Initiative: What CAISI Covers

Every few weeks a new acronym lands in an agent security thread: CAISI, NCCoE, the NIST concept paper. Most of the commentary I found was secondary, so on 17 October 2026 I read the NIST pages and the concept paper PDF line by line and wrote down only what they say.

This post covers what the initiative is, what each public document asked for, which standards the identity paper names, what is still unsettled, and a small agent register you can build before anything is finalised. Every claim traces to a NIST page listed under sources.

What NIST announced on 17 February 2026

The Center for AI Standards and Innovation (CAISI) at NIST announced the AI Agent Standards Initiative on 17 February 2026, working with NIST's Information Technology Laboratory (ITL), the National Science Foundation and other interagency partners. The announcement describes agents as systems that can take autonomous actions, and names the risk it wants to avoid: a fragmented ecosystem and slowed adoption if agents lack reliability and interoperability.

The initiative has three pillars. First, industry-led development of agent standards, and U.S. leadership in international standards bodies. Second, community-led open-source protocol development and maintenance for agents. Third, research in AI agent security and identity, to enable new use cases and trusted adoption across sectors.

Read it as a programme frame, not a rule. The announcement sets no requirement for anyone. It says NIST will use convenings, RFIs, listening sessions and other approaches, and that research, guidelines and further deliverables will be announced in the months ahead, with no dates given. Everything concrete so far sits in three linked documents, covered next.

The calendar: what was asked, and when

The initiative hub page lists the public inputs. I opened each one and compared dates, because the hub and the detail pages do not fully agree.

Two details matter if you cite this. The hub page was last updated on 14 August 2026 yet still shows the spring deadlines, so a listed deadline is not proof a window is open. And the 20 March versus 31 March mismatch is on NIST's own pages. I report both rather than choosing one.

The CAISI RFI: what it asked about securing agents

CAISI's request for information, issued on 12 January 2026, seeks input from industry, academia and the security community on securing AI agent systems. Its focus is the risk that appears when model outputs are combined with software functionality, not general software vulnerabilities. The page says responses will inform future voluntary guidelines and best practices and CAISI's agent security research.

The release summarises five areas of input. Respondents were encouraged to bring concrete examples, case studies and actionable recommendations.

• Unique security threats to AI agent systems, and how they may change over time
• Methods to improve security during development and deployment
• Strengths and gaps in existing cybersecurity approaches when applied to agents
• Ways to measure agent security and anticipate risks during development
• Deployment-environment interventions, including limiting and monitoring agent access

The threats it names are indirect prompt injection, where a model processes adversarial data; insecure models, such as those affected by data poisoning; and harmful actions without any adversary, such as specification gaming or misaligned objectives. It also mentions conventional flaws such as exploitable authentication or memory management, but says they overlap with other software and are not the main focus. The release page does not reproduce the individual questions. I did not read the Federal Register text, so I do not quote them.

The NCCoE concept paper on agent identity and authorization

The identity work is a separate document. It is a draft concept paper dated February 2026 from NIST's National Cybersecurity Center of Excellence (NCCoE), titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, with Harold Booth, Bill Fisher, Ryan Galluzzo and Joshua Roberts as authors. It says it complements but is distinct from the CAISI RFI.

Its premise is modest on purpose. It asks whether NCCoE should run a project applying existing identity standards and best practices to software and AI agents, and says the feedback will decide scope, feasibility and value, and whether a demonstration or some other output fits. Next steps it names are a draft project description and a call for collaborators. If the project goes ahead, the deliverable is a practice guide built in NCCoE labs with commercially available technology, delivered iteratively like the recent Mobile Driver's License project.

It defines an agentic architecture as one that takes in instructions, dynamically acquires context from other resources, processes the results, potentially takes action and returns a response. Five areas of interest follow: identification of AI and software systems, authorization, access delegation, logging and transparency, and tracking data flows so that the provenance of prompts and inputs can inform policy decisions.

The exclusions matter as much as the scope. Retrieval-augmented generation and architectures using only an LLM with its training data are out of scope, and so is identifying agents from untrusted external sources; the paper focuses on enterprise use cases where control and visibility are greater. It names three: agents that improve staff efficiency, agents for security work, and agents for software development and deployment pipelines.

The standards the paper says it is considering

Section 2 of the paper lists what the project is currently considering. The right-hand column is my reading of where each one would sit in an agent stack, not NIST's mapping.

The paper also says NIST will apply SP 800-207 Zero Trust Architecture, SP 800-63-4 Digital Identity Guidelines and NISTIR 8587 Protecting Tokens and Assertions from Forgery, Theft, and Misuse. Nothing here is new cryptography. The bet is that existing identity standards already cover most of the problem, and the open question is how they bend for agents.

Turn the paper's questions into an agent register

The paper closes its note to reviewers with questions grouped under identification, authentication, authorization, auditing and non-repudiation, and prompt injection. They are the most reusable part, because you can answer them about your own agents today. This register and checker are my sketch, not a NIST schema and not a compliance test. Each field maps to a question the paper asks.

// 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);

The checker's one opinionated rule is that an agent's credential subject must differ from the human it acts for. That is my policy, taken from the paper's question about binding agent identity to human identity for human-in-the-loop authorization. A record that fails it is usually an agent running on someone's personal token, which cannot be separately revoked or audited.

// 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"]
}

The second block shows the log record shape I would aim for, because the paper asks how agents can log their actions and intent in a verifiable way and how actions bind back to human authorization. Whether a record like this is tamper-proof depends on where you ship it. An append-only sink is the minimum, and the paper does not claim to have solved that.

What is still unsettled

Nothing I read is a standard, a requirement or a final guideline. The documents are an announcement, a request for information, a draft concept paper and a listening-session call. The paper itself says the project might not take the shape it sketches, and that a demonstration may not even be the output.

Several things I could not confirm. I could not open the NCCoE project page, which returned HTTP 403 to my fetcher, so I do not know whether a draft project description or call for collaborators has been published since April. I found no summary of RFI responses. Secondary commentary mentions an interoperability profile planned for late 2026, but none of the NIST pages I read lists one, so I left it out. The paper's MCP and OAuth statements are a February snapshot; check the current MCP authorization specification before copying them.

My trade-off is to build against the concepts the paper names, identity, delegation, scoped authorization and logging, because they are the same questions any auditor will ask, and to hold the vocabulary loosely until NIST publishes a project description or guideline.

What to do on Monday

None of this needs to wait for NIST. These five steps use only questions the paper itself asks.

1. Inventory every agent and what it can reach, using the register above. Begin with the three use cases the paper names: staff productivity, security work and deployment pipelines.
2. Give each agent its own credential, separate from any person's, and record the human it acts for. This answers the paper's on-behalf-of and human-in-the-loop questions.
3. Write down who revokes an agent credential and how, then test it once. The paper asks about issuance, update and revocation of agent keys.
4. Log actor, on-behalf-of, tool and stated intent for every action, to a sink the agent cannot edit.
5. Subscribe to the initiative hub page and re-check it before you quote a date. Put the date you checked in your own document, as I did here.

The comment windows I read have closed, so the practical channel is the hub page, where NIST says further deliverables will appear. If your organisation works in healthcare, financial services or education, the listening-session call was aimed at you, but check with CAISI whether it is still taking input.

The rule I take from reading the primary pages: treat the NIST AI agent work as a map of the questions to answer, not yet as a standard to comply with. Identity, delegation, scoped authorization and logging are the stable part. Dates, deliverables and names will move, so cite the page you read and the day you read it.