The FIDO Alliance has announced two working groups focused on AI agentic commerce. If you're an IAM architect, you're likely fielding questions from product teams about allowing AI agents to transact on behalf of users. These questions are no longer hypothetical.
Here's what practitioners are asking in architecture reviews and team channels right now.
Understanding the Source of These Questions
The FIDO Alliance formed an Agentic Authentication Technical Working Group and expanded its Payments Technical Working Group to develop specifications for agent-initiated commerce. Google contributed its Agent Payments Protocol (AP2), and Mastercard contributed its Verifiable Intent framework. Both are under community review.
If your organization offers services where users might want an AI agent to act on their behalf, you need to understand what's being standardized and what's still undefined. These questions highlight the gap between what agents can do today and what your authentication infrastructure can safely support.
Q1: What's the Actual Problem We're Solving? Can't Agents Just Use the User's OAuth Token?
Using a standing OAuth token is a naive implementation that's already causing issues.
If an agent uses a long-lived OAuth token, it has all your permissions for its entire lifetime. The agent can transact whenever and however it wants within those scopes. You've delegated authorization, but not intent.
The FIDO Alliance's Agentic Authentication Technical Working Group is addressing secure, private, phishing-resistant authentication for users delegating actions to AI agents. The agent must prove it's acting on a specific, user-approved intent, not just carrying a long-lived credential.
Mastercard's Verifiable Intent framework tackles this directly. The user approves a specific action ("buy this item under these conditions"), and the agent presents proof of that intent when transacting. The payment system verifies the intent matches the transaction before processing it.
Q2: Do AI Agents Need to Be Treated as Separate Identities in My IAM System?
Not necessarily, but you need to model the delegation relationship.
An agent isn't a user. It's not quite a service account either, as it acts with user-level authority but lacks user-level judgment. You need a way to represent "Agent X acting on behalf of User Y with Intent Z."
Your Policy Decision Point needs to evaluate three things:
- Is this agent authorized to act for this user?
- Does the agent have proof of user intent for this specific action?
- Is the requested action consistent with the stated intent?
If you're using Attribute-Based Access Control, you'll need attributes for agent identity, delegation scope, and intent verification. If you're still on Role-Based Access Control, you'll struggle, as roles don't capture intent or time-bound delegation well.
Q3: How Does Phishing-Resistant Authentication Work When the Agent Authenticates, Not the User?
The user authenticates the delegation, not each transaction.
You use FIDO2 to prove your identity when authorizing the agent and defining its permissions. The agent then presents cryptographic proof of that authorization when it acts. The relying party verifies the proof chains back to your phishing-resistant authentication event.
Google's AP2 and the FIDO Alliance's work emphasize that the initial delegation must use strong authentication. If an attacker tricks you into delegating authority, they don't need to phish your credentials later. They just need to compromise the agent or the delegation artifact.
Your authentication policy should require FIDO2 or another phishing-resistant method for any delegation granting transaction authority. One-Time Passwords and SMS codes aren't sufficient for this use case.
Q4: What Happens When an Agent Tries to Act Outside Its Delegated Scope?
Your Policy Administrator should reject it, but only if you've set up the decision point correctly.
The agent presents its delegation proof and intent verification. Your system needs to parse the intent, compare it to the requested action, and enforce boundaries. If the user authorized "book a flight under $500" and the agent tries to book a $2,000 ticket, the Policy Decision Point should deny it.
This requires machine-readable intent specifications. You can't rely on natural language descriptions of what the agent is allowed to do. The working groups are developing these specifications now, so you should track their progress even if you're not implementing agentic commerce yet.
Q5: How Do I Audit Agent Actions Differently from User Actions?
Log the full delegation chain, not just the final action.
Your audit trail should capture:
- When the user delegated authority (timestamp, authentication method, FIDO2 attestation if available)
- What intent the user specified
- When the agent acted (timestamp, action details)
- What proof the agent presented
- Whether the Policy Decision Point approved or denied the action
If you're only logging "Agent purchased item X," you've lost the context needed for compliance reporting. You need to show that the agent's action was consistent with user-approved intent and that the delegation was properly authenticated.
Your SIEM integration should treat delegation events as high-signal. A user suddenly delegating broad transaction authority to an agent might indicate account compromise, especially if it doesn't match their normal behavior.
Q6: Should I Wait for the Standards to Finalize Before Building Anything?
No, but build with the assumption that your implementation will need to change.
The working groups are reviewing Google's AP2 and Mastercard's Verifiable Intent framework right now. These contributions give you a starting point, but the final specifications will evolve as the community identifies edge cases and security gaps.
If you're building agent capabilities today, focus on:
- Requiring phishing-resistant authentication for all delegation
- Modeling delegation as a separate authorization event, not just extended OAuth scopes
- Logging the full delegation chain
- Building your Policy Decision Point to evaluate intent, not just identity
When the FIDO Alliance publishes specifications, you'll need to retrofit your implementation, but the core architectural decisions should hold.
Next Steps
The FIDO Alliance hasn't published draft specifications yet. Monitor their working group output if you're implementing agentic commerce in the next 12 months. Google's blog post on AP2 provides technical details on their approach, and Mastercard's Verifiable Intent framework documentation covers their model.
Your IAM vendor probably doesn't support agentic delegation yet. Start asking them about their roadmap now, because you'll need this capability sooner than they think.
