NIST's proposed agent identity tenets give AI assurance teams a useful starting point for assigning evidence ownership. The practical step is to take one consequential workflow and identify who can prove that its identity, delegated authority and access controls work. A list of principles alone cannot answer those questions.
In an October 27 publication, NIST proposed ten initial design tenets for agent identity management. They cover distinct agent identities, constrained delegation, limited privileges, revocable authorization, human-review triggers, signed mandates, separation of policy from reasoning, deterministic access decisions, monitoring and immutable evidence. NIST says implementation should reflect transaction risk and deployment context, and acknowledges that current standards and technology may not immediately fulfill every tenet.
These are proposed design principles. The publication does not establish a new legal duty or certify a product. Maetra's analysis below focuses on how a compliance owner could turn that proposal into an evidence plan.
Give each control a person who can demonstrate it
Consider an illustrative support agent that can propose a customer refund. Its business owner knows when a refund is appropriate. An identity team manages credentials. An application team controls the refund endpoint. A security team monitors unusual activity. Each can hold a useful piece of the answer, while nobody owns the complete workflow.
Maetra recommends starting with a short record that names the workflow, the consequential action, its owner and the systems that participate. Attach the control question to a responsible team. For example, the endpoint owner should be able to demonstrate what happens when an otherwise valid request arrives with authority that has expired.
The evidence should identify the configuration actually tested. A screenshot from an earlier pilot may establish that a setting once existed, but it cannot establish that today's deployment still uses it. Record the environment, configuration revision, test date and reviewer alongside the result.
Organize the review around a real transaction
The following is a suggested review structure, not an official NIST mapping or a declaration that every deployment can already meet each design goal.
| Review question | Suggested accountable owner | Useful evidence |
|---|---|---|
| Which agent and workload made the request? | Identity or platform team | Identity registration linked to the deployed configuration |
| What authority reached the downstream service? | Application owner | A bounded test showing the requested action and permitted scope |
| What happens when authority expires or is revoked? | Identity and endpoint owners | Denial result captured at the actual enforcement boundary |
| Which risk condition requires human review? | Business control owner | Versioned rule, reviewer responsibility and a test of the pending path |
| Can the agent alter its own retained history? | Evidence infrastructure owner | Access configuration and an independently retained test record |
A small organization may assign several responsibilities to one person. The record should still distinguish the responsibilities. Otherwise a failed test can move between teams without anyone being accountable for correcting it.
Record gaps without converting them into exceptions by default
A useful assurance record has room for uncertainty. If a downstream service accepts a broad credential that cannot be narrowed for the task, record that limitation and the affected action. Do not label the tenet satisfied because the agent received a carefully written prompt.
Maetra recommends separating three states: demonstrated in the current environment, planned but untested, and currently unsupported. Add the evidence link and next review trigger to each state. This makes a roadmap inspectable without presenting future engineering work as an implemented control.
For a high-impact workflow, an unresolved gap may justify reducing the agent's reachable actions while the owner evaluates alternatives. That decision belongs to the organization's risk process. The proposed tenets do not supply a universal risk threshold or make every action require human approval.
Reuse evidence only when the boundary matches
One identity-platform test may support several internal assurance questions. Reuse is helpful when the relying workflows actually use the same configuration and enforcement path. It becomes misleading when a team applies a successful test from one endpoint to another endpoint that accepts a different credential or bypasses the same check.
Keep a simple dependency record: which workflows rely on this evidence, which configuration they share, and what change invalidates the conclusion. A credential-policy change, new downstream service or new delegation path should prompt a scoped review. This is a recommended operating practice, not a freshness interval prescribed by NIST.
An independent Oktsec commentary also discusses runtime checks and deployment gaps. It is the author's implementation assessment of its own product, not a NIST evaluation. Teams should require evidence from their own deployment before accepting any vendor's alignment claim, including Maetra's.
A useful first deliverable
Choose one action and produce a review record another person can follow without joining the original project. Include its owner, current configuration, the authority used, one successful permitted request, one denied request and the unresolved gaps. Have the relevant endpoint owner confirm what those results establish.
Maetra Comply supports framework mapping and evidence management. It can help organize applicable control evidence and its ownership, while deployment teams remain responsible for proving that identity and access enforcement work. For a starting point, explore Maetra's framework coverage and identify one existing control record to improve.
Sources
- NIST: Design Tenets for Agent Identity Management Systems, October 27, 2026.
- Oktsec: NIST's agent identity tenets, read from the runtime, October 30, 2026. Independent vendor commentary, not certification or product validation by NIST.