TL;DR: FIDO’s new AP2 and Verifiable Intent standards define how AI agents can act within cryptographic limits, but they leave the root identity question unresolved: how to verify the human and business behind the delegation chain, according to Prove Identity. Without that anchor, agentic commerce becomes a trust problem disguised as a protocol problem.
At a glance
What this is: This analysis says FIDO’s AP2 and Verifiable Intent standards give agentic commerce a cryptographic delegation model, but they do not solve the identity problem at the root of the chain.
Why it matters: IAM, fraud, and NHI teams should read this as a warning that protocol-level authorisation is not the same as verified identity, and that delegation models fail if the originator cannot be trusted.
Context
Agentic commerce is the use of AI agents to carry out transactions within limits set by a human or a business. The governance gap appears when a protocol can describe what an agent may do, but not prove who is behind the delegation or whether that origin identity is trustworthy.
FIDO’s AP2 and Verifiable Intent work is significant because it moves agentic commerce from concept to enforceable structure. The unresolved question for identity teams is not whether an agent can act inside a cryptographic envelope, but whether the human and business identities at either end of the chain can be verified and carried through dispute handling.
Key questions
Q: What breaks when agentic commerce can authorise actions but not verify the root identity?
A: The failure is that a cryptographically valid delegation can still originate from a synthetic, fraudulent, or weakly verified identity. In that case, the protocol enforces limits on the action while leaving the trustworthiness of the actor unresolved. That creates a system that can be technically correct and operationally unsafe at the same time.
Q: Why does agentic commerce create a trust problem as much as a payment problem?
A: Because the agent is only one part of the transaction chain. The real risk sits in whether the human, business, and consent behind the agent can be proven and later defended. If those identities are not anchored, the commerce flow can move money or data with no reliable basis for attribution.
Q: How should security teams govern delegated control in autonomous AI systems?
A: They should treat delegated control as a first-class identity problem, not a by-product of application integration. That means binding every action to a named owner, a defined purpose, and a constrained scope, then reviewing whether the agent still operates within those limits as its behaviour changes. Accountability must remain traceable throughout the agent lifecycle.
Q: What is the difference between agent authorisation and identity verification in commerce?
A: Authorisation answers what the agent may do within limits. Identity verification answers whether the person or business behind that delegation is real, trustworthy, and appropriate to initiate the action. An organisation can have strong authorisation rules and still accept bad identity at the root of the chain.
Technical breakdown
Cryptographic delegation chains in agentic commerce
AP2 and Verifiable Intent define how an issuer, a human, and an agent can exchange proof within constrained terms such as spend limits, merchant scope, and time windows. That makes the delegation itself machine-verifiable, which is useful for payment and transaction enforcement. But the protocol only governs the permissions inside the chain, not the trustworthiness of the identity that started it. In practice, this separates authorisation mechanics from identity assurance, which is where fraud and abuse still enter.
Practical implication: Treat cryptographic delegation as a control layer, not as proof that the originating identity has been verified.
Why identity verification sits outside the protocol
The article’s core point is that FIDO is defining how an agent may act, not how to establish that the person issuing the delegation is real, valid, and appropriately bound to the transaction. That distinction matters because a strong delegation protocol can still carry fraudulent or synthetic identity into a trusted workflow. In other words, the chain can be mathematically sound while the root credential remains operationally weak. For IAM, this is the difference between proving possession and proving trustworthy identity.
Practical implication: Anchor agent authorisation to verified human and business identity before delegation is issued.
Why trust registries become the missing control plane
The article argues that relying parties will need a way to resolve whether the identity behind an agentic transaction is trustworthy, and to preserve evidence for disputes. That points to a trust registry model, where identity attributes, consent records, payment authority, and reputation signals are queryable across sessions. This is not the same as point-in-time authentication. It is longitudinal trust, where the relying party needs continuity from verification through execution to adjudication.
Practical implication: Build identity registries and evidentiary chains that survive beyond the initial transaction event.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cryptographic delegation does not solve identity assurance: AP2 and Verifiable Intent can define what an agent is allowed to do, but they do not prove whether the originator of the delegation is the right human or business. That means the protocol can be formally correct while still carrying synthetic or fraudulently claimed identity into the transaction. The practitioner conclusion is that trust in agentic commerce starts before authorisation, not inside it.
Agentic commerce shifts the failure mode from session control to root trust: Traditional IAM controls often focus on whether a session was authenticated and whether an action stayed inside policy. This model adds a deeper dependency on the quality of the identity credential issued at the start of the delegation chain. If the root credential is weak, the entire commerce flow inherits that weakness.
Trust registry is the named concept identity teams should design around: The missing operational layer is not another agent policy, but a way to verify and resolve the real entity behind delegated action over time. That includes identity attributes, consent, payment authority, and dispute evidence. The practitioner conclusion is that agentic commerce governance needs a durable trust record, not just a permission slip.
Business identity is now part of the authorisation problem: The article correctly treats the business on the receiving side as part of the trust equation, not a background participant. Agentic commerce will not scale safely if only the agent and the human are modelled while merchant identity and transaction legitimacy remain implicit. The practitioner conclusion is that commerce identity must be bidirectional.
Longitudinal proof will matter more than point-in-time login: The article’s strongest insight is that possession of a key or device proves very little without a preserved chain of consent and attribution. In agentic workflows, the relying party needs traceability from action back to actor, not just a valid authentication event. The practitioner conclusion is that evidence retention becomes a core identity control.
From our research library:
- The agentic AI market is already worth $5 billion and is projected to reach $50 billion by 2030.
- Read next: Agentic AI Identity Guide
What this signals
Trust registry becomes the practical control plane for agentic commerce: Identity teams should expect delegated AI transactions to require a durable way to resolve who authorised the action, what authority they had, and whether that authority still stands. Without that continuity, the relying party sees only a valid-looking transaction, not a trustworthy one.
Agentic commerce will force IAM and fraud teams to converge on the same evidence model. Consent, business identity, and payment authority will have to be queryable together, because a protocol that validates action limits but not origin trust shifts the control burden upstream to verification and lifecycle governance.
For practitioners
- Define the root identity signal Specify what evidence is required before an AI agent is allowed to act on behalf of a person or business, including identity proofing, consent, and binding to the delegating account.
- Separate delegation from assurance Map where your current controls prove authorisation only, and where they prove the underlying identity is real, current, and appropriate for the transaction.
- Build a trust registry model Establish how identity attributes, payment authority, and consent records will be resolved and retained across the full transaction lifecycle.
- Extend dispute evidence handling Ensure transaction records can show who authorised the agent, what the agent was allowed to do, and how that proof can be surfaced when a dispute occurs.
Key takeaways
- Agentic commerce protocols can constrain what an AI agent does without proving who truly stands behind the delegation.
- The unresolved gap is not authorisation mechanics but root identity assurance for the person and business behind the agent.
- Identity teams need a trust registry and evidence chain that carry verification, consent, and attribution through dispute resolution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic commerce depends on delegated identity and scoped authority, which AP2 and VI try to constrain. |
| ASI09 — Human-Agent Trust Exploitation | The article centers on proving that the human behind the agent is real and trustworthy. | |
| Recommendation — Map delegated commerce flows to ASI03 and verify that agent authority never exceeds the originating identity. Apply ASI09 to require proof that a human delegation source is authentic before an agent can act. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The governance question is who is accountable for delegated AI action and evidence. |
| Recommendation — Use GOVERN to define accountability, consent, and evidence requirements for agentic transactions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about scoped authorisation for delegated AI action. |
| Recommendation — Apply PR.AA-05 to bound agent permissions to explicit, verifiable transaction limits. | ||
| NIST SP 800-63 | SP 800-63C — Federation | Agentic commerce depends on federation-style trust transfer across parties and intermediaries. |
| Recommendation — Use SP 800-63C to model how identity assertions and trust signals move across the delegation chain. | ||
Key terms
- Agentic Commerce: Agentic commerce is a buying and transaction model where software agents act on behalf of a person. The identity challenge is not just proving who owns the account, but constraining what the agent may do, for how long, and under what revocation and audit rules.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Trust Registry: A trust registry is a governed directory that says which organisations are allowed to issue or verify specific credentials. It does not replace cryptography. It adds the policy and authority layer that makes a credential meaningful in a particular ecosystem.
- Root Identity Assurance: Root identity assurance is the evidence that the entity initiating a delegation is a real and appropriate human or business, not merely a credential holder. In agentic commerce, this assurance sits before authorisation and determines whether the rest of the delegation chain is meaningful or just cryptographically neat.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org