What is the safest pattern?
A strong implementation separates the agent identity, human authentication, delegated authority, action proof, and service-side enforcement. This lets a downstream service tell that an agent acted for a person without mistaking the agent for that person. OpenID Foundation’s on-behalf-of guidance
- Give the software agent a managed identity with its own credential lifecycle.
- Verify the user on a trusted relying-party surface.
- Describe the delegated action, target, limits, purpose, duration, and downstream delegation rules.
- Issue signed, short-lived authority and verify it at the action boundary.
How do you bind the human to the agent?
- 01
Register both identities
Keep the agent identity separate from the user account. Define the owning organization, credential rotation, and revocation path.
- 02
Present a clear approval request
Show the person what the agent wants to do, including the action, target, amount or data boundary, duration, and whether tools or sub-agents may be involved.
- 03
Authenticate the human on a trusted surface
Trigger WebAuthn or another appropriate ceremony controlled by the relying party. The agent can initiate the request, but it does not receive the passkey private key, biometric, or PIN.
- 04
Create scoped, signed authority
Bind the human identifier, agent identifier, permitted action, purpose, audience, limits, issue time, expiry, request identifier, and revocation conditions.
- 05
Verify immediately before execution
The receiving service validates agent credential, human delegation, signature, audience, scope, expiry, proof-of-possession, and current policy.
- 06
Preserve an audit trail
Record the human, agent, approval context, executed action, policy decision, and outcome so accountability survives after the session ends.
When should the user be asked again?
Human-in-the-loop does not mean prompting on every click. It means defining where human authority is required and making the resulting approval specific, verifiable, and enforceable. NIST’s human-binding and least-privilege questions
| Recommended control | |
|---|---|
| Low-risk action inside a narrow active scope | Allow with the existing delegated authority after normal policy checks. |
| New merchant, tool, or data destination | Re-evaluate policy and often request approval. |
| Amount or privilege exceeds the approved limit | Require step-up authentication and fresh consent. |
| Agent delegates to another agent or tool | Require explicit delegation rules and scope attenuation. |
| Credential, device, or agent risk changes | Suspend or revoke authority and re-authenticate. |
| Irreversible or regulated action | Require action-specific proof and an auditable approval event. |
What should stay outside the agent context?
Do not expose passwords, passkey private keys, biometric data, recovery codes, reusable one-time passwords, unrestricted API keys, or long-lived session cookies to the model. Keep authentication and signing inside trusted components with narrowly defined interfaces. OAuth security best current practice
Sender-constraining a token with DPoP or mTLS reduces the risk that a stolen token can be replayed by another client. It complements, rather than replaces, human authentication and action-specific authorization. RFC 9449 DPoP
How does LoginID help?
LoginID uses passkeys to verify the human before an agent executes a consequential action. That verified event can support scoped consent, digitally signed transaction authorization, and a service-side decision that connects the action to a known person without giving the agent the person’s credentials.