NIST Answered the Autonomy Question by Handing It Back

November 4, 2026·10 min read

On 27 October, four authors published Design Tenets for Agent Identity Management Systems on NIST’s Cybersecurity Insights blog. Three of them work at NIST: Harold Booth, Bill Fisher and Ryan Galluzzo. The fourth is Tom Clancy, at MITRE. The post calls itself blog #2 in a series on agentic identity, says the tenets are drawn from public comments on the NCCoE’s agent identity project, and sets out ten numbered paragraphs.

The day before it appeared, I wrote that the NCCoE project page still described a draft project description that “has not appeared,” and that the eventual deliverable was an SP-1800 practice guide with no date attached. Both statements are still true. What arrived on the 27th was a blog post that answers, as well as anything NIST has published, the question of how much autonomy an agent should have. The answer is that you decide.

What kind of document this is

The post states no comment period. It is not a Special Publication and it assigns no control identifiers. The blog it sits on carries a standing disclaimer in its own about section: “The views presented here are those of the authors and do not necessarily represent the views or policies of NIST.” That line is boilerplate for the entire blog rather than a caveat attached to these ten paragraphs. It still tells you what to do with them.

Set that against the rest of the program. The benchmark guidance is still an Initial Public Draft on the CAISSI guidelines page, listed against a comment deadline of 31 March 2026 that passed seven months ago. The SP 800-53 overlays project was renamed on 20 October to Control Overlays for Super Intelligence Systems, COSIS, under the September super-intelligence order, and it still lists single-agent and multi-agent use cases among five planned overlays. Its publications page has one row on it: AI 100-2 E2025, a taxonomy of adversarial machine learning, final on 24 March 2025. The identity track’s resource hub still points at an SP-1800 practice guide.

I went through the rest of that inventory in the October piece on the incident guide, so I will not repeat it here. The sequence runs backwards: the concepts arrived first, in the weakest instrument the program has.

Tenet 05 is the answer, and it is a verdict

“Every organization defines risk thresholds and tolerances that, when reached, initiate human review of agentic actions.”

The paragraph above the tenets says the same thing more broadly. Tenets “should be applied and implemented by organizations based on the risk associated with the agentic transactions they intend to support.”

I think that is the right call, and it is also the sentence that keeps the document from being assessable. NIST cannot know your risk appetite and should not pretend to. But an assessor who asks what autonomy tier an agent runs at is asking for a document with your thresholds in it, signed by somebody. The program has published no template for it, so the classification is yours to invent and to defend on request.

The rest of tenet 05 is the sharpest thing in the post, and it sits in a subordinate clause. Escalation flows have to be “cognizant of consent fatigue where human escalation becomes so frequent that agentic actions are approved habitually, rather than through careful risk consideration.”

Read that next to the way human review shows up in a control matrix. A review step gets counted as a control. Tenet 05 says the control degrades as volume rises, which makes the count meaningless unless the escalation rate sits beside it. In my experience the checkbox gets ticked and nobody asks how many prompts that reviewer cleared that day.

The delegation rule already exists, and it is not NIST’s

Tenet 02 requires that “as authority is delegated down to sub-agents or downstream services, scopes attenuate so that downstream entities can never claim more authority than the parent.”

That is close to the accountability gap the Cloud Security Alliance named in April, and it is not a new idea. If you have not read that note, take the diagnosis and leave the prescription: it ends by recommending CSA’s own controls matrix. On 26 October I quoted the NCCoE summary of comments, where a commenter had already asked for exactly this attenuation down a delegation chain (that post is here). What changed is that NIST wrote it down as a tenet.

A commenter under the tenets post, Mayur Agnihotri, made a point I had missed. OWASP’s AI Security Verification Standard, in its 1.01 release, carries requirement 9.5.7 at level 2: “Verify that authority derived through delegation never exceeds the delegating agent’s current authority.” It is the same rule as tenet 02, in a document built to be tested against. He also set tenet 05 beside 9.2.3 and 9.2.4, which require a trusted reversibility classification for each high-impact action and a runtime that enforces it. He disclosed contributing to that chapter, which I appreciate, and I checked each requirement in OWASP’s repository rather than taking the comment’s word for it.

What separates tenet 02’s sentence from 9.5.7 is a level number. One is a design principle addressed to whoever reads a blog. The other is a verification item in a catalogue built on the claim that its requirements can be tested.

The pattern repeats. Tenet 08 says probabilistic signals are “not used as the primary mechanism” for an access decision. AISVS 9.5.3, also level 2, says access control decisions are “enforced by application logic or a policy engine, never by the AI model itself.” For tenet 07’s separation of policy from reasoning, the nearest outside requirement I found is 9.3.6, which asks for “architectural separation between processing of untrusted tool outputs and agent operations.” That one is not the same clause, and I would not present it as one.

The mapping is mine. The tenets post cites no verification catalogue, and I could not find a crosswalk between the two documents, so testing against both is work you do yourself.

AISVS supplies the human-approval control as well. 9.2.1, at level 1, requires the agent runtime to block privileged or irreversible actions “until explicit human approval is received and verified.” That goes further than tenet 05 does, and it turns the approval trigger into something testable. 9.2.3 then supplies a definition for the class by requiring a trusted reversibility grade for each high-impact action, “such as read-only, reversible, externally reversible, or irreversible.”

What neither document settles is the number. 9.2.1 gates the actions you call privileged or irreversible and leaves that call to whoever applies the standard. Tenet 05 asks you to define thresholds and tolerances and never says what sets them. Neither says how much escalation a reviewer can absorb: I searched the 1.01 chapters for a requirement about escalation rate or reviewer fatigue and found none, and tenet 05’s consent-fatigue clause is the only place in either document that names the problem.

Reversibility is the piece I would take from AISVS. It is a property of the action rather than of your appetite for risk, which makes it something two teams can agree on without sharing a risk register. Tenet 05 does not use anything like it.

The comment thread is asking the question the tenets assume away

One commenter asks what changes “when the mandate issuer, the agent’s operator and the party enforcing the decision are different organisations,” and supplies the example most people will meet first: a consumer’s agent asking a bank to make a payment or change a limit. The bank does not control the agent, cannot inspect its harness, and receives a mandate it did not issue.

Tenet 02 covers that case if the chain the bank verifies is anchored somewhere the bank trusts. Another reply on the same thread puts the failure mode plainly: “Without a neutral anchor, each large platform will issue its own agent identities and portability dies at the first boundary.” Tenet 02 says authority attenuates as it is delegated. It does not say who attests to the parent’s authority when the parent belongs to somebody else.

The thread also asks how tenet 10’s independent logging survives when there is no enterprise to operate it, which describes a great many open-source agents. It also contains a proposal for an eleventh tenet, that “the human’s authority must not be reproducible by the agent,” because the strongest human credentials often sit on the same device the agent runs on. The commenter discloses a commercial interest in the answer. AISVS 9.2.9 at level 3 covers half of it by isolating approval key material from the agent runtime. The other half, an approval that nothing in the agent’s environment can produce, is still a proposal in a comment box.

What I would do with this quarter

Write the ladder down. Four lines is enough to start: which actions are irreversible, what value or volume triggers review, who can approve, and what the approval leaves behind as evidence. Put your own thresholds in it, because NIST has said they are yours. This is the artifact an assessor will ask for. It is also the one you have to design yourself, because no NIST publication I have read supplies a template.

Map the tenets you rely on to requirements you can test, and label the mapping as yours. The alternative is a control matrix with “tenet 02” sitting in a cell, where the next person to touch it assumes the tenet is the requirement.

Start with tenet 10. An append-only log the agent cannot write to is the one of the ten that pays off whatever NIST publishes next, because it is the one that answers a question about last Tuesday. It is also the one you can begin without waiting for anything.

Do not call any of it compliance. The tenets bind nobody, the blog disclaims itself, and an assessor who learns that after you claimed otherwise leaves you worse off than if you had said nothing.

What I am not claiming

NIST setting your risk thresholds was never realistic, and I do not think the agency dodged anything by declining. A standards body can describe how to classify risk. It cannot set your appetite for it, and a number NIST invented would be one every organization ignores.

Concepts arriving before controls is ordinary too. The AI Risk Management Framework had the same shape: an outline, then a draft, then a version everybody cites. The difference I keep coming back to is the vehicle. The AI RMF arrived as a numbered publication with comment periods attached. This arrived as blog post #2, with the authors’ views disclaimed on the blog’s own about page.

I have been wrong about this program’s timing twice already, in September and again in October, so weigh the prediction accordingly. What I am more confident about is narrower. The two tenets I would carry into an architecture review are 07 and 08, and you do not need anyone’s permission to adopt them today. An agent whose permissions are decided by a policy engine rather than by the model is a design choice available this week, and tenet 07’s rationale explains why it has to be architectural: an LLM takes data and instructions through a single interface, so the separation cannot come from inside the model.

The post closes by saying the tenets will be the guideposts for the NCCoE’s agent demonstrations. That is the next thing to watch on this track, and I have no idea when it will appear.