NIST Published Ten Agent Identity Tenets. Here's Where a Verified Person Fits.
On October 27, NIST published ten design tenets for agent identity management systems, an initial set describing what good looks like for identity, authentication and authorization when software agents act for people. For CISOs and compliance teams, it's a useful yardstick for any program that lets agents act on someone's behalf.
The tenets expect what an agent does to trace back to whoever started the task. When that's a person, NIST's post doesn't say how the person gets identified - and that’s where Proof is aiming to close the gap.
What are NIST's ten agent identity design tenets?
The October 27 post is the second in a NIST series on agentic identity, following an earlier post on why agentic AI needs a strong identity foundation. NIST draws the tenets from public comments on its NCCoE project on software and AI agent identity and authorization and says organizations should apply them according to the risk of the agentic transactions they support. It also calls them a starting point, and says current standards and technology won't meet all of them yet.
Here is a summary of each:
Where a verified person fits
Tenet 02 says an agent and the entity that started its task should be cryptographically linked for the whole run, whether that entity is a person or an organization. NIST's reasoning is that if an agent's actions can't be tied back to whoever initiated them, organizations lose non-repudiation and can't hold anyone responsible for a high-impact action. Tenet 06 adds signed mandates from the task originator, meaning a statement of what the agent may do and within what limits, which downstream services can verify.
When the originator is a person, the link only means something if you know who that person is. We verify the person first, checking their identity against government-issued evidence at NIST IAL2 and tying the result to a certificate from our WebTrust-audited certificate authority. Kantara certifies the identity proofing at IAL2.
Agents also need a way to present that verification to the services they deal with, and that's what x401 is for. It's an open protocol, published by Proof, that lets an agent show a service who it represents and what it's authorized to do.
In practice, the person approves an action in a digital wallet on their own device, and the device signs the approval along with its exact terms. The agent hands that signed approval to the business, which can check the signature and certificate chain on its own. That gives the business the signed mandate tenet 06 describes.
x401 is also designed to interoperate with AP2 and Verifiable Intent, two other ways of recording what a person has authorized an agent to do.
What a verified person doesn't cover
Tenets 01, 03, 07 and 09 are about the agent itself: its identity as software, its privileges, its architecture and its monitoring. A verified person at the root can't make an agent with undue privileges safe or catch a hijacked agent between approvals, so those controls stay with your security and IAM teams. Tenets 04, 05, 08 and 10 also rest on things you run yourself, including revocation, risk thresholds, access decisions and logging. If a vendor says one product covers all ten, ask them to show you.
Questions to ask vendors
Three questions to put to any vendor that sells agent identity:
- Who initiates the agent, and how was that person's identity proofed? (Tenet 02)
- Is the approval bound to the exact action, and does it fail if any term changes? (Tenet 06)
- Can we verify the evidence ourselves, without the vendor vouching later? (Tenets 08 and 10)
How x401 addresses the authorization gap
NIST's tenets call for every agent action to trace back to whoever initiated the task, with limits a business can check. Proof calls the missing identity layer the authorization gap: agentic commerce protocols assume credentials a business can trust, and none of them specifies who issues them.
x401 targets that gap. A website can ask an agent who it's acting on behalf of, what that person approved, check the signed answer on its own, and say yes to an agent acting for a verified customer. Superfluid has announced the first live implementation, and the published specs let any team build its own.
If you build or secure agent systems, read the x401 specification and see how a service can check who an agent represents.
.jpg)
