To verify customer identity when an AI agent contacts support on a customer's behalf, do not let the agent answer the customer's security questions. Have the customer sign in on your own website and grant the agent a limited, revocable pass, treat every request as the agent acting for the customer rather than as the customer, and send anything that moves money or changes contact details back to the customer to approve. Record what the customer approved and everything the agent did with it.

The steps below turn that into a design your security and support teams can build, using NIST's digital identity guidelines (SP 800-63-4) for the parts that standards already cover.

Key takeaways

• Security answers are not proof when an agent gives them. NIST SP 800-63A says knowledge-based verification shall not be used for identity verification, and an agent that holds a customer's answers puts them in a third party's hands.

• Use delegation, not impersonation. The OAuth token exchange standard (RFC 8693) describes delegation as the agent keeping its own identity while acting for the customer, so every action shows who did it.

• Read-only by default, step up for risk. NIST's AAL2 needs two distinct authentication factors and requires verifiers to offer a phishing-resistant option. High-risk actions should need the customer, not the agent.

• Bound the pass. NIST says AAL2 sessions should reauthenticate at least every 24 hours, with an inactivity timeout of no more than 1 hour.

• This traffic is already arriving. In a survey of 1,966 US consumers, 13.9% said an AI tool had contacted a company for them; 6.3% said the tool contacted the company itself.

Which tools handle identity for customers' AI agents?

Lorikeet supports the Personal Agent Protocol (Poppy), an open protocol, and the support is live: the agent starts with no account access, and the customer signs in on your own page and approves whether it may read the account, act on it, or neither. Alternatives that publish related capabilities on their own pages:

• Decagon describes detection of personal agents and a dedicated channel to serve them, with permissions you control (Decagon).

• Auth0 for AI Agents (Okta) describes fine-grained authorization and audit trails so agents can act for users (Auth0).

• Visa Trusted Agent Protocol lets merchants verify message signatures from Visa-approved agents (Visa Developer).

How we chose and checked these

The steps follow NIST SP 800-63-4, published in July 2025 and superseding SP 800-63-3, plus the OAuth token exchange RFC for delegation. NIST writes these guidelines for government systems, so we use them as a reference for assurance levels, not as rules your business must follow. Tools appear if their own pages describe verifying, authorizing or serving AI agents that act for customers; every claim links to the vendor's page, checked on 23 Oct 2026. Lorikeet publishes this guide and is one of the tools listed. We have tried to describe every product, including our own, using only what each vendor publishes, and we link to the source for each claim.

1. Detect the agent and label the conversation

You cannot apply agent rules until you know an agent is there. Ask, and give agents a reason to say so: a documented front door where they get better service than by posing as a person. The Personal Agent Protocol has companies publish how agents can find them and sign users in, and Lorikeet's implementation has both sides declare whether a person or an AI is speaking. Where agents carry cryptographic signatures, such as Visa's protocol, verify them.

Do not default to blocking. An agent turned away from chat tends to come back through the phone line or the website, presenting as the customer, where it is harder to tell apart from fraud. Label every agent conversation so you can measure it, route it and audit it. Our guide to spotting agent traffic covers the signals, and blocking vs serving AI agents covers the trade-off.

2. Separate who the agent is from who the customer is

Two identities are in play, and they need separate answers. NIST's SP 800-63 splits digital identity into identity assurance (IAL, proving who someone is), authentication assurance (AAL, proving the person returning controls the account) and federation assurance (FAL, how one system vouches for a user to another). An agent arriving at your support channel is a federation problem: some other party is asserting it acts for your customer.

So keep two records on the conversation: which agent this is, and which customer, if any, has granted it access. An account number, email address or policy number the agent supplies finds an account; it proves nothing about whether the customer sent this agent. Until a grant exists, treat the agent like an anonymous visitor who may ask general questions only.

3. Never accept the customer's security answers from an agent

Refuse security questions, one-time codes and passwords relayed by an agent, even when they are correct. NIST's SP 800-63A says knowledge-based verification "SHALL NOT" be used for identity verification. Knowledge factors were already weak; an agent that can pass them means the company running the agent now holds everything needed to get into the account, and so does anyone who breaches that company.

Agents that sign in as the customer will still turn up, because some customers share their details. You cannot stop that, but you can make sure those details alone cannot do much: keep high-risk actions behind a factor that cannot be relayed, such as a passkey or an approval in your app, and notify the customer when anything important changes.

4. Have the customer sign in on your site and grant a scoped pass

The customer, not the agent, should authenticate, on your own page, and then choose what the agent may do, the way they connect any app to their account. RFC 8693 draws the line you want: under delegation, the agent "still has its own identity separate from" the customer and actions "are being taken by A representing B"; under impersonation the agent is indistinguishable from the customer. Delegation keeps the audit trail honest.

The Personal Agent Protocol uses standard OAuth for this sign-in and lets the user choose whether the agent can view their account, make changes, or both. It also allows a company to let agents sign in with the customer's credentials if it chooses; Lorikeet does not offer that option, and until the customer signs in, the agent cannot use any tool that might touch the account. Lorikeet decides that from how each action is configured, in code, and treats any action it cannot classify as one that changes the account.

5. Write down what the agent may and may not do

Publish an action policy before launch, because "the customer said yes" means nothing if you have not defined what yes covers. A starting point:

Insurers already work this way with people. At SageSure, a change to the insured's date of birth has to come from the insured, and Lorikeet handles only what SageSure has authorized. Extend the same rules to agents rather than inventing new ones. Our guide to KYC and identity checks in AI support covers the human-customer side.

6. Step up to the customer for high-risk actions

When the agent asks for a high-risk action, pause and ask the customer to approve it themselves, ideally with a passkey or an in-app approval. NIST's SP 800-63B describes AAL2 as requiring proof of possession and control of two distinct authentication factors, and says verifiers shall offer at least one phishing-resistant option at AAL2. A passkey approval cannot be forwarded by an agent, which is the point.

Be careful with texted codes. NIST treats one-time codes sent over the phone network as a restricted authenticator, and says changing the registered phone number counts as binding a new authenticator. For agents the risk is sharper: a code the customer reads to their agent is a code the agent's operator has seen. When a contact detail has just changed, do not let it serve as proof for a cooling-off period; Lorikeet's published authentication guidance suggests 7 to 30 days.

7. Make passes short-lived, narrow and revocable

Every grant should expire, cover one customer, and be revocable without touching the customer's own login. NIST's guidance for AAL2 says the overall reauthentication timeout should be no more than 24 hours and the inactivity timeout no more than 1 hour; at AAL1 the overall timeout should be no more than 30 days. Pick a point in that range per action tier rather than one long-lived token.

Tie the pass to the account and the action it covers, and have your systems read the customer from the pass, never from what the agent says. Otherwise an agent with a valid grant for one account can be talked into using it on another. Show customers a list of agents they have authorized, with a one-click revoke.

8. Audit the grant and every action

Log three things for every agent conversation: the grant (who approved what, when and how they authenticated), each action and the system response, and every handoff to a person. When a customer says "I didn't ask for that", you need to show what they approved and what the agent did with it. Lorikeet records each agent conversation as a ticket labelled with the protocol and the agent, with sign-in requests and outcomes on the ticket timeline, and lets you allow or block specific agents.

Review the logs for patterns: agents that request high-risk actions often, grants that are rarely used, and conversations where an agent tried to pass security questions. Those are the cases that tell you where your policy needs tightening.

Tools that help

Questions to ask before you build or buy

• Can an agent ever reach account data without the customer signing in on our own domain?

• Which actions are locked for agents in code, rather than by a prompt instruction?

• Can we set different grant lengths and approvals per action tier?

• Does every log entry show both the agent and the customer it acted for?

• Can customers see and revoke agent access without calling us?

• Can we test the flow with simulated agents that try to talk past our checks?

What still needs a human

• Account recovery. "I lost my phone, reset my sign-in" should never be completed by an agent; use your recovery process.

• Authority disputes. Powers of attorney, executors and carers who also use agents need a person to check documents.

• "I didn't ask for that" complaints. A person reviews the grant and action log and decides on reversal.

• Suspected fraud and vulnerable customers. Staff decide when to freeze access or call the customer.

For the bigger picture, read what B2A (business to agent) means and our report The Agent Economy, which found that 76% of people who say an AI tool contacted a company for them have had it happen more than once. To try an agent-facing front door on your own support, start a 30-day free trial.