Comparison

Keigen Evidence Methodology vs AI Agent Identity

Why Identity Alone Does Not Prove Commercial Action

AI agent identity tools answer three questions: who is acting, whether the actor is authorized to act, and whether the action was logged. The Keigen Evidence Methodology answers a fourth: whether what the actor did meets the commercial, operational, contractual, or compliance standard required for the decision that follows — and whether the evidence is designed to support external review.

The two categories are not competitors. Identity is the foundation. Evidence is the layer above it. An enterprise running AI agents in commercial workflows needs both, and conflating them is one of the most expensive category errors in the 2025–2026 agentic commerce conversation.

This article maps the layered architecture from agent identity through to decision-grade evidence, walks through a worked example showing where each layer ends, and explains how the Keigen Evidence Methodology integrates with — rather than replaces — the AI agent identity work being standardised by MIT, the OpenID Foundation, NIST, and the major payment networks through 2026.

The four-layer stack

Every commercial action taken by an AI agent that will face later review involves four layered questions. Each layer depends on the one below it. Identity work has produced strong standards for the bottom three. The fourth — evidence designed to support external review — is where the Keigen Evidence Methodology operates.

Layer 4 — Evidence Does the action meet the commercial/operational/contractual standard required for the decision that follows? Can the evidence support external review? Keigen Evidence Methodology
Layer 3 — Auditability Was the action logged with distinct attribution to the agent and the human user it acts on behalf of? SCIM agent schemas, OAuth audit logs, AP2 Mandate signing, Stripe SPT observability
Layer 2 — Authorization Is this agent permitted to perform this action, within what scope, and under whose authority? OAuth 2.1, OIDC, On-Behalf-Of flows, scope attenuation, FAPI, Trusted Agent Protocol
Layer 1 — Identity Who or what is the entity taking the action? SPIFFE/SPIRE workload identity, Web Bot Auth (IETF RFC 9421), Mastercard agentic tokens, OIDC-A

The bottom three layers are well-served by published standards and rapidly-developing industry frameworks. Keigen does not compete in that work. The fourth layer — whether the action’s substance meets the standard a CFO, sponsor, regulator, auditor, or counterparty will require months later — is structurally a different question, requires different artifacts, and is where Keigen operates.

What AI Agent Identity does

The AI agent identity conversation has matured rapidly through 2025 and into 2026. Three reference points anchor where the field now sits.

In January 2025, MIT researchers published Authenticated Delegation and Authorized AI Agents, proposing extensions to OAuth 2.0 and OpenID Connect to enable verifiable delegation from a human user to an AI agent — distinguishing authentication (identity), authorization (permitted scope of action), and auditability (verifiable logs). In October 2025, the OpenID Foundation released Identity Management for Agentic AI, a comprehensive whitepaper covering OAuth 2.1 with PKCE, Model Context Protocol authentication, SPIFFE/SPIRE workload identity, SCIM extensions for agent lifecycle management, recursive delegation, scope attenuation, and Web Bot Auth for browser and computer-use agents. In February 2026, NIST published a concept paper through the National Cybersecurity Center of Excellence titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, with a public comment period closing 2 April 2026.

The major payment networks have moved in parallel. Mastercard’s Agent Pay Acceptance Framework, announced in 2025, registers and verifies AI agents before permitting them to transact, using agentic tokens at the Content Delivery Network layer through Web Bot Auth. Stripe introduced the Agentic Commerce Protocol (ACP) in September 2025 and the Agentic Commerce Suite in December 2025, including Shared Payment Tokens (SPTs) — agent-scoped credentials bounded by seller, time, and amount. Visa published the Trusted Agent Protocol with full merchant specifications, building on IETF RFC 9421 HTTP Message Signatures and Ed25519 cryptographic signing. Worldpay, Visa, and Cloudflare announced collaboration on the same protocol stack in October 2025. Google’s Agent Payments Protocol (AP2) introduces signed Intent Mandates and Cart Mandates as cryptographic proof of user intent in autonomous transactions. KYAPay binds agent identity verification to payment authorization tokens for programmatic onboarding.

Read across all of this work, the pattern is consistent. Each framework answers some combination of three questions: Is the agent who it claims to be? Is it authorized to perform this action with this scope on behalf of this user? Can the action be logged with distinct attribution to both the agent and the user?

These are foundational questions. The agentic commerce conversation cannot proceed without strong answers to them, and the agentic commerce conversation does now have strong answers — through the standards, frameworks, and protocols catalogued above. Through late 2026 and 2027, the bottom three layers of the stack are likely to become increasingly operational across enterprise and consumer agentic deployments.

The OpenID Foundation paper itself names the limit of this work clearly. Today, an API call made by an agent on a user’s behalf is often “logged indistinguishably from an action taken directly by the user.” Even with strong identity, authorization, and audit trails, the records produced answer who acted — not whether what they did meets the standard required for the decision that follows. That gap is what evidence infrastructure addresses.

What Keigen Evidence Methodology does

The Keigen Evidence Methodology operates one layer above the agent identity stack. The thesis sentence is short enough to quote and operational enough to apply: if a result matters commercially, operationally, contractually, or for compliance, someone must be able to show what happened, who acted, under what rules, and what evidence can support review.

Identity work answers the who acted clause. Evidence infrastructure answers the what happened, under what rules, and evidence can support review clauses.

The methodology is graduated across three levels. Level 1 outputs are decision-useful but lightweight — diagnostic reports and confidence-graded verdicts that a buyer can verify through normal business action without needing a heavy evidence pack. Level 2 outputs apply lightweight evidence controls selectively to high-risk paths — high-ticket order trails, custom-item delivery records, sponsor-funded campaign segments where downstream review is predictable. Level 3 outputs are full evidence infrastructure with manifest, custody log, qualified electronic timestamping, QA results, methodology version, and a verifier readme that allows independent inspection. Level 3 is where Keigen sits clearly above the agent identity stack: a Verified Draw evidence pack, an AI-agent work output bound to a TimeToPoint billing record, or an RBG high-ticket dispute pack.

The methodology is built against published standards rather than proprietary protocols. It integrates with C2PA Content Credentials for provenance, NIST AI RMF Generative AI profile for AI risk documentation, ISO/IEC 42001 for AI management system structure, EU AI Act Article 11 and Annex IV for high-risk system documentation, ISO/IEC 27037 for digital evidence collection guidelines, JSON Schema 2020-12 for manifest validation, RFC 3161 for timestamp protocols, and qualified electronic timestamps from EU-listed Qualified Trust Service Providers under UK eIDAS. Where the agent identity stack uses RFC 9421 HTTP Message Signatures to sign the request, the Keigen evidence layer uses qualified timestamps and structured manifests to seal the finding — including the upstream identity-layer evidence as part of its custody chain.

Six topic pillars organise the methodology’s commercial application: provenance and authenticity, buyer motion vs noisy identification, reported growth vs earned growth, evidence of work in human-AI systems, governed outcomes and defensible selection, and assurance before compliance. Each pillar maps to a Keigen product domain and to a specific commercial question that agent identity does not — and structurally cannot — answer.

The boundary: identity proves who; evidence proves what-met-standard

The cleanest way to see the boundary is to walk through the specific questions each layer can and cannot answer.

The agent identity stack can answer: Was this agent registered by an approved Payment Scheme? Yes — Visa Trusted Agent Protocol signature verified. Did the user authorize this transaction with this scope? Yes — AP2 Intent Mandate and Cart Mandate signed and chained to user identity. Was the request fresh and replay-protected? Yes — RFC 9421 HTTP Message Signature with timestamp and nonce within tolerance. Was the action logged distinctly to agent and user? Yes — OBO flow produced an access token with both sub (user) and act (agent) claims, captured in the audit log.

What it cannot answer: Was the substance of what the agent ordered consistent with what the user actually wanted? Did the delivered item match the order specification? Was the campaign that drove this transaction free of contamination from incentivised traffic? Was the allocation step — if any — performed against fixed rules with frozen inputs and verifiable randomness? When the customer disputes the charge sixty days later, what evidence will the merchant produce that can support Visa or Mastercard chargeback review?

These are not extensions of the identity question. They are categorically different questions, and they sit one structural layer above the layer where AP2 Mandates, Trusted Agent signatures, and SPT lifecycle observability operate. A perfect answer at the identity layer — every Mastercard agentic token verified, every AP2 Mandate signed, every audit log captured — does not produce an answer at the evidence layer. It produces one of the inputs the evidence layer requires.

The Keigen Evidence Methodology consumes the agent identity stack as input. A Level 3 evidence pack records the verified agent identifier, the OBO access token claims, the AP2 Mandate hashes, the qualified timestamp, the policy applied, the QA results, and the verdict. The pack is sealed with its own qualified electronic timestamp from an EU-listed provider and structured for independent verification. The agent’s identity becomes part of the custody chain. It is not the output.

Worked example: agentic commerce on a high-value order

Consider an AI agent making a £24,000 jewellery purchase on behalf of a customer through a consumer chat interface. Walk through the layers.

Layer 1 (Identity). The agent is a Visa-onboarded provider in the Visa Intelligent Commerce programme. When it navigates to the merchant’s product page, it includes an Agent Recognition Signature using RFC 9421 HTTP Message Signatures with tag=agent-browser-auth. The merchant’s CDN — Cloudflare in this scenario — verifies the Ed25519 signature, confirms the timestamp window (under 8 minutes), checks the nonce against recent records, and recognises the agent as legitimate. Identity verified.

Layer 2 (Authorization). When the agent moves to checkout, it presents an AP2 Cart Mandate signed by the user’s identity provider. The Mandate is bound to the specific transaction: this seller, this cart contents, this transaction limit, this validity window. The merchant’s payment processor — Stripe in this scenario — verifies the Mandate, processes the Shared Payment Token bounded by seller and amount, and confirms the agent is authorised for exactly this purchase. Authorization verified.

Layer 3 (Auditability). The OBO access token contains the user identifier (sub claim) and the agent identifier (act claim). The merchant’s order management system records both, alongside the AP2 Mandate hash, the Trusted Agent signature, and the SPT lifecycle event. Audit trail captured.

The transaction completes. The customer receives the jewellery five days later. Eleven days after delivery, the customer files a chargeback claim that the item received does not match the order specification — colour, gemstone setting, and finish all disputed. The merchant has the agent identity stack outputs above, all verified.

Now Layer 4 (Evidence). What artifacts does the merchant produce in their chargeback defence? The Mastercard Agent Pay framework’s “purchase intent data” provides the cart contents and transaction limits at order time. That establishes what was ordered. It does not establish what was delivered, whether the delivered item matched the custom specification, whether the QA inspection passed before despatch, or what the timestamps were for each delivery checkpoint. Without an evidence pack at Layer 4, the merchant’s defensible record is the identity stack’s output plus a delivery confirmation — which may or may not survive Visa or Mastercard chargeback review depending on the dispute reason code.

A RealBuyerGrowth Level 2 evidence add-on for high-ticket merchants seals the order specification, custom-item requirements, QA inspection results, despatch checkpoints, and delivery confirmation into a structured pack at the moment of completion — with qualified timestamping at sealing. The pack inherits the Visa Trusted Agent signature, the AP2 Mandate, and the SPT identifier as part of its evidence chain. When the chargeback arrives, the merchant produces a single, verifiable artifact that answers all four layers — and is designed to support the kind of review the £24,000 dispute warrants.

The identity stack made the agent transaction possible. The evidence pack made the merchant defensible.

When you need both

For most enterprise-scale agentic commerce in 2026 and 2027, the answer is both. The agent identity work is foundational — without verified agents, scoped authorization, and OBO audit trails, the transaction infrastructure does not function at all. Mastercard, Stripe, Visa, Worldpay, Cloudflare, the OpenID Foundation, and NIST are doing essential work here. Keigen does not duplicate or replace it.

What the identity stack does not produce is the evidence designed to support external review months later — when a £24,000 chargeback is filed, when a £2 million sponsor activation needs to demonstrate value to the CFO, when a prize-draw winner is challenged and the DCMS voluntary code requires evidence of fair selection, when an EU AI Act Annex IV inspection asks for the technical documentation of a high-risk AI system’s actual operation, or when an AI-agent-produced piece of work needs to support a billing claim against a corporate procurement counterparty.

For low-stakes interactions — small-ticket consumer purchases, routine internal automation, lead-quality assessments verifiable by SDR routine work — Layer 1 through Layer 3 alone are usually sufficient. The graduation principle applies: do not over-engineer evidence for decisions that can be verified through normal business action. For high-stakes interactions where downstream external review is predictable, Layer 4 evidence infrastructure is the difference between a defensible commercial record and a screenshot in an email thread.

Standards integration: how Keigen sits alongside identity work

The Keigen Evidence Methodology integrates with — rather than competes against — the agent identity stack. Specifically:

The methodology consumes Visa Trusted Agent Protocol signatures, Mastercard agentic tokens, AP2 Mandates, SPT lifecycle records, OBO access token claims, and SCIM agent identity records as inputs into its evidence packs. The Keigen manifest schema includes fields for upstream identity-layer artifacts — agent identifier, identity provider, signing protocol, signature verification time, OBO claim structure — so verifiers can independently confirm that the identity-layer evidence was valid at the moment the evidence pack was sealed.

The methodology operates against the same regulatory backdrop. The EU AI Act’s Article 11 and Annex IV requirements apply equally to identity infrastructure and evidence infrastructure for high-risk AI systems. ISO/IEC 42001 AI management system certification depends on both. The DCMS voluntary code for prize draws requires evidence of fair selection — which depends on identity (who is the operator), authorization (who set the rules), and evidence (was the selection performed against fixed rules with frozen inputs).

Where standards bodies are converging on identity at Layers 1–3, Keigen contributes to the conversation at Layer 4 — building against published standards, integrating with the rest of the stack, and operating as a trust-density layer above the identity work rather than a parallel proprietary protocol.

Frequently asked questions

Is Keigen competing with Mastercard Agent Pay, Stripe ACP, or Visa Trusted Agent Protocol?
No. Those frameworks operate at the identity, authorization, and auditability layers (Layers 1–3). Keigen operates at the evidence layer (Layer 4), one structural layer above. The Keigen Evidence Methodology consumes outputs from those frameworks as inputs into its evidence packs.

Why is identity not enough for commercial decisions?
Identity answers who acted and was the actor authorized. It does not answer did what they did meet the commercial, operational, contractual, or compliance standard required for the decision that follows. A perfectly identified, perfectly authorized agent transaction can still produce a delivered item that does not match the order specification, a campaign result contaminated by promotion abuse, or an allocation decision that fails sponsor or regulatory review. Identity is necessary; it is not sufficient.

Does Keigen require AI agent identity infrastructure to be in place first?
For agent-driven flows, yes — the evidence pack is more useful when it can chain its custody to a verified upstream agent identity. For non-agent flows (a human SDR’s lead-quality assessment, a manual ecommerce dispute, a human-operated prize draw), evidence infrastructure operates independently of agent identity work.

How does Keigen relate to the EU AI Act’s Annex IV documentation requirements?
EU AI Act Article 11 and Annex IV require high-risk AI system providers to produce technical documentation including automatic logs of operations and a post-market monitoring plan. Identity infrastructure produces the operations logs. Evidence infrastructure produces the structured, externally-verifiable documentation that supports the post-market monitoring claims. Methods built in 2026 to produce decision-grade commercial evidence become 2027 compliance evidence as enforcement dates take effect.

Is the Keigen Evidence Pack the same as a C2PA Content Credential?
No. C2PA Content Credentials provide tamper-evident metadata for digital media assets — provenance and modification history. The Keigen Evidence Pack provides decision-grade evidence for commercial findings — verdict, custody, qualified timestamping, methodology version. Both reference published standards and could be combined in workflows where both content provenance and decision evidence are needed.

Where does Web Bot Auth fit in the stack?
Web Bot Auth (built on IETF RFC 9421) sits at Layer 1 (Identity) for browser and computer-use agents — it lets a legitimate AI agent cryptographically prove its identity within HTTP requests. It is foundational infrastructure for agentic commerce and is integrated by Mastercard, Visa, Worldpay, and Cloudflare in their respective frameworks. Keigen evidence packs reference Web Bot Auth signatures as part of their upstream custody chain when applicable.

Ready to see the evidence?

Find out how the Keigen Evidence Methodology applies to your commercial decisions.

Get my evidence report Read the full methodology →
← Methodology PillarGlossary →