Seven Months Apart, the Same Questions: NIST's Design Tenets for Agent Identity, and the Design We Published in March

By Kevin Ryan Khan, Co-founder, Strikaris LLC

An evening with a standards document

I did not expect to spend an evening in late October reading a standards document and recognising my own arguments coming back at me.

On October 27, 2026, the National Institute of Standards and Technology published "Design Tenets for Agent Identity Management Systems" on its Cybersecurity Insights blog. NIST is the United States federal standards body, and a tenet is simply a design principle. This post sets out ten of them for agent identity management systems, the systems that establish who an AI agent is, what it may do, and how its actions are watched and recorded. NIST calls the tenets "an initial set." They are voluntary guidance, offered as guideposts for demonstrations run by its National Cybersecurity Center of Excellence, and NIST is candid that not all of them "will be immediately fulfilled by the current state of standards and technology."

I read it in one sitting. Then I read it again, more slowly, and what kept stopping me was the calendar. Seven months earlier, Brandon Zeek and I had published our own answer to the same problem, and on several of the questions that matter most, a two-person company building a product and a federal standards body setting out what good looks like had arrived at the same commitments, in print, seven months apart. Nothing about our post was a reply to theirs. When we published in March, the tenets did not exist. I have no reason to think anyone at NIST has ever seen our work, and in a way that is the point. Two groups looked at the same problem from opposite ends and wrote down some of the same answers.

This is the story of where the two documents meet, and of where ours stops short.

What we published in March

On March 16, 2026, Brandon Lee Zeek and I published "Before the Agent Acts: The Governance Gap in Enterprise AI" on the AWS Builder Center. Brandon passed away in May 2026. The design in that post is the one we built together, and it is the design I am comparing here.

The post described MirrorOS, our governance system. MirrorOS sits between an AI agent and the systems the agent acts on, and it decides whether an action is permitted before the agent carries it out. Before the agent does anything, whether that is approving a payment, updating a record, or triggering a workflow, two checks run.

The first check is Prolog behavioral verification. Does this action violate any rule in the Codex? The Codex is the rule set of the system, written in SWI-Prolog. Prolog is a logic programming language, and its rules are stated as facts and relations rather than as instructions. These are not prompts. They are logic.

The second check is Z3 structural verification. Is this action mathematically consistent with the axioms of the system? Z3 is a theorem prover, and a theorem prover is software that determines whether a statement provably follows from a given set of rules. It does not guess. It proves, or it refuses.

If both gates pass, the agent executes. If either gate fails, the action is blocked. And every decision is sealed in a tamper-evident, hash-chained ledger. The ledger is kept by the governing system rather than by the agent, so any later alteration breaks its cryptographic verification.

That was the whole commitment, published with our names on it in March. Then we got on with other work, and the post sat there, dated and public, while the industry conversation moved the way it moved.

Where the two documents meet

Reading the NIST post in October, I found myself walking through our own design in the order NIST had chosen to ask its questions. Here is that walk, in the order the recognition landed.

Separation of policy from reasoning (NIST tenet 7). NIST writes: "The logic that determines what an agent attempts to do is architecturally separated from the systems that determine what it is allowed to do." Its reasoning ends with a short sentence: "Guardrails alone are insufficient." The March design is built on exactly that separation. Nobody asks the executor whether an action is allowed. By the time the executor receives an instruction, the gates have already ruled. As the March post put it, governance placed inside a prompt "is probabilistic and cannot be audited." The decision sits outside the model and upstream of it, where it can be examined on its own.

Deterministic decisions (NIST tenet 8). NIST holds that deterministic capabilities should be "the primary mechanism for making access decisions," and that probabilistic information may inform a decision but must not make it. In the March design, no language model decides who is authorized. The verdicts come from formal logic, and they do not vary with mood, temperature, or phrasing. Run the same proposed actions a thousand times and the result is the same every time.

The evidence (NIST tenet 10). NIST calls for "an unbroken, tamper-evident chain of custody and append-only body of evidence," kept on "logging infrastructure independent of the agent," so that a compromised agent cannot rewrite its own record. The March design seals every gate decision in a tamper-evident, hash-chained ledger, kept by the governing system rather than by the agent. We keep one distinction in our claim language, because it matters and because it is easy to blur. A sealed verdict proves that an action was permitted under the rules. It does not prove that the action as executed matched the action that was checked. Permitted and performed are separate claims, and any system like ours should be evaluated on both.

Mandates (NIST tenet 6), echoed in part. Our design does not meet this tenet, and I want that sentence where a reader cannot miss it. NIST proposes that the person or organization giving an agent its task can also give the agent a cryptographically signed statement. The statement sets out what the agent is meant to achieve and what limits it must work within. The March Codex is not such a signed statement, and we do not claim that it is one. What the two designs share is one idea underneath the tenet. In both designs, the governing instructions exist as a written, formal artifact outside the agent. In our case that artifact is a rule set, and the client whose rules they are can read it. The instructions are not directions buried in a prompt. The signed element exists in our work only as a recorded design decision. If this governance work is productised, the client would receive one signed, client-readable rule pack. That pack would be the single source of truth from which enforcement is generated and checked.

Linking an agent back to whoever tasked it (NIST tenet 2), in part. NIST asks that agents stay linked to the entities that task them throughout execution, and that authority only shrink as it is delegated. A companion piece of the same design work is the kernel. The kernel is a Python action-authorization pipeline built around an interceptor, which is a component that every proposed action must pass through. The kernel keeps what we call bounded causal provenance. That is a record of which task, and whose instruction, stands behind each action. It is the direction of the linking NIST asks for, and I am choosing those words carefully. Attenuation means delegated authority that can only ever narrow, and it is only partially realised in the design. The kernel implementation passed 236 tests in April 2026. That figure is evidence about the code. It is not a claim that the kernel meets that tenet.

The layer that is not ours yet

Five of the ten tenets are mostly about identity, and about what happens while an agent runs. Tenet 1 is distinct agent identification, with a credential lifecycle of its own. Tenet 3 is least and zero standing privilege, meaning no persistent rights when idle. Tenet 4 is short-lived, dynamic and revocable authorization, verified continuously at runtime. Tenet 5 is human-in-the-loop triggers, designed against consent fatigue, meaning approvals granted from habit rather than judgment. Tenet 9 is continuous monitoring for compromise and drift.

MirrorOS governs the moment before an action. It does not issue agents their identities. It does not hold or rotate their credentials. It does not watch them while they run, and it does not escalate a decision to a human in the middle of a task. Those layers are not built, and reading NIST's list in October was, among other things, reading a tidy description of our own unfinished business. NIST's own sentence covers us as fairly as anyone. Not all of the tenets will be immediately fulfilled by the current state of standards and technology.

We would rather state the gaps ourselves. The convergence and the gaps are equally checkable from the same two documents.

What I take from it

We expect the practical effect to land in procurement and security review. The questions a buyer should ask an agent platform are now written down by NIST, in plain language, with the reasoning attached. Where does the policy decision sit relative to the model? Is the decision deterministic? Who keeps the record, and can the agent touch it? A vendor whose whole answer is that the model has guardrails now has to answer tenet 7 in writing.

For a company of our size, the lesson is plain. Publishing design reasoning early, with a date on it, is how a two-person company takes part in a standards conversation it cannot buy its way into. The commitments were in print in March. The questions were written down by NIST in October.

The March post ended with this: "Trust in AI agents isn't built by making better models — it's built by making better systems around them." Seven months later, the federal standards body published ten tenets for the systems around them. MirrorOS stands as preserved work for now. When it moves again, it will move against a written list, NIST's list, and so will everyone else's.

A note on method, for the reader who wants the scope stated plainly. This post compares two published designs, ours from March and NIST's from October. It does not rest on an audit of our code against the tenets, and nothing here claims that MirrorOS meets the tenets or is certified against them. That audit is still pending. Where the designs point the same way, we have described them as aligned. Where ours does not reach, we have said so.

The March post: Before the Agent Acts: The Governance Gap in Enterprise AI. The NIST post: Design Tenets for Agent Identity Management Systems.