AI Agent Identity: What NIST’s Design Tenets Leave to Evidence

What NIST published on AI agent identity, and what it is not

NIST’s post proposes design tenets for agent identity management systems rather than a standard, and those tenets will steer the demonstrations of its NCCoE project on agentic identity and authorization. Its authors, Harold Booth, Bill Fisher, Ryan Galluzzo and Tom Clancy, call the tenets “a starting point” and say that “these design tenets will be the guideposts for our agentic demonstrations in the NCCoE.” It is “blog #2 in our series on agentic identity, authentication and authorization,” after an August 27, 2026 post arguing that agentic AI needs a strong identity foundation.

The NCCoE’s agentic identity and authorization project released a concept paper in February 2026, drew over 600 responses and plans a practice guide in the SP 1800 series. The German outlet All About Security covered the tenets on November 2, 2026. Read them as a design brief for AI agent identity management, a picture of where the field should head.

Distinct, cryptographically verifiable agent identities

NIST asks for “unique, cryptographically verifiable identification of agents,” with identities “distinguishable from other identities (e.g., human users, service accounts).” Ideally, the post adds, each identity “should be tied to a specific workload, environment, and approved configuration.” AI agent authentication then means proving the caller is that agent, in that environment, with that configuration. The August post is blunt about today’s shortcuts: “bearer tokens and static API keys do not prove identity,” and “Credential sharing is a bad idea in all contexts.” An agent running on a developer’s token or a shared service account has no AI agent identity of its own and looks like anything else holding the same secret.

Delegation, attenuation and zero standing privilege

Agents often delegate, handing subtasks to other agents. NIST wants agents and the entities that start their tasks to remain “cryptographically linked” throughout execution, and as authority moves down the chain, “scopes attenuate so that downstream entities can never claim more authority than the parent.” The Least & Zero Standing Privilege and Short-Lived, Dynamic & Revocable Authorization tenets remove permanent rights altogether: “All access grants are Just-In-Time (JIT), time-bounded and audience-specific.” Under zero standing privilege, an agent holds no access between tasks. A Human-in-the-Loop Triggers tenet keeps people in the approval path for sensitive actions, mindful of consent fatigue.

Signed mandates and policy kept apart from reasoning

Under the Mandates and Constraints tenet, the task originator “can create cryptographically signed mandate statements that define intended outcomes and constraints for agentic actions.” Because a signed mandate can be verified downstream, it “can support authorization decisions, auditing, non-repudiation and accountability.” AI agent authorization, in this model, sits outside the model’s reasoning. The Architectural Separation of Policy from Reasoning tenet states that “Guardrails alone are insufficient,” and a further tenet calls for Deterministic Access Decisions. Together, they leave the allow-or-deny decision to policy rather than to the agent’s judgment.

Immutable evidence held outside the agent

NIST’s Immutable Evidence tenet says that “the enterprise maintains an unbroken, tamper-evident chain of custody and append-only body of evidence detailing the agent’s identity, the delegated intent, and the resulting actions.” Then comes the condition that carries the weight: “This logging infrastructure is independent of the agent to prevent modification.” The language comes from forensics, where a digital chain of custody answers the same questions for any evidence: who held it, when, and whether anyone could have changed it. Continuous Monitoring relies on these records too, since agents “operate at a scale and velocity that is not achievable for humans and even most deterministic automation.” Where NIST asks for logging the agent cannot modify, TrueScreen gives the orchestrator a place outside the agent’s runtime to send each event and certifies it on arrival, fixing the date at that moment.

What agent identity proves and what it cannot

AI agent identity answers which agent acted, a signed mandate answers with what authority, and neither one proves what the agent actually did. NIST’s design tenets of October 27, 2026 handle them separately, under Distinct Agent Identification and under Mandates and Constraints, but teams often treat them as one package, so it helps to see where each one stops.

Identity answers which agent acted

A verified AI agent identity binds an action to a specific agent, workload and configuration, so you know the request came from the procurement agent in production and not from a test build or a stolen key. It says nothing about what that agent did with its access. An agent with a perfectly valid identity can still misread a supplier catalog, follow an instruction injected into a document, or call the right tool with the wrong amount.

A signed mandate answers with what authority

A signed mandate records what the person or system behind the task asked for and which limits applied, such as an order ceiling or a refund policy. Its signature shows it came from its originator and has not been altered. It describes intent; whether the agent stayed inside it is a separate fact the mandate cannot capture.

Neither proves what the agent actually did

What an agent did is a sequence of events. It read inputs, called tools with particular parameters, got results back and produced an output. Identity and mandate frame those events without recording them, and any record of them is only as good as the place and the moment it was written.

Why the record of agent actions has to live outside the agent

A record the agent can write, edit or delete is the agent’s own account of events, worth no more than the agent’s trustworthiness. NIST places logging outside the agent for that reason, and the same reasoning decides which records hold up when an action is challenged.

A compromised agent and its own logs

Picture an agent hijacked through a poisoned document, or one whose credentials were stolen so that someone else now acts under its AI agent identity. If its activity log sits in storage it can write to, the log is part of what was compromised. Entries can be dropped, reworded or backdated, and the edits look like ordinary log lines. Even without an attack, an agent writing its own history reports what it believes it did, which may not match what the tool server executed. An audit trail between agents meets the same problem at every hop.

What makes a record hold up in a dispute

A record of agent actions holds up when it is captured at the moment of the action rather than reconstructed afterward, written by a component the agent does not control (the orchestrator, the API gateway or the tool server that executes calls), and certified at that point. A time-stamp token of the kind defined in RFC 3161 fixes the date, and a cryptographic seal makes any later change detectable. Anyone should be able to check it without asking the party that produced it, which is the point of independent verification. Certification proves the record has not changed since it was certified, and when that happened. Accuracy comes from the capture point, so the component that writes the record matters as much as the seal on it.

Where current standards stop, by NIST’s own account

By NIST’s own account, “not all of these design tenets will be immediately fulfilled by the current state of standards and technology.” It is a candid admission, and a useful one, because teams deploying agents now have to decide how much of NIST’s target architecture for AI agent identity to build themselves. Regulation points the same way without settling the design. Article 12 of the EU AI Act requires high-risk AI systems to technically allow the automatic recording of events over their lifetime. Not every agent is high-risk, and the AI Act’s record-keeping requirements describe a capability of the system, so for AI agent governance your architecture still decides whether those logs sit where the system could change them.

How is the record of an AI agent’s actions certified?

TrueScreen certifies the knowledge base, the prompts, the operations and the outputs of AI agents through its MCP server and API, each time the system that runs the agent sends a record. Certification starts automatically when a system or agent calls the service, and what matters is who makes that call. When the orchestrator, gateway or tool server sends the record, the agent is not the one deciding what gets recorded, and a certified entry cannot be changed afterward without the change showing. That is the separation between an agent and its record that the Immutable Evidence tenet describes.

Structured events go through data certification as a title plus key-value pairs, for instance the agent’s identity, its mandate reference, the tool called and the result. When content must not leave your perimeter, hash certification sends only its SHA-256 hash, so the file stays with you while its integrity and date are still proven. API keys and MCP connections belong to a workspace in the Portal and can be revoked.

The final step applies a qualified electronic seal and a qualified timestamp under eIDAS, with the timestamp token in the RFC 3161 format. TrueScreen is not a trust service provider and not a certification authority. What you end up with is a certification with legal value under eIDAS: the record carries the date it was certified, and any change after that moment is detectable.

Anyone can verify a certification without involving TrueScreen: the public verifier runs in the browser, uploads nothing, checks the XAdES seal and the RFC 3161 timestamp, and recomputes the SHA-256 hash. The package can also be checked with standard tools, which matters when the other party has no reason to trust your systems.

1. 1

   Certify the mandate when the task starts

   When a task begins, the orchestrator sends the signed mandate, or its hash, for certification. The authority the agent received now carries a date, and any later change to it is detectable.

2. 2

   Certify each tool call where it executes

   Each time a call completes, the gateway or tool server certifies the inputs the agent read and the call it executed, with parameters and results.

3. 3

   Certify the output and keep the package with the case file

   The final output is certified as it leaves the agent, and the package is stored with the transaction records.

   

   Feature

   Data Certification API and MCP Server for AI Agents

   TrueScreen certifies the records your orchestrator sends, from agent prompts to outputs, so any later change is detectable.

   Discover more →

When an agent’s action is disputed: a purchase order and a refund

A certified record moves a dispute away from whose logs to believe and toward what a record that anyone can verify actually shows. It decides nothing on its own, since any evidence can still be challenged and the outcome rests on the facts and the contract. What changes is where the argument starts.

A procurement agent and an order quantity

A procurement agent orders a component in a quantity far above what the buyer expected. The supplier says the order is binding, the buyer says the agent exceeded its mandate, and the agent’s own logs, kept on the buyer’s servers, persuade nobody. Suppose instead the orchestrator had certified the mandate, the supplier data the agent read and the order it sent, each when it happened. The parties can then see whether the mandate allowed that quantity, or whether the catalog listed a different pack size. Here TrueScreen takes the argument away from whose logs to believe, because the mandate and the order carry certifications from the moment they happened and either side can verify them. Who bears the loss still depends on the contract and on how liability for agentic AI is allocated.

A support agent and the terms of a refund

A support agent grants a refund, and the customer later claims a larger amount was promised in the chat, or finance says the refund broke policy. If the gateway certified the conversation turns, the policy document the agent retrieved and the refund call it executed, you can show which terms the agent saw and what it executed. If the policy in the knowledge base was wrong, the certified record shows that too, because certification preserves what was there, not what should have been.

Conclusion