NIST's AI Agent Standards Work: What Is In Scope

The scope of NIST's AI agent work is narrower than the sales version of the phrase. NIST announced the AI Agent Standards Initiative, and described it as work on agents capable of autonomous actions. The announcement frames the problem around public trust, interoperability, and adoption, not around a mandatory control catalogue for every agent deployment. That distinction matters when an agent can release a payment, alter a customer record, or change a credit limit.

NIST AI agent standards now in scope

NIST's public statement gives compliance teams a useful boundary. It does not say that a final agent standard already exists. It says the Initiative will foster industry-led technical standards and protocols for AI agents. That is not nothing. It is also not a binding rule that tells an engineer exactly when an email agent may cancel an invoice or when a support agent may delete a record.

"The Initiative will ensure that the next generation of AI—AI agents capable of autonomous actions—is widely adopted with confidence, can function securely on behalf of its users, and can interoperate smoothly across the digital ecosystem."

— NIST, Announcing the "AI Agent Standards Initiative" for Interoperable and Secure Innovation

The hard word in that sentence is "on behalf of". An agent acting on behalf of a user is not just producing text. It is being placed between intent and execution. The risk owner then has to ask a different question from the one asked of a chatbot: what proof exists that the action was allowed before it touched the system?

NIST describes AI agents as being able to work autonomously for hours, write and debug code, manage email and calendars, and shop for goods. NIST also says the utility of agents is constrained by their ability to interact with external systems and internal data. Put those two statements together and the practical problem becomes plain. The agent is useful when it crosses a boundary, and the boundary is where the control has to be visible.

A standards initiative can name the interoperability problem. It can convene the right market. It can give vendors a common direction. It cannot, by itself, produce the after-the-fact record for a disputed transfer. That record has to exist at runtime, tied to the specific action, and capable of being reviewed after the incident is no longer fresh.

NIST warned that, without confidence in agent reliability and interoperability between agents and digital resources, innovators may face fragmentation and stunted adoption. That warning is not a substitute for an internal authorization model. It is a reason to stop treating an agent connector as the control.

The announcement also points to process rather than completion. NIST said it would use public input, including convenings, RFIs, listening sessions, and other approaches, to support interoperable and secure adoption of AI agents. CAISI was also said to be holding listening sessions beginning in April on sector-specific barriers to AI adoption, with a focus on AI agents. Those are signals of standards formation. They are not the same as a finished test that proves your agent was permitted to change a production record.

NIST AI RMF agents and the older risk work

The NIST AI RMF matters here because it is the nearest mature frame NIST has already put around AI risk. NIST describes the AI RMF as intended for voluntary use and for improving the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. Voluntary use means the framework, standing alone, is not a command that forces one implementation pattern. That is useful flexibility. It is also the reason a compliance officer cannot point to the acronym and say the agent control question is solved.

"The NIST AI Risk Management Framework (AI RMF) is intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems."

— NIST, AI Risk Management Framework

For agents, the AI RMF should be read as a risk-management frame, not as an authorization product. It helps an organisation ask whether risks are being governed, mapped, measured, and managed. It does not decide whether an agent may approve a supplier payment after a purchase-order mismatch. That decision lives in the system of action, not in the existence of a framework document.

NIST's AI RMF page says a companion NIST AI RMF Playbook was published with other materials. The AI RMF Core page separately says practices related to mapping AI risks are described in the NIST AI RMF Playbook. The same AI RMF Core page says practices related to managing AI risks are described in the NIST AI RMF Playbook. That supports a simple reading: the RMF ecosystem tells teams how to organise risk work, but it does not turn a completed agent action into proof that the action was authorised.

There is also profile work around particular kinds of AI use. NIST published the Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, and describes it as a cross-sectoral profile and companion resource for the AI RMF 1.0 for Generative AI. NIST also published a Concept Note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure. That Concept Note says NIST will develop a profile giving critical infrastructure sectors increased confidence to deploy AI agents and tools as part of their overall strategy.

That is a stronger agent connection than a generic AI governance slogan. It still has limits. A profile can set expectations for a sector. It can shape language between engineering, compliance, and external reviewers. It cannot retroactively prove that a particular deleted record, changed limit, or released refund passed through an allowed decision path.

For readers who need the broader RMF background, the site's NIST AI RMF topic page collects the existing Crelis coverage. The useful move here is not to restate the whole framework. The useful move is to separate framework adoption from runtime proof.

What is NIST AI RMF in this context

NIST describes the AI RMF as a framework to better manage risks to individuals, organisations, and society associated with artificial intelligence. That sentence is broad by design. It is meant to apply across AI products, services, and systems, not only to agents that take action in business systems.

"The NIST AI RMF is a framework to better manage risks to individuals, organizations, and society associated with artificial intelligence (AI)."

— NIST, NIST AI Risk Management Framework (AI RMF 1.0) Launch

That breadth is why the RMF is useful and why it can be misused. It gives a governance vocabulary. It does not answer every operational question. In an internal review, the next question should be mundane: show the record for the action.

The RMF also sits in a resource ecosystem. NIST says the Trustworthy and Responsible AI Resource Center was launched to facilitate implementation of, and international alignment with, the AI RMF. The AI RMF Core page says the NIST AI RMF Playbook is an online companion resource available to help organisations navigate the AI RMF. Those resources may help teams structure controls. They do not make a runtime authorization record appear.

This is where vague compliance language becomes dangerous. "Governed" can mean that a policy was approved. "Managed" can mean that a risk register exists. "Measured" can mean that a dashboard has a metric. None of those words proves that the agent was allowed to execute the one action now being challenged.

The difference is not academic. A chatbot answer can be wrong and still leave no direct system change. An agent action can move money, contact a customer, update a field, or trigger a process that other systems treat as final. The evidence burden follows the action, not the model.

The internal control pattern is therefore different. An organisation can use the RMF to decide which risks matter. It can use the agent standards work to track where the industry may align on protocols and expectations. It still needs its own decision record for the moment when an agent tries to do something that matters.

What this means if you have to produce evidence

Evidence is not the same thing as logging an outcome. A log that says "payment released" tells you what happened. It may not tell you who was allowed to permit it, which policy applied, what context was evaluated, or whether a human approval was required before release.

The NIST material points to confidence. That is the right word at the standards level. At the evidence level, confidence has to be earned by artefacts that survive the incident. A reviewer who was not present needs more than the final state of a workflow.

Start with a concrete action. The agent asks to change a credit limit. The control question is not whether the agent is impressive, or whether the model usually behaves, or whether the organisation has adopted the AI RMF. The question is whether this agent, for this customer, under these conditions, was permitted to make this change at that time.

Now add the dispute. The customer later says the change was unauthorised. The business says the action was allowed. A dashboard screenshot will not carry much weight. A tamper-evident record of the decision can.

This is also where pure interoperability work stops short. If two systems can pass an agent request between them, that helps execution. It does not automatically prove authority. Interoperability can make the action flow. Evidence has to make the authority behind the action inspectable.

The same point applies to a deleted record. If the deletion is contested, "the agent had access" is too weak. Access may explain how the action occurred. Authorization explains why it was permitted. Evidence shows that the permission existed before the deletion happened.

Do not collapse these questions into one file. Read the decision review workflow beside the broader AI governance compliance reference, then ask the narrower agent question: can you prove the permission behind the action?

Practical steps for agent standards readiness

1. Separate the framework file from the action record. Keep the AI RMF work where it belongs: risk governance, assessment, and operating discipline. Do not let it become a substitute for runtime proof. If a control owner cannot point from a completed action back to the permission that allowed it, the record is not yet fit for dispute.
2. Define sensitive actions in ordinary business language. "Refund issued", "supplier bank details changed", "customer record deleted", and "credit limit increased" are better units than broad system permissions. They match the way harm appears and the way reviewers ask questions.
3. Record the decision before execution. The useful artefact is not only that the agent acted. It is that the permission decision existed before the action reached the system. Crelis describes GREENLIGHT as checking agent requests for sensitive actions and recording every action while existing systems keep working.
4. Preserve context, not just identity. The same agent identity may be safe for one task and unsafe for another. The record should show the action, the relevant conditions, and the decision path that allowed, escalated, required approval, or blocked the request.
5. Design for the outside reviewer. Assume the person reading the record later does not trust the agent, the model, or the dashboard. The artefact should stand on its own. It should show what was requested, what was allowed, and what actually happened.
6. Track NIST work without pretending it is finished. NIST said future research, guidelines, and deliverables for the AI Agent Standards Initiative would follow in the months ahead. That makes monitoring sensible. It does not justify waiting to define internal authority for agent actions.
7. Test the ugly cases. Pick the actions that will embarrass the organisation if they are wrong. A failed refund is not the same as a changed bank account. A draft email is not the same as a sent termination notice. The control should be judged at the point where the agent can cause a real system change.

Crelis's position is narrow: agent standards and the NIST AI RMF can help organise the field, but they do not by themselves prove who authorised a specific action. GREENLIGHT is Crelis's permission step for AI agent actions, and the product demonstration asks teams to identify where their agents touch money, customers, records, or infrastructure. The point is not to record a better story after the fact. The point is to create the authority record before the action happens.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• NIST AI RMF topic page.
• Oversight framework for AI systems — how review records differ from ordinary monitoring.
• AI risk oversight framework — how accountability depends on records that survive review.