As AI agents begin changing tickets, sending messages, invoking APIs, and moving work across enterprise systems, the identity attached to each action becomes part of the control environment. Proper authentication is necessary, but it does not establish that the action was appropriate or remained within the purpose for which access was granted. An agent can use a valid credential, operate through an approved integration, and still exceed the authority behind the task. NIST’s new design tenets for agent identity management provide a useful structure for examining that problem.
The tenets connect agent identity with delegated authority, limited privilege, independent policy enforcement, monitoring, and evidence. NIST is not proposing that identity alone will make an agent trustworthy. Its approach recognizes that organizations must be able to identify the agent, trace the authority under which it operates, restrict what it can do, and reconstruct the result after execution. The system determining what the agent attempts should remain separate from the system determining what the agent is permitted to do.
Identity Establishes Who Acted, Not Whether the Action Was Authorized
NIST calls for agents to have distinct, cryptographically verifiable identities tied to the workload, environment, and approved configuration. This avoids the common practice of allowing an agent to operate through a person’s account or a broadly shared service identity. A distinct identity improves attribution because the record can show that a particular software component performed the action rather than making the activity appear to come directly from the human user. It also creates a foundation for managing the agent’s credentials and access throughout its lifecycle.
Attribution does not resolve the authority question. An authenticated employee may still lack authority to approve a transaction, while an authenticated system may still lack permission to change a protected record. An agent should be evaluated in the same way. The organization needs to know who delegated the authority, what actions the delegation covered, how long it remained valid, and whether any downstream service received a narrower scope rather than inheriting broad access.
Agentic workflows make this harder because execution can change while the task is underway. An agent may begin with an approved objective, choose another tool, retrieve information from a different source, or delegate part of the work to another service. Each identity in the chain may be valid even when the combined execution moves beyond the original purpose. The control environment therefore has to preserve the connection between the task originator, delegated intent, agent identity, and specific action throughout the workflow.
Authorization Cannot Depend on the Model Governing Itself
NIST’s seventh design tenet separates policy from reasoning. The model or agent may determine what action to attempt, but an external system should determine whether the action is allowed. This limits the ability of prompt injection, malicious content, or an error in reasoning to alter the credentials and policy controls surrounding the agent. NIST states the conclusion plainly: “Guardrails alone are insufficient.”
Instructions inside a prompt can shape behavior, but they do not provide the same assurance as an independently enforced control. A model may misunderstand an instruction, treat untrusted content as a command, or select an unexpected route to complete the objective. If the reasoning system can also expand its permissions or weaken the policy decision, the agent can influence the boundary intended to constrain it. The policy layer must remain outside that reasoning path and make consistent decisions based on verified identity, scope, context, and risk.
The remaining tenets support that architecture. Zero standing privilege limits the access available when the agent is idle, while short-lived and revocable authorization reduces the exposure created by stolen or reused credentials. Signed mandates preserve the intended outcome and constraints, and deterministic access decisions prevent model confidence from becoming the primary basis for permission. Continuous monitoring and independent, tamper-evident evidence provide the information needed to detect changes and reconstruct the action later.
These controls have to operate together. A known agent can still hold excessive access, and a valid token can still be used outside the intended task. A human approval can be weak or stale, while a complete log can faithfully record an action that should never have been permitted. The governance conclusion depends on the combined chain of identity, delegated intent, limited permission, independent authorization, execution, resulting state, and preserved evidence.
Human Review Must Carry Real Decision Authority
Human involvement remains important, although the presence of an approval step does not automatically make the workflow controlled. NIST warns that frequent approval requests can create consent fatigue, causing people to approve access simply to keep the work moving. The record may show a human click without showing a meaningful decision. A useful approval requires the correct person, sufficient context, and recognized authority over the specific action.
Scope and timing are equally important. Approval to use one system should not become implied approval for every action the agent later discovers, and an approval granted at the beginning of a task should not remain valid after the circumstances change materially. Organizations need to define what information accompanies the request, how long the decision remains valid, and which changes require renewed authorization. Without those conditions, human review can become an administrative step attached to a workflow whose actual authority remains unclear.
What Sentinel Is and Why It Is Relevant
Sentinel is a bounded agentic AI governance and workflow simulation environment I have been developing to examine how AI-supported actions move through policy, risk, authorization, human review, execution, evidence, and verification. It uses synthetic records and staging systems so control assumptions can be tested without authorizing production activity. Sentinel is not a certification, production control platform, or claim that an organization has satisfied NIST’s tenets. Its value is narrower: it provides a structured environment for observing where an intended control holds, where it fails, and what evidence is available to support the conclusion.
The current design is intended to separate the model proposing an action from the control evaluating it. It also separates the role permitted to write from the role expected to verify the result. This structure reflects a familiar segregation-of-duties principle because the same identity should not create the request, approve it, execute it, and certify the outcome. The design remains under test, so the role labels and intended permissions cannot be treated as proof that the separation is enforced.
One staging exercise used a synthetic change ticket to evaluate a proposed internal review note. The integration was instructed to create the note as internal, but the receiving system stored the entry as a public comment. The mismatch became visible only after the stored result was read back from the receiving system and compared with the requested action. The test was stopped, and the result was recorded as a control failure rather than described as a successful write.
The prompt contained the intended visibility, and the integration reported that it had performed the action, yet neither fact established that the authorized state existed in the destination. The configured roles also did not prove that the expected restriction operated. The receiving system’s actual state provided the evidence needed to understand what happened. This result shows why an agent’s account of its own action cannot replace independent verification.
The sequence can be separated into four events. Reasoning explains what the agent intended to do, authorization determines what it was permitted to do, execution shows what the connected system accepted, and verification establishes the state that remained afterward. Those events may align during a successful run, but governance cannot assume that they did. A record containing only the request or the integration response may omit the point where the control failed.
The Sentinel exercise has important limitations. It involved one synthetic ticket in a staging environment, no production data, no real infrastructure change, and no automated business decision. The separate writer and verifier permissions still require complete live enforcement testing under their own identities, and the result has not been independently reproduced. NIST has not evaluated or endorsed Sentinel, and this exercise does not establish compliance with the design tenets. The evidence supports a limited conclusion: independent read-back and preserved destination evidence are necessary when the organization needs to prove the authorized result occurred.
Second-Line Review Should Follow the Full Action
Policies describing responsible agent behavior will not be enough for consequential workflows. Second-line risk should be able to follow an action from the original business purpose through identity, delegated authority, policy decision, execution, resulting state, and independent verification. The review should establish which person or organization provided the authority, which agent and approved configuration received it, what systems and tools were included, and whether a downstream service could obtain broader access than the original grant. It should also determine whether the agent could influence the policy control, credentials, monitoring, or evidence intended to constrain it.
Review should continue beyond the access decision. The evidence needs to show what the receiving system accepted, what durable state changed, whether retries or alternate paths were possible, and whether another party could verify the result without relying on the agent’s explanation. The organization should know whether it can interrupt the activity, revoke the authority, reverse the change, and reconstruct the sequence afterward. These questions turn responsible AI from a broad commitment into an examination of whether a specific control operated as intended.
Many of the weaknesses will appear between organizational functions rather than within one technology. Identity teams may manage credentials, security teams may manage policy, technology teams may own the integration, and business leaders may own the decision. Each component can appear to work while the combined process fails to preserve accountable authority. Independent review can examine those seams and determine whether the complete workflow maintains defined limits and produces evidence strong enough to support the organization’s conclusion.
Moving from a Design Principle to Evidence
NIST describes the tenets as an initial direction and acknowledges that current standards and technology may not immediately satisfy every requirement. The NCCoE project is expected to develop implementation guidance, example architectures, and lessons from laboratory work over time. Organizations can still examine their present exposure by selecting one consequential agent workflow and reconstructing the full chain of identity, delegated intent, permissions, authorization, execution, state change, and evidence. That exercise will usually reveal more than another general policy statement.
Strong identity and limited delegation can support adoption because they make responsibility easier to trace and intervention easier to enforce. Deterministic authorization and reliable evidence allow the organization to explain why an action was permitted and demonstrate what occurred in the receiving system. As agents move closer to transactions and system changes, those capabilities become part of the institution’s control environment. The model may propose an action, but it should not control the boundary around its own authority.
Sources
- NIST: Design Tenets for Agent Identity Management Systems, October 27, 2026.
- NIST: Back to the Future—Why Agentic AI Needs a Strong Identity Foundation, August 27, 2026.
- NCCoE Agentic Identity and Authorization Project Resource Hub.
Disclosure
AI assisted with source organization, research support, and drafting. Juan A. Martinez Diaz reviewed and approved the final text and remains responsible for its claims.