Passkeys verify a human or device at login, while delegated agent credentials prove what a software agent is allowed to do after login. Both reduce reliance on passwords, but only delegated credentials express transaction scope, issuer confidence and ongoing authority for autonomous purchasing workflows.
What passkeys prove, and what delegated agent credentials prove
Passkeys are an authentication step. They establish that a human user or trusted device has satisfied the sign-in ceremony, usually in a phishing-resistant way, but they do not describe what happens after login. That distinction matters in commerce because checkout, basket actions, refunds, and procurement approvals can be separated from the initial login event.
Delegated agent credentials are an authorization step. They carry the authority of a software agent acting on someone’s behalf, and they should express the scope, duration, and issuer confidence of that delegated power. That makes them closer to transaction permissions than to login proof, which is why they matter most once an autonomous workflow starts placing or changing orders.
For sign-in assurance, the relevant comparison is with passkey guidance such as NIST SP 800-63 Digital Identity Guidelines and NHIMG’s Passwordless and Passkeys Guide, which focus on proving the user or device at authentication time rather than constraining downstream agent actions.
Why commerce separates authentication from delegated authority
In a consumer or enterprise commerce flow, a passkey can confirm that the right person entered the session, but it does not by itself answer whether a software agent may buy, re-order, negotiate, or trigger a refund. Commerce systems increasingly need that second decision because an agent may operate continuously after the human is gone, and its authority often needs to vary by merchant, basket value, product category, or approval threshold.
That is why delegated agent credentials are not just another login factor. They are evidence that the agent has a bounded mandate, and the buyer or platform can later evaluate whether the agent stayed inside it. Where organizations want a formal model for this, the agent-identity and authorization materials from NHIMG’s Agentic AI Identity Guide and AI Agent Authorisation Guide are the closer conceptual fit than passkey material, because they address delegated authority rather than sign-in alone.
In practice, the strongest mental model is: passkeys answer “who or what just authenticated?”, while delegated credentials answer “what may this agent do next, on whose authority, and for how long?”. That is especially important when a commerce platform permits one identity to approve a session and another identity, the agent, to execute the transaction.
How to read scope, issuer confidence, and ongoing authority
Delegated credentials become useful only when they carry more than a yes/no permission. Scope tells the platform what the agent may do. Issuer confidence tells the platform how strongly the delegate was established and by whom. Ongoing authority tells the platform whether the permission remains valid for the current transaction, not just at the start of the session.
That makes lifecycle handling as important as initial issuance. If the agent credential is long-lived, overly broad, or hard to revoke, the platform can lose the ability to distinguish one approved purchase from many unauthorized ones. NHIMG’s Guide to NHI Rotation Challenges and Guide to the Secret Sprawl Challenge are relevant here because commerce credentials tend to fail when they are treated as static secrets instead of governed, expiring authority artifacts.
For protocol context, delegated authority is often expressed through token exchange and client authorization patterns, which is why RFC 8693: OAuth 2.0 Token Exchange is more directly aligned with delegated agent credentials than a passkey reference is. The core design question is not “did the user sign in securely?”, but “did the system issue the agent the right constrained power to act on that user’s behalf?”.
Risk and Threat Considerations
The main risk is confusing strong human authentication with safe machine delegation. A passkey can be fully legitimate while the downstream agent still has excessive, stale, or poorly scoped commerce authority. That gap creates overbuying risk, fraudulent transaction risk, and weak repudiation if the platform cannot show exactly what the agent was permitted to do.
Failure mechanism: The platform accepts the authenticated user as proof that all later agent actions are safe, then allows broad or persistent credentials to execute transactions outside the intended scope. Attackers and abusers benefit from that confusion because a valid sign-in can mask misuse of delegated commerce authority.
Impact: Unauthorized purchases, account drain, refund abuse, and broken auditability become harder to contain because the system cannot cleanly separate human authentication from agent authorization. At scale, one compromised or overprivileged delegate can create repeated financial and trust loss across many transactions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-63 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authentication and assurance at login, which passkeys implement. |
| Recommendation — Use passkeys to raise sign-in assurance without treating authentication as transaction authorization. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Commerce agents fail when delegated credentials carry excessive or standing privilege. |
| NHI-07 — Long-Lived Secrets | Long-lived commerce credentials increase misuse and revocation risk for agents. | |
| Recommendation — Constrain agent credentials to the minimum transaction scope needed for each workflow. Prefer short-lived delegated credentials and rotate or revoke them promptly. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent credentials can be misused when identity and privilege are conflated in transactions. |
| Recommendation — Separate user authentication from agent privilege checks before executing commerce actions. | ||
Practitioner Guidance
What to verify: Verify that the credential presented at login only proves authentication, while the delegated credential separately encodes transaction limits, merchant or product constraints, and expiry. If those two layers are merged, you do not have delegated authority, you have an oversized login token.
Decision rule: If the workflow can place an order, change a payment state, or approve a refund without re-checking scope, treat the delegated credential as too broad. If the action is low-risk and purely informational, keep it tied to authentication alone rather than issuing standing transaction authority.
Practitioner takeaway: In commerce, passkeys reduce password and phishing exposure at the front door, but delegated agent credentials are what prevent an authenticated session from turning into unlimited machine authority after the human has logged in.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?