The SBOM Becomes the Trust Anchor

October 26, 2026·9 min read

I argued in Agents Broke the Software Bill of Materials that the format has no field for who wrote the code, and that until someone invents that field the only provenance you can produce is logs and policy. I still think that is right. It is not the whole story either. NIST has now published its summary of the 614 responses to the February concept paper behind its agent identity project, and among the proposals commenters filed is one that hangs an agent’s identity off the software artifact that produced it, with the bill of materials carried as metadata for access decisions.

That does not close the provenance gap. It puts the SBOM somewhere else in the architecture.

The question NIST actually asked

The concept paper ran from February 5 to April 2, 2026. Its identification section is four lines long, and three of them are questions:

What metadata is essential for an AI agent’s identity? Should agent identity metadata be ephemeral (e.g. task dependent) or is it fixed? Should agent identities be tied to specific hardware, software, or organizational boundaries? How would this be enforced?

None of them is rhetorical. The second sets up a binary, and the third asks whether an artifact boundary is even the right place to hang an identity. The authorization section then asks the question I keep coming back to, “What are the mechanisms for an agent to prove its authority to perform a specific action?”, followed by one that has aged badly: “How might an agent convey the intent of its actions?”

I read the paper as a menu of open problems. The summary of comments reads like a room full of people answering them.

What the document is, and is not

The summary reports “over 600 responses”; its breakdown chart counts 614, grouped by the sector of whoever sent them, 430 (70%) from industry and 123 (20%) from independents. Those are responses, not 614 people, and the count is the only number the document gives. The first Wayback capture is October 6, which brackets publication.

What it is not is a NIST position. It reports what respondents said, and states that including or omitting a standard “should not be taken as endorsement or rejection,” and that the standards listed are “in various states of maturity.” It also records that “there was no consensus on the exact means” for identifying agents, with splits on trust models and centralization. The agreement it does claim is narrower: “near unanimity” on the concept of identifying agents at all, and “broad consensus” that any secure deployment needs stable trust anchors. Every design detail below is a commenter’s proposal, labeled that way in the original.

The document discloses that the manuscript “was edited with the assistance of Gemini,” with the authors verifying the content.

The evolutionary-versus-revolutionary split and the program’s next steps are in my September post and the October one. This is about the part nobody has read closely.

Commenters rejected the binary, then filled in both halves

The identity section opens by saying the feedback “highlighted a critical architectural debate regarding the lifetime and durability of an agent’s identity,” then quotes a respondent dismantling the framing:

The paper’s discussion of ephemeral versus fixed agent identity presents a false binary. The identity anchor should be stable, tied to the software artifact and organizational boundary that produced the agent. The credential expressing that identity should be short-lived, bound to the anchor via a confirmation claim, and independently revocable.

The summary splits that argument into two sections, one on trust anchors and one on ephemeral access.

The anchor, which the summary describes as drawing “broad consensus across submissions,” is a stable, long-lived root of trust that “should not be tied to an individual, dynamic agent instance, but must instead be cryptographically bound to the foundational layers that produced and housed the agent.” Three functions justify the persistence. Hardware binding ties the deployment environment to TPMs, secure enclaves or organizational keys. Behavioral analysis gives risk engines something stable to profile, which is hard when every instance is a new identity. And structured system metadata, which is where the bill of materials enters:

Attaching immutable, long-lived metadata—such as the model family, software bill of materials (SBOM), and organizational ownership boundaries—to inform continuous access policies.

The credential is ephemeral, bound to that anchor by proof of possession, with three required properties. It expires on completion or timeout of a specific sub-task. Scope attenuates down a delegation chain, “ensuring that a sub-agent never inherits more access than required for its immediate, transient function.” And it can be revoked without disturbing the anchor or freezing other agent workflows.

That is a coherent architecture, and it is not the one the paper proposed. NIST asked whether identity metadata should be ephemeral or fixed. The answer came back that it should be both, at different layers, with the fixed layer bound to the artifact.

Why that changes where the decision happens

An SBOM you file at release is a document. An SBOM attached to an identity anchor as immutable metadata for continuous access policies is a query input. The difference is who reads it and when.

The filed version is read by a person at a point in time and describes what was present then. The version in this design is read by whatever makes the authorization decision, the moment an agent asks to do something, alongside the model family and the organizational boundary. A policy engine could refuse a tool call because the artifact an agent was built from is not on an approved list. I have seen that logic in build pipelines for years. Making it a live input to an agent’s authorization decision is a different move, and it is the one the commenters are asking for.

The supply-chain link is explicit in two other places. In the software development and deployment use case, commenters proposed “using SPIFFE SVIDs for authenticating supply-chain enforcement agents” and, separately, “using SBOM/CBOM for entitlement handling.” CBOM is the cryptography bill of materials, so the entitlement decision would run off what is inside the artifact, down to its cryptographic libraries.

I argued in September that permissions should be a signable supply-chain artifact. This is the first evidence I have that anyone put that to NIST.

I would not build on it yet. It sits in a summary of a comment period with no implementation behind it and no NIST endorsement. But it is the first time I have read a bill of materials described as an authorization input for agents in public.

What it does not do

Binding an identity to an artifact tells an authorization engine which artifact an agent came from. It does not tell you who wrote what is inside it. The SIEP-171 problem, that a consumer “cannot currently learn whether the code was produced wholly or partly by an AI agent,” is untouched, and nothing in the summary proposes a production-method field.

An SBOM is a list of components, and being on the list is not being trustworthy, so a policy gating on the list inherits its weaknesses. A second limit is harder to design around. For an agent built from a model, a framework, a prompt and a set of tools, deciding which artifact “the software artifact and organizational boundary that produced the agent” names is the part the summary never answers.

The gap that got a name instead of a fix

The section I would send to anyone still arguing about agent permissions is the one on intent. NIST asked in February how an agent might convey the intent of its actions. Eight months later the summary opens with the concession that “Intent is not yet a mature standards category, but it is becoming a core design requirement,” and records a commenter putting the problem more sharply than the paper did:

The core argument is that current authorization frameworks answer who is acting but not what bounded authority is being exercised for a specific action, creating an intent dimension that has no standard representation.

The candidate list is long and the summary endorses none of it: OAuth Rich Authorization Requests, transaction tokens, authorization-evidence drafts, FIDO Alliance work on agentic authentication, the Agent Payments Protocol, Verifiable Intent. Signed intent is “seen by our commenters as a necessity,” “no clear consensus exists on how to implement” it, the word itself is not fully defined, and there are privacy concerns about what an intent statement leaks across organizational boundaries.

That is more honest than most agent security writing. The missing piece is named, scoped and still unspecified.

What happens next, and what to ignore

Nothing is scheduled. The project page says comments are now rolling rather than a fixed period, and that community input will inform “the development of a draft project description.” That description has not appeared. The eventual deliverable is a practice guide in the SP-1800 series with no date on it. My September guess about timing was wrong, and I have already written that down.

The formal track moves on a slower clock. The IETF WIMSE working group adopted draft-ietf-wimse-aims-00 on September 15, which frames the problem as “Agents are workloads” and whose revision history includes “Clarify that LLMs should not have access to Agent credentials.” It expires March 19, 2027, and it is not a standard. The August post on SPIFFE and WIMSE covers that stack.

There is no deadline here and nothing that binds a contractor. The NCCoE runs labs.

What an architect can take from it is a direction, not an obligation. The three metadata fields the commenters named are ones you can collect now: model family, artifact with its bill of materials, ownership boundary. You probably generate two of the three. Getting an authorization layer to read them off identity material is where the document stops. How and when metadata is conveyed is, in its words, “still an open topic of debate.” The commenters who raised the metadata gaps also said the protocol extensions and profiles an authorization decision would need are still for standards bodies to write.

My honest reading, after the whole document, is that the SBOM field is the weakest of the three. The model family is a string. The ownership boundary is organizational bookkeeping. The bill of materials is the only one carrying a real format and real tooling, and it is also the one that still cannot answer the question that started this thread: who wrote the code. What has changed is that the artifact an agent came from is now on the table as an authorization input, proposed by commenters rather than by me. I can defend that. I could not defend the claim about SBOMs being dead.