Attestation for AI Agents: What It Is and What It Proves

Attestation for an AI agent proves that specified requirements were demonstrated, and that a statement was issued on that basis. That is useful, and it is also much narrower than many agent-security discussions make it sound.

AI agent attestation without the sales gloss

Start with the noun, not the vendor claim. NIST gives the clean definition:

"Attestation is the “issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.” [ ISO/IEC 17000 ]"

— NIST, Software Supply Chain Security Guidance: Terminology

That definition has hard edges. It contains a statement. It contains a decision. It contains specified requirements. It does not say that the system is safe in every respect, that every later action is allowed, or that a reviewer will have enough evidence to reconstruct a disputed event.

For an AI agent, that distinction matters because the agent is not just a static package sitting on a shelf. NIST describes AI agents as software systems that use data and algorithms to autonomously perform tasks. NIST also says agents can work autonomously for hours, write and debug code, manage emails and calendars, and shop for goods. The risk owner should therefore ask what the attestation is actually about.

An attestation could be about a build, a configuration, a device, a control, or a stated requirement. The definition allows that breadth because the requirements are specified elsewhere. If the requirement is enrolment under a recognised identity process, the attestation says nothing direct about whether the agent may approve a refund today. If the requirement is a runtime meeting a named control, it still does not prove that a particular customer record was deleted under the right approval.

This is where agent discussions get loose. A meeting note may say that the agent is attested and then treat that word as if it settled identity, access, runtime permission, and audit. It does not. A single attestation may support one of those questions. It may support several if the requirements are written that way. It cannot support a question it never asked.

The separation is close to the one between identity, permission, and proof. A separate Crelis article on identity, authorization, and evidence makes that distinction at the action level. The short version is simpler: do not let one security artefact inherit the job of another.

Attestation AI agent claims and limits

When an AI agent claim includes attestation, read it as a scoped assurance claim. It should tell you what was checked, against which requirements, who issued the statement, and what decision preceded it. If those items are absent, the word is doing more work than the evidence.

NIST’s work on software agents is not framed as a magic attestation answer. NIST says the National Cybersecurity Center of Excellence is interested in a project to demonstrate how identity standards and best practices can be applied to software agents, with a focus on agentic AI applications. NIST’s concept paper also asks what technologies are being used or planned to support AI agents. Those are scoping questions. They are not a blanket rule that any product labelled attested has solved the operational problem.

The operational problem appears when the agent touches something that matters. A payment release is not made safer merely because a component somewhere has an attestation statement. The release still needs an identity, a permission decision, and evidence that the permission existed at the time of release. The attestation may help one part of that chain. It is not the chain.

NIST puts the agent-access problem this way:

"However, realizing these benefits requires understanding the potential risks from giving AI agents access to diverse data sets, tools, and applications, and applying appropriate identification and authorization controls to mitigate these risks."

— NIST, New Concept Paper on Identity and Authority of Software Agents

That sentence names identification and authorization controls. It does not say attestation replaces them. It does not say a prior statement about a system answers whether an agent should change a credit limit for this account, under this policy, at this moment. The live decision remains live.

A reasonable engineer may object that a sufficiently detailed attestation could include runtime control requirements. That is true. The answer is not to dismiss attestation. The answer is to read the requirement set. If the requirement set covers runtime authorization and retained evidence, then the attestation may be relevant to those concerns. If it covers only enrolment, configuration, or conformity with a development practice, then it should not be stretched into an action-level approval record.

This is also why a tool-call discussion should not start with the word agent. It should start with the action. A file export, a vendor payment, and a calendar update do not carry the same risk. The MCP tool-call authorization question is therefore not whether a tool exists, but who permitted this call and what record survives.

What is attestation security in plain terms

In security, attestation is evidence used in a decision, not the decision itself. NIST Special Publication 800-63B states that attestation information may be used as part of a verifier’s risk-based authentication decision. The phrase may be used matters. It permits use. It does not make attestation sufficient for every authentication decision, and it does not turn authentication into authorization.

That is the first boundary. Authentication asks whether the actor is who it claims to be. Authorization asks whether that actor may do the thing now. Attestation information can support the first question in a risk-based process. It does not, by definition, answer the second unless the attested requirements expressly include that permission model.

The second boundary is correctness. An attested agent can still make a poor recommendation, choose the wrong supplier, or summarise a contract badly. That is not a contradiction. Attestation says specified requirements were demonstrated. It does not certify all future judgement.

The third boundary is later proof. An attestation statement may be available before an action. A dispute usually arrives after the action. The reviewer then asks a narrower question: who allowed this deletion, when, under what policy, and what changed afterwards. A prior attestation may help establish the system’s posture. It is not automatically a complete event record.

NIST’s supply-chain guidance shows the same caution in a different setting:

"Federal agencies that seek more comprehensive attestation capabilities in higher risk scenarios should reference the evolving standards, tools, and practices guidance and Appendices D and E of SP 800-161r1."

— NIST, Software Security in Supply Chains: Attesting to Conformity with Secure Software Development Practices

The wording is cautious. More comprehensive attestation capabilities are treated as something to be sought in higher-risk scenarios, not assumed from the presence of the word attestation. That is the posture a compliance team should copy. Ask what capability exists. Ask what scenario it covers. Ask what it leaves untouched.

The distinction between runtime security and runtime authorization is useful here. Security monitoring may notice behaviour. Authorization decides whether a specific action may proceed. The difference is unpacked in runtime authorization versus runtime security. Attestation can sit beside either. It should not be used to blur them.

What this means if you have to produce evidence

The evidence problem begins when the meeting ends. The agent has acted. The user has complained. The finance team wants to know why a payment went out. The records owner wants to know why a customer field changed. At that point, the agent was attested is only helpful if the attestation maps to the disputed question.

Map the question backwards. The disputed action is the anchor. If the action was a payment release, the evidence must show the actor, the permission, the conditions, and the resulting action. If the action was a record deletion, the evidence must show the same things for that deletion. The statement that a system fulfilled some other requirement is not irrelevant, but it may be beside the point.

This is the place to be strict with language. Do not write attested in a control description without saying attested to what. Do not accept agent is trusted as a substitute for an authorization decision. Do not accept logged as a substitute for evidence that the log answers the approval question.

NIST says the real-world utility of agents is constrained by their ability to interact with external systems and internal data. That is exactly where evidence becomes hard. The action may cross a model, an orchestration layer, an approval step, and the target system. A reviewer will not grade the architecture diagram. The reviewer will ask whether the relevant decision can be shown.

There is a practical way to keep the term honest. Treat attestation as one artefact in an evidence pack. Put it next to the identity record, the runtime permission decision, the policy in force, the action request, the action result, and the retained record. If the attestation helps prove one of those items, keep it. If it merely sounds reassuring, do not let it carry the file.

Practical steps for reading an attestation claim

1. Name the requirement. Write down the exact requirement the attestation says was fulfilled. If nobody can name it, the claim is not ready for a control register.
2. Separate identity from permission. Decide whether the artefact supports identification, authentication, authorization, or later evidence. One artefact may help more than one category, but only if its stated requirements reach that far.
3. Bind it to an action. Test the claim against a concrete event, such as a payment release or record deletion. If the attestation cannot help answer that event, describe its scope more narrowly.
4. Check the timing. Mark whether the statement existed before the action, during the decision, or after the event. A pre-action posture statement and a post-action evidence record do different jobs.
5. Keep the negative finding. If the attestation does not prove authorization, say so in the risk note. Silence is how a scoped assurance turns into an assumed control.
6. Use adjacent controls deliberately. If the missing question is who authorised a specific agent action, treat that as a runtime authorization problem rather than an attestation vocabulary problem.

Crelis treats agent control as a runtime authorization and evidence problem: GREENLIGHT is the permission step, and the product demonstration is where that claim can be tested against a concrete agent path.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Identity Is Not Authorization Is Not Evidence — separates the three questions an agent action raises.
• Who Authorizes an MCP Tool Call? — applies the permission question to a single tool call.
• Runtime Authorization vs Runtime Security — explains why detection and permission are not the same control.
• GREENLIGHT — shows the permission step for agent actions.