AppliedAI360

AI Agent Verification: How the Industry Is Approaching It (2026)

Identity, authorisation, pre-deployment assurance and runtime verification are being solved by different groups, in different products. This briefing maps who is doing what, how mature each layer is, and the gap that matters most: none of them talk to each other.

22 October 2026

Agentic AIAI Governance

Executive summary

AI agents now take actions, not just produce text: they call tools, move money, send messages and act on behalf of people. Enterprises therefore need to answer four questions about every agent, every time it acts:

  1. Who is this agent? (identity)
  2. Is it allowed to do this, for whom? (authorisation and delegation)
  3. Was it shown to be safe before it went live? (pre-deployment assurance)
  4. Is it behaving correctly right now? (runtime verification)

In 2026 each question has an active community working on it: identity standards bodies and payment networks on the first two, certification schemes and researchers on the third, and “guardian agent” vendors and formal-methods researchers on the fourth. The work is real and moving quickly. But it is happening in separate products, with separate evidence, and the layers do not inform each other.

The consequence is a specific blind spot: an agent can hold a valid identity and a certificate earned at launch while doing something unsafe today, and the bank, merchant or other agent it is dealing with has no way to know. Closing that loop — so that runtime evidence changes an agent’s trust status and counterparties check that status before accepting a request — is the most important open problem in agent verification.

Layer Question Maturity in 2026
Identity Who is this agent? Standards forming quickly; payment-network pilots live
Authorisation & delegation May it do this, on whose behalf? Largely unsolved; identity is not authorisation
Pre-deployment assurance Was it proven safe before go-live? First certification scheme exists; certificates are static
Runtime verification Is it behaving correctly now? Gartner market guide published; most deployments still pilots

1. Identity: who is this agent?

Standards bodies. The US National Institute of Standards and Technology (NIST), through its National Cybersecurity Center of Excellence, published a concept paper in early 2026 on software and AI agent identity and authorisation. Rather than inventing new mechanisms, it proposes applying existing standards to agents: OAuth 2.0/2.1 and OpenID Connect for tokens and delegated consent, SPIFFE/SPIRE for cryptographic workload identity and attestation, SCIM for provisioning and de-provisioning agent identities, and attribute-based access control (NGAC) for least privilege. It explicitly frames the open problems: what metadata defines an agent, whether identities should be per-task or persistent, how credentials are issued and revoked, and how an agent’s actions trace back to an authorising human.

Enterprise identity platforms. The major identity providers now treat agents as a distinct class of identity. Microsoft Entra Agent ID registers and governs agent identities alongside users and workloads; Okta has extended its platform to secure AI agents across identity providers and positions “agentic identity” as a strategic priority. A recurring point from practitioners is that registering an agent’s identity does not, by itself, decide what that agent may do at runtime.

Payment networks and agentic commerce. Payments are where agent identity has moved fastest, because merchants must decide whether to accept a purchase an agent initiates. Visa’s Trusted Agent Protocol signs agent requests so merchants can verify them at the edge, built on HTTP Message Signatures (RFC 9421), with Visa operating the agent registry; Visa reports more than 100 partners in pilot. Mastercard Agent Pay authenticates agents purchasing for consumers. Cloudflare has partnered with both networks so that signed agent traffic can be recognised and distinguished from malicious bots.

Know Your Agent (KYA) start-ups. A cluster of companies is applying know-your-customer thinking to agents: verifying the developer behind an agent, binding the agent to a responsible human, and scoring reputation. Proposals include a five-layer “Digital Agent Passport” (developer provenance, user binding, permissions, behaviour telemetry and risk scoring), public agent reputation directories, and decentralised approaches using W3C Decentralized Identifiers, Verifiable Credentials and an Ethereum agent-registry standard (ERC-8004, on test networks). Many of these are at framework or pilot stage; buyers should separate live capability from roadmap.

What is still missing: a common way for an agent to present not just who it is but what it is currently trusted to do — a credential that reflects its live behaviour.

2. Authorisation and delegation: may it do this, for whom?

This is the least-solved layer. The NIST paper sets out why: agents discover tools and data at runtime, so static permissions go stale; aggregated data can be more sensitive than its parts; least privilege is hard to define for behaviour that is not fully predictable; and “on behalf of” chains — a person delegates to an agent, which delegates to another agent — must remain traceable for human approvals and audit.

The Model Context Protocol (MCP), now the common way agents connect to tools, relies on OAuth for authorisation, which helps at the connection level but does not express business rules such as “no payment above £5,000 without a second approver in the last ten minutes”. Commentators have stressed that identity products leave this decision to runtime policy.

The OWASP Top 10 for Agentic Applications (2026) shows why this matters: identity and privilege abuse (ASI03), tool misuse (ASI02) and insecure inter-agent communication (ASI07) are all failures of authorisation and delegation rather than of identity alone.

3. Pre-deployment assurance: was it shown to be safe?

Certification. AIUC-1, developed with input from Stanford, MIT, MITRE, the Cloud Security Alliance and others, presents itself as the first security, safety and reliability standard for AI agents. It focuses on agent behaviour under pressure — data protection, operational boundaries, attack resistance and error prevention — and certification involves thousands of technical evaluations plus a policy and guardrail audit, with quarterly re-testing. UiPath was the first enterprise automation company to be certified, with the audit carried out by Schellman.

Testing products. Quality-engineering vendors are adding agent assurance offerings that test agents before they ship, extending traditional test automation into agent behaviour.

Research. Recent work proposes a formal “agent operational envelope” — permissions, domain constraints, safety properties, governance rules and autonomy level — from which regulatory, operational and adversarial test scenarios are generated automatically. Tested across fintech, banking, insurance and healthcare with 1,800 scenarios against 125 regulatory requirements, ontology-grounded generation achieved materially higher regulatory coverage than persona-based test generation (48% versus 33%) and issued a machine-verifiable trust certificate with graduated deployment verdicts.

What is still missing: certificates describe the agent on the day it was tested. Agents change constantly — new models, prompts, tools and MCP servers — and quarterly re-testing leaves long gaps.

4. Runtime verification: is it behaving correctly now?

Guardian agents. Gartner published its first Market Guide for Guardian Agents in February 2026, defining them as systems that supervise AI agents to keep their actions aligned with goals and boundaries. It groups capabilities into visibility and traceability, continuous assurance and evaluation, and runtime inspection and enforcement, and identifies six delivery models: standalone oversight platforms, AI/MCP gateways, embedded runtime modules, orchestration-layer extensions, hybrid edge-cloud deployments and cross-agent coordination. Gartner expects enterprises to need an independent control layer that works across platforms, and notes most deployments are still prototypes or pilots.

Formal runtime verification. Researchers are applying temporal logic — rules about sequences of events over time — to agent traces, because many violations are only visible across a session, not in a single message: processing data before consent was recorded, disclosing a person’s data after an erasure request, or acting on untrusted content without confirmation. One study encoding GDPR principles as runtime checks blocked every realised violation in its test cases with no false positives when data categories were extracted accurately, at a cost of about two microseconds per event; with noisy extraction, attack success rose to at most 12%. Stateless filters such as regex and PII detectors missed most session-dependent violations.

A second study replayed attacks from public agent benchmarks against temporal-logic monitors and flagged around 70% of attack chains — but also fired on 29% of benign runs, because benchmark traces rarely record approvals, timestamps or where data came from. Its conclusion is important for anyone building runtime controls: verification is only as good as the trace. Traces must record provenance, approvals and time in a trustworthy way.

Threat model. The OWASP Top 10 for Agentic Applications has become the common reference for what runtime verification must catch: goal hijack through content an agent reads (ASI01), tool misuse (ASI02), identity and privilege abuse (ASI03), supply-chain compromise of tools and MCP servers (ASI04), unexpected code execution (ASI05), memory and context poisoning (ASI06), insecure inter-agent communication (ASI07), cascading failures (ASI08), exploitation of human trust (ASI09) and rogue agents (ASI10).

5. The gaps that matter

  1. The layers are disconnected. Identity, certification and runtime monitoring are sold and operated separately. Evidence from one does not change the others.
  2. Certificates are static. A certificate earned at launch says nothing about an agent that has since changed or is being attacked.
  3. Identity is not authorisation. Knowing who an agent is does not tell a system whether this action, at this amount, for this person, is allowed now.
  4. Traces lack trustworthy history. Runtime checks need provenance, approvals and timestamps recorded in a tamper-evident way; most logs do not provide them.
  5. Counterparties are blind. A bank, merchant or partner agent receiving a request can increasingly verify who sent it, but not whether that agent is currently in good standing.

6. What good looks like: a closed verification loop

The direction of travel points to a single loop in which each layer feeds the next:

  • Declare an operational envelope for each agent: tools, data, limits, autonomy level and accountable human sponsor, with a fingerprinted bill of materials covering model, prompts, tools and MCP servers.
  • Certify before deployment against scenarios generated from that envelope, the applicable regulations and the OWASP agentic threats, producing a graduated trust level rather than pass/fail.
  • Verify every action at runtime against stateful policies, with provenance tracking so content from untrusted sources cannot silently drive high-impact actions.
  • Let runtime evidence change trust status — downgrade, suspend or revoke — automatically and with a stated reason.
  • Let counterparties check that status at the moment of the request, using signed requests and a live credential, and accept, ask for step-up approval or reject.
  • Keep a tamper-evident record that maps each decision to the obligations it evidences: EU AI Act record-keeping and human oversight (Articles 12 and 14), ISO/IEC 42001, the NIST AI RMF and OWASP ASI.

7. Recommendations for regulated organisations

In the next 90 days

  • Build an inventory of agents with an accountable human sponsor and a bill of materials for each.
  • Write an operational envelope per agent and make it machine-readable.
  • Require signed, attributable agent requests for any action that moves money, data or customer outcomes.

In the next 6–12 months

  • Introduce graduated trust levels with automatic downgrade on runtime evidence, not only periodic re-certification.
  • Record provenance, approvals and timestamps in agent traces, in a tamper-evident form.
  • Ask counterparties and platforms how they will verify your agents — and how you will verify theirs.

See it working

The Agent Verification Console in Labs demonstrates the closed loop on three fictional financial-services agents: passport, envelope, pre-deployment certification, runtime verification with attack injection, a living trust certificate, a counterparty check and a tamper-evident evidence trail.

Sources

Vendor capabilities are described as publicly stated by the vendors or reported by third parties, and many are at pilot stage. This briefing is not legal advice.