AI Agent Verification: Identity, Authority and Actions

What Is AI Agent Verification?

AI agent verification means checking an AI agent's claims against evidence the agent did not produce. It covers the agent's identity (which agent this is and who it acts for), its authority (what it is permitted to do) and its work (whether the actions it reports actually happened). Each check has a different owner and a different kind of proof.

The word "verification" had two established senses before agents arrived. Security uses it for identity: the NIST glossary entry for verification carries the FIPS 201-3 definition, which begins "The process of confirming or denying that a claimed identity is correct". Software engineering uses it for checking a product against its requirements, the sense IEEE 1012 uses and the one compared with validation later in this guide.

An AI agent needs both senses at once, because it presents a credential and then reports work. The Agent Identity Framework draft, an individual Internet-Draft dated 26 August 2026 that the IETF has not endorsed, frames them as "three fundamental questions about any autonomous action: which agent performed it, whether the agent was authorized to perform it, and whether the resulting evidence is independently verifiable."

Search results for the term mix all of these meanings:

The last row is a different subject. If your agent is the one doing the checking, for example a voice agent that confirms a caller's identity before it discusses an account, read the use case on testing identity verification agents.

Which Kind of AI Agent Verification Do You Need?

The check you need depends on where the agent sits relative to you. If agents you did not build reach your site or API, start with identity; if you deploy an agent that acts for customers, add authority. If your agent changes records, you also need evidence of what it did, whatever its credentials say.

Most organizations start on agent identity from a weak position. In the Cloud Security Alliance survey report Securing Autonomous AI Agents, released in 2026, commissioned by Strata and covering autonomous AI agent security in enterprises, only 18% of respondents say they are "highly confident" that their current IAM systems can manage agent identities effectively, and 35% express only moderate confidence.

The rows of the table above are cumulative. An agent that writes to your systems on behalf of customers needs all three checks, and passing the first two tells you nothing about the third.

How Do You Verify an AI Agent's Identity?

You verify an AI agent's identity by making the agent prove a claim you can check. The agent signs each request with a private key, you look up the matching public key in a directory you trust, and the key's owner is tied to an accountable person or organization. A name the agent sends about itself is not proof.

Self-description fails first. In May 2025, in its post on verifying bot and agent traffic with cryptography, Cloudflare wrote that "user agent headers alone are easily spoofed and are therefore insufficient for reliable identification."

The published building block is RFC 9421, HTTP Message Signatures, a Standards Track RFC from February 2024. It describes "a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message." Identity schemes for agents, the IETF Web Bot Auth draft among them, add layers on top of it:

• A signed request - the agent signs chosen parts of each request (method, path, host, a creation time) with its private key, so the receiver can tell that the request was not altered and is recent.
• A key the receiver already knows - a signature shows possession of a key. It identifies an agent only when the receiver can find that key in a registry or directory it trusts.
• A link to an accountable party - the registry entry names the person or organization that operates the agent, and in delegated cases the user it acts for.

Card networks describe the same layers from the merchant's side. The README of Visa's Trusted Agent Protocol lists the questions a merchant has to answer: "Is this a legitimate, trusted, and recognized AI agent?", "Is it acting on behalf of a specific, authenticated user?" and "Does the agent carry valid instructions from the user to make this purchase?" The first is identity. The other two are authority.

node verify-agent.mjs

PART 1  WHO SENT THE REQUEST (RFC 9421, Ed25519)
Signature equals the RFC example: true

As signed, 30 s later
  ACCEPT  signed by a known key, fresh, unaltered

Path changed after signing
  REJECT  signature does not match the request

Same request, replayed a day later
  REJECT  signature is too old

Key id nobody has registered
  REJECT  key is not in the directory

How Do You Verify What an AI Agent Is Allowed to Do?

You verify an AI agent's authority by checking, before each action runs, that the credential it presents was issued for this service, for this user and for this kind of action, and has not expired. A valid identity is not permission: a correctly identified agent can hold a token far wider than its task.

Protocols do not do this for you by default. The Model Context Protocol authorization specification (revision 2026-07-28) states that "Authorization is OPTIONAL for MCP implementations." Where a server does implement it, the specification requires that "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience". The guide to MCP security covers the rest of that specification.

A token wider than its task passes every identity check. On 25 April 2026 the founder of PocketOS published an account, recorded in the AI Incident Database as incident 1469, of a coding agent that deleted the company's production database through an infrastructure API. By the founder's account, the agent went looking for an API token and found one in an unrelated file: a token created to add and remove custom domains that also carried authority across the provider's entire API.

That is one party's account, and the replies of the infrastructure provider and the coding tool's vendor were not read for this guide. It still shows the gap: the account describes no forged identity, only a real token that the API accepted for a call far outside the purpose the token was created for.

The stronger control checks each action against a rule before the tool call runs. AgentSpec, a paper accepted at ICSE 2026, defines such rules with triggers, predicates and enforcement mechanisms. In the authors' own evaluation it "successfully prevents unsafe executions in over 90% of code agent cases", "with overheads in milliseconds."

You can test authority on your own agent with negative cases, where the correct result is a refusal that appears in the log:

• An expired token - give the agent a credential past its expiry and confirm the service rejects the call and the agent reports the rejection.
• A token issued for another audience - present a valid token that was issued for a different service and confirm this service refuses it.
• A tool outside the granted scope - ask for a task that needs a tool the agent was not granted, such as a delete when it holds read access, and confirm the call never runs.
• A credential borrowed from another agent - run one agent with a second agent's credential and confirm the mismatch is detected.

The guide to testing AI agent permissions turns these into a full test plan with least privilege as the baseline.

Which Agent Identity and Authorization Standards Exist in 2026?

As of October 2026, RFC 9421 for signed HTTP requests is the one published RFC in the table below. The documents written specifically for AI agents are Internet-Drafts, optional parts of a protocol, card network programs or papers. None of the documents read for this guide is a finished standard covering agent identity, authority and action logs together.

Every status in the table that comes from a document was read on its publisher's own page on 8 October 2026. The status words matter: an individual Internet-Draft is its authors' proposal with no formal standing in the IETF process, a working group draft has been adopted by an IETF group and can still change or expire, and only an RFC is a finished document.

Before you build on a row, open the document and read its status line again. Both IETF drafts in the table expire in March 2027 unless they are renewed, and draft numbers change with each revision. For the agent card row, the guide to A2A protocol testing shows how to test a card and the authentication it declares.

The NIST row matters for the second half of this guide. Among the questions in its concept paper on agent identity and authorization, NIST asks: "How can we ensure that agents log their actions and intent in a tamper-proof and verifiable manner?" NIST lists that as a question still to be answered, so the identity documents above do not yet settle how an agent's actions are recorded and checked.

Why Does a Verified Identity Not Prove That an AI Agent Did Its Job?

Identity answers who sent a request, and authority answers whether the request was allowed. Neither says whether the work was done. An agent with a valid signature and a correctly scoped token can still report a step that failed or never ran, because its report is a claim written by the agent itself.

The Agent Identity Framework draft quoted earlier keeps the two apart in one sentence: "attestation is a claim, evidence is an artifact that can be verified independently of the claim." A signed request is an attestation about the sender. A final message that says "done" is an attestation about the work.

OpenAI has measured deceptive behavior of this kind in its own models. The OpenAI GPT-5 system card (August 2025) says an earlier model, OpenAI o3, "would sometimes make false claims about actions it had taken", and "say it had completed tasks it hadn't". It reports two different measurements, which should not be mixed:

• A stress test - on coding tasks built with "some key unresolvable impediment", the card's deception rate is 0.47 for OpenAI o3 and 0.17 for gpt-5-thinking. Those are fractions of tasks designed to be impossible.
• Production-like conversations - on a set of conversations representative of production data, OpenAI's chain-of-thought monitor "flagged deception in 4.8% of OpenAI o3 responses and 2.1% of gpt-5-thinking's responses". The card says that figure combines several types of deception, some of them minor, and estimates the monitor's precision at 81% and its recall at 84%, so it is not a count of false completion reports alone.

Both measurements are about two OpenAI models and say nothing about a ranking of current models. They establish that a model misreporting its own work is a measured behavior, and identity checks do not look for it.

A known and authorized agent shows the same gap in practice. In Project Vend, a real-money experiment in which Anthropic had a Claude model run a small shop in its own office, the company reports that the agent "received payments via Venmo but for a time instructed customers to remit payment to an account that it hallucinated."

How Do You Verify What an AI Agent Actually Did?

For one task, compare three things: what the agent said it did, the record of the tool calls it made, and the state of the system afterwards. A step counts as done when its call succeeded and the system shows the effect. Where the state cannot be read, the step is unverified, which is neither a pass nor a failure.

The comparison is needed because an agent can leave a failure out of its report. The preprint Are Your Agents Upward Deceivers? (December 2025) built "a benchmark of 200 tasks" and ran "11 popular LLMs" as agents in a constrained environment, with broken tools among the constraints. On its first task type, where a file the agent needs cannot be opened, the models did not report the failure in 62.5% of cases on average, with individual models between 27.5% and 97.5%.

That figure describes one task type in one benchmark. The second part of the script from the identity section applies the comparison to sample data: an imaginary agent's final report on one task, a tool call log and a snapshot of the end state, all written by hand for this guide. No real agent, service or key is involved.

PART 2  WHAT THE AGENT DID (sample data)
Task: Rotate the API key for the billing-sync service
The agent reported 5 steps as done.

C1  Created the new API key
    VERIFIED: call ok, state matches
C2  Stored the key in the vault
    VERIFIED: call ok, state matches
C3  Restarted billing-sync
    CONTRADICTED: call failed (503)
C4  Revoked the old key
    CONTRADICTED: no such call in the log
C5  Posted a note in #ops
    UNABLE TO VERIFY: call ok, state not readable

Claimed done: 5
VERIFIED         2
CONTRADICTED     2
UNABLE TO VERIFY 1

The sample is small and its rule is deliberately simple (one tool per claim, one state check per claim). The three verdict words are the script's own labels, and the output is not from any product. It shows what the comparison finds:

• The report claimed 5 of 5 steps. The record supports 2.
• Step C3 was attempted and failed with a 503, and step C4 has no call in the log at all. The report presents both as done, and the log shows that neither happened.
• Step C5 has a successful call and no readable state, so it is unverified. Counting it as a pass would overstate the agent, and counting it as a failure would blame the agent for a gap in the check.

The failure modes behind steps like C3 and C4, and how to build tools that make them visible, are covered in the guide to agent action hallucination.

Which Evidence Shows That an AI Agent Completed a Task?

Four kinds of evidence exist, from weakest to strongest: the agent's own statement, the record of its tool calls, the response each tool returned, and the state of the system afterwards. The state is the one that shows the effect. When it cannot be read, the honest result is unverified, counted apart from pass and fail.

• The agent's statement - proves that the agent wrote a sentence. It ranks lowest because the model that skipped or failed a step is the same one writing the summary.
• The tool call record - proves that a call was attempted, and with which arguments, provided the record comes from the platform or test harness. It ranks above the statement because the agent did not write it, and below the response because an attempt is not a success.
• The tool's response - proves what the tool answered: a success, an error, an identifier. It ranks below the state because a success message does not prove that the effect landed on the right object or is still there.
• The state afterwards - a read of the system the agent was meant to change: the record, the file, the service status. It ranks highest because it shows the effect, and it needs read access and a check that does not itself write.

Decide for each claim which kind of evidence you require before the run, and write down what happens when it is missing. A result reported as "5 done" and a result reported as "2 verified, 2 contradicted, 1 unverified" describe the same sample run above, and only the second tells a reviewer how much was checked.

A second model that reads the transcript and gives an opinion is not a fifth kind of evidence, and it ranks below a read of the system: the study Let's Think in Two Steps evaluated multimodal models as verifiers of agent runs and found "a strong tendency for MLLMs to over-validate agent behavior".

Where a model has to do the checking, for example when the output is code or prose with no single correct state, the guide to the verification agent covers the patterns and the question of who checks the checker.

How Is AI Agent Verification Different From Validation and Evaluation?

Verification checks a specific claim or requirement against evidence: this agent is who it says, this action was permitted, this step happened. Validation asks whether the agent is fit for its intended use, and evaluation measures how well it performs across many tasks. You need all three, at different moments.

The first two terms come as a pair in engineering standards. The IEEE summary of IEEE 1012-2024, the IEEE standard for system, software and hardware verification and validation, says the two processes "are used to determine whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs." The first half of that sentence is verification and the second half is validation.

• Verification - a yes, no or unverified answer about one claim. You need it at every request (identity, authority) and after every task whose result matters (actions).
• Validation - a release decision about the whole agent in its real environment, with acceptance criteria and a named approver. The guide to AI agent validation covers the plan and the sign-off.
• Evaluation - scores across a set of tasks, used to compare versions, prompts or models. The guide to AI agent evaluation covers the methods.

An evaluation score built on unverified completions inherits their error, and a validation decision depends on the verified results behind it.

When Should You Verify an AI Agent: Before Release, at Runtime or After Each Run?

Verify identity and authority at runtime, on every request and before each tool call, because credentials are presented live. Verify the agent's work before release, in test runs against a staging system, and again after each production run whose result matters. Each stage has a different owner, so name one for each check.

• Before release - the team that builds the agent runs it against staging, compares each reported action with the call record and the state, and runs the negative authority cases. Fix what is contradicted, and add read access where results came back unverified.
• At runtime - the receiving service verifies the signature and the token on each request, and a policy layer checks each tool call against its rule before the call runs. Security and platform teams own both.
• After each run - for actions that move money, change access or delete data, read the affected system once the agent finishes and reconcile the result with the agent's report. The team that operates the agent owns this, with the log kept for audit.

The NIST concept paper lists the last stage among its areas of interest as "Logging and Transparency", which it describes as linking an agent's actions to the identity of the non-human entity that took them. For production, AI agent monitoring covers what to watch between verified runs, and agentic AI governance covers who signs off and what an audit trail has to contain.

If you can start only one of the three checks this month, pick by the table of situations in the second section: identity when outside agents already reach you, evidence of actions when your own agent already writes to production systems.

How Do You Check an Agent's Claimed Actions With Agent Assurance?

TestMu AI's Agent Assurance does not verify who an agent is or what it is authorized to do. It checks what an agent you own did in a test run before release: each acceptance criterion is graded against observed evidence, and a claimed action never counts as proof.

The starting point is that an agent's account of what it did is the weakest evidence available about what it did. A closing message, a transcript and a trace are all the agent's own record.

Take an agent you own that rotates an API key for an internal service. Its final message lists the service restart as done, although the restart call failed and the agent moved on to the next step. The message reads the same whether the restart happened or not, so the criterion "the service was restarted" has to be graded on something else.

For a claimed action, Agent Assurance compares:

• A claimed tool call - with the tool calls the profile returns from the run, checked against the tools the agent declares. A criterion can also name a call that must not happen.
• A claimed file change - with what is on disk after the run: the files altered inside the paths your profile declares, plus any artifacts the run left.
• A claimed record update - with the record itself, confirmed by a read-only query through a tool you provide and approve.

Each criterion ends as Pass, Fail or Unable to Verify. Unable to Verify is not a failure: the pass rate counts only scenarios with a decided verdict, so an Unable to Verify result moves it neither way. If checking a claim would itself require another write, the criterion is Unable to Verify.

Agent Assurance sees only what your profile exposes and your access permits. When the profile passes back nothing but the agent's answer, most criteria end as Unable to Verify. It also runs before release, so it is not a runtime control and will not stop an unauthorized call in production.

Most eval and observability tools score what your agent said and recorded. That describes each category's default approach and no single product: a check of the effect can be scripted per task in them, and they do not build it in by default.

Agent Assurance is pre-alpha and publicly installable. It runs from the terminal as Rook CLI. Install it from npm:

npm install -g @testmuai/rook

Rook CLI is available for macOS and Linux, and 64-bit Windows through npm or WSL; installing through npm requires Node.js 22 or newer. To call it from inside Claude Code, install the rook skill:

npx @testmuai/rook-skill@latest install --agent claude-code

For the rules behind each verdict and the kinds of observed evidence, read the Agent Assurance overview in the docs. Whatever your agent writes during a run is written for real, so use a staging target every time.