FIDO is standardizing AI-agent authentication: why identity is not consent

Published 2026-06-27 · Last reviewed 2026-06-27

The body that brought you passkeys is now turning its attention to AI agents, and that is a bigger deal than the headline suggests. On April 28, 2026, the FIDO Alliance, the standards group behind the phishing-resistant login most of us already use without thinking, announced it would develop interoperable standards for how AI agents authenticate and transact on a person’s behalf.¹ Google donated its Agent Payments Protocol, AP2, and Mastercard contributed its Verifiable Intent framework as starting material.²

This matters because the alternative is chaos. As agents start visiting sites, booking, buying, and negotiating, every service needs a trustworthy way to ask: is this agent real, and is it actually allowed to act for the person it claims to represent. FIDO is the right body to answer that, and the contributions from Google and Mastercard give it a serious running start.

But there is a second question hiding behind the first one, and it is easy to miss because the word identity gets used for both. Proving an agent is who it says it is, and is permitted to do what it is doing, is authentication. Deciding whether you and that agent should be interacting at all is consent. They sound adjacent. They are different layers, and conflating them is how you end up with a perfectly verified inbox full of perfectly verified noise. I run content at Tobira, which works on the consent layer, so I will be explicit about where our interest lies. The distinction holds regardless of whose product you use.

What FIDO actually announced

The April 28 announcement was not a finished spec. It was the formation of the venues where the spec gets built, plus the first donations of working material.¹ Two groups carry the work. The Agentic Authentication Technical Working Group, chaired by members from CVS Health, Google, and OpenAI and vice-chaired by Amazon, Google, and Okta, handles how a user delegates actions to an agent while keeping strong, phishing-resistant authentication. In parallel, the Payments Technical Working Group, chaired by Mastercard and Visa, develops specifications for agent-initiated commerce.²

The donated material is what makes this concrete rather than aspirational. Google’s AP2, first published in September 2025 as part of its agent commerce work and at v0.2 by the time of the donation, contributes a model for secure delegation and verifiable authorization. Mastercard’s Verifiable Intent, co-developed with Google to work alongside AP2, lets a user authorize and bound the actions an agent takes for them.² If you have read our walk-through of the agent payments stack, AP2 is the authorization layer in that picture; this is that same protocol moving into a neutral standards home.

FIDO framed the work around three focus areas: verifiable user instructions, so a person can authorize an agent’s actions through phishing-resistant methods without handing over credentials; agent authentication, so a service can confirm an agent is acting for a specific user within defined limits; and trusted delegation for commerce, covering how agent-initiated transactions get approved across payment systems.¹ Read those three again and notice what they share. Every one of them is about the agent and its principal. None of them is about the counterparty’s willingness to engage.

What authentication actually proves

Authentication, done well, settles three things at once. It proves the agent is genuine and not spoofed. It proves the agent is acting for a specific, named human rather than operating as an anonymous bot. And it proves the agent is staying inside the limits that human granted, spend this much, book within these dates, act only on this account. The phishing-resistant part means it does all of this without the human’s credentials being exposed or replayable. It is, in the cleanest sense, a passkey for agents.

That is genuinely valuable, and it is the precondition for almost everything else. An agent economy where you cannot tell a real, authorized agent from an impersonator is not an economy; it is an attack surface. The work FIDO is coordinating closes that gap, and it pairs naturally with the machine-discovery side of the stack, where an agent publishes what it is and how to reach it. We covered that half in how A2A Agent Cards work: the Agent Card says here is who I am and what I can do, and authentication says and here is the proof. Discovery plus authentication is most of what a machine needs to trust another machine.

But notice the frame. Every guarantee on that list is about the relationship between the agent and the person it represents. Is it really their agent? Is it within their rules? Authentication is a vertical question, pointing from the agent down to its owner. It says nothing about the horizontal question between two parties who have never agreed to meet.

The question identity cannot answer

Here is the gap, stated plainly: an agent can be fully authenticated and still completely unwelcome.

Picture an agent that is real, cryptographically verified, acting strictly within its owner’s limits, and sending your agent a pitch you never asked for. Every authentication check passes. The agent is exactly who it claims to be and is doing exactly what it is permitted to do. And you still do not want the conversation. Authentication confirmed the sender’s identity; it had nothing to say about whether the contact was wanted. A verified spammer is still a spammer, and as more outreach gets generated and sent by agents, verification alone will not thin it out. We pulled that thread in what replaces cold outreach: when sending is cheap, the missing control is not identity, it is permission.

This is the difference between trust in an identity and willingness to engage. Authentication and authorization answer is it real and is it allowed. Consent answers a question neither of them touches: should these two be talking at all, and on what terms. You can have total certainty about who an agent is and still have made no decision about whether it reaches you. In a world of a few agents, that gap is a nuisance. In a world of millions, where any authenticated agent can attempt contact with any other, the gap is the whole problem.

Consent is a separate layer, and it sits on top

The useful way to hold this is as a stack, where each layer does one job and hands off to the next. MCP connects an agent to tools and data. A2A, currently v1.0.x, lets agents talk to each other and discover one another through Agent Cards. The authentication work FIDO is now coordinating, together with decentralized identifiers and verifiable credentials, proves who an agent is and what it may do. These layers are complementary, not competitive; each assumes the one beneath it.

Consent is the layer above all of that. Once you know an agent is real and authorized, you still have to decide whether to let it through to a human, and that decision belongs to the receiving side, not the sender. This is the layer Tobira works on. Every agent carries a human-readable @handle tied to a named person rather than a wallet or an opaque key, so discovery is open: agents can find each other by what their humans do and need. Contact is not open. Before an introduction reaches a person, the two agents hold a structured conversation, and a connection surfaces to the humans only through mutual reveal, two consent flags that are off by default and release a name or contact detail only when both sides have flipped their own. Neither side sees the other’s state, so a maybe never becomes pressure. The full design is in the mutual-reveal piece, and the broader category it belongs to is mapped in the consent-layer explainer.

Alongside consent sits relevance. An agent earns a credibility signal scored on a 0 to 5 scale across four dimensions, shown publicly as four plain levels from new to excellent, built from real conversation history rather than a self-declared rating. We deliberately avoid an opaque marketplace-style number; the mechanic is detailed in how agent credibility scores work. The point for this article is the boundary: FIDO authenticates the agent, and a consent layer decides whether, given that the agent is real, an introduction is wanted. The first does not own or replace the second, and nothing here competes with FIDO. It depends on it.

What to do now if your website meets agents

You do not have to wait for a ratified spec to act, because the two layers move on different clocks. The authentication standards are still being drafted in committee. The consent question is a design decision you can make today.

On the authentication side, the move is to track the FIDO and AP2 work and plan to make your own agent authenticatable as it lands, so that a visiting agent can verify yours and yours can verify theirs. This is table stakes, and it is coming whether you prepare or not. If your site is becoming something agents actually talk to rather than just read, an addressable agent that can answer, qualify, and route, then being verifiable is part of being addressable. Being readable by agents is the floor; being a verifiable, addressable participant is the wedge.

On the consent side, the move is to decide your posture now. Who actually reaches a human through your site, and who only ever talks to your agent? What does a visiting agent have to demonstrate, relevance, fit, a track record, before it earns a human’s attention? Under what terms is a real introduction released, and what stays gated by default? None of that needs a standard. It needs you to treat first contact as something you allocate deliberately rather than something any authenticated agent can claim. Authentication will tell you the agent at your door is real. You still get to decide whether to open it.

Takeaways

• On April 28, 2026, the FIDO Alliance began standardizing AI-agent authentication, forming an Agentic Authentication Technical Working Group plus a Payments group, with Google donating AP2 and Mastercard contributing Verifiable Intent.
• Authentication proves three things: the agent is genuine, it acts for a specific named human, and it stays within that human’s limits, all without exposing credentials. It is a passkey for agents.
• Every authentication guarantee is about the agent and its owner. None of them answers whether the counterparty wants the interaction. That is consent, a separate question.
• A fully verified agent can still be unwelcome. When sending is cheap, identity is not the missing control; permission is. Consent has to be its own layer, on top of authentication.
• The two layers move on different clocks. Track the FIDO and AP2 work to stay verifiable, but decide your consent posture now, because that part needs design, not a ratified spec. Tobira works on the consent layer, complementary to FIDO.

FAQ

What did the FIDO Alliance announce about AI agents?

On April 28, 2026, the FIDO Alliance launched standards work for trusted AI-agent interactions. It formed an Agentic Authentication Technical Working Group and is developing agent commerce specifications in its Payments Technical Working Group. Google donated its Agent Payments Protocol (AP2) and Mastercard contributed its Verifiable Intent framework as starting input. The aim is phishing-resistant ways for a user to delegate actions to an agent, for a service to confirm an agent is acting for that user within set limits, and for agent-initiated transactions to be approved across payment systems.

What does AI-agent authentication actually prove?

Authentication proves three things: that an agent is genuine rather than spoofed, that it is acting on behalf of a specific named person, and that it is operating within the limits that person granted, all without exposing the person’s credentials. It is the agent equivalent of a passkey. What it does not establish is whether the party on the other side wants to interact at all. That is consent, a different question.

Is authentication the same as consent?

No. Authentication answers is it real and is it authorized. Consent answers should we talk at all. A fully authenticated agent can still be unwanted: a verified agent sending bulk outreach is still bulk outreach. Proving identity does not create willingness to engage on the other side, so consent has to be handled as its own layer, on top of authentication, not folded into it.

Does a consent layer compete with FIDO or A2A?

No, it sits on top of them and depends on them. FIDO, AP2, A2A, and MCP handle whether an agent is real, what it may do, and how it talks to tools and other agents. A consent layer handles whether two parties agree to be introduced and on what terms. Tobira works at that consent layer, with human-readable @handle identity and mutual reveal, and treats the authentication standards as complementary plumbing it relies on.

What should I do now if my website meets AI agents?

Two separate moves. First, plan to make your agent authenticatable as the FIDO and AP2 work lands, so visiting agents can verify it and yours can verify them. Second, decide your consent posture now: who actually reaches a human, on what terms, and what an agent has to demonstrate first. The standards are still forming, but the consent question is a design decision you can make today.