For decades, e-commerce identity and access management has rested on what, in retrospect, was a simple model. A customer signs in, the merchant confirms who they are and what they are allowed to do, and the transaction proceeds. Business purchases added a third party: the employer paying for travel, software, or supplies bought on its behalf. Merchants learned to handle this through corporate accounts, corporate credit cards, and negotiated contract terms. Personal AI agents now add a fourth party to these relationships. The agent acts on the customer's account with delegated authority, sometimes in the context of a business transaction and sometimes in a purely personal one.
What the Fourth Party Changes
The question is no longer only whether the customer is who they claim to be and what they are authorized to do. Merchants must now also answer what the customer delegated to the agent, who can prove it, and how. Customer identity and access management (CIAM) systems, fraud reduction intelligence platforms (FRIP), and the other systems around them were built to authenticate people, manage their consent and entitlements, and block fraud. Most do not yet model delegations that run through agent software acting on someone's behalf.
One Customer, Two Hats
The difficulty is that a single personal agent can act for the same person in two very different capacities: as an end consumer and as an employee. The merchant often cannot tell from the request which scenario is in play, who is paying, what rules apply, or who is ultimately accountable. A travel booking could be a family holiday or a client visit governed by a corporate travel policy. A software subscription could be for personal use or for company business. A restaurant reservation could be for a birthday or a client dinner. A ride to the airport could be the start of a vacation or of a client trip. The list goes on.
When the merchant or the agent guesses wrong, disputes over reimbursements, refunds, and policy violations will tend to surface long after the transaction, when the context that would have resolved them is gone.
Why the Merchant Cannot Sort It Out Alone
Merchants differ in what they can see. Some have direct contractual relationships with employers and can evaluate a transaction against the scope of that contract. Many others see only the individual and have no view of which business, if any, stands behind the purchase.
Either way, the merchant cannot depend on direct access to the agent platform. What it does have, by definition, is direct interaction with the personal agent. That makes the agent the primary channel for the signals the merchant needs. The merchant therefore needs reliable ways to authenticate the agent and verify what it is authorized to do, including the role in which the person is acting.
Emerging initiatives such as the IETF's Web Bot Auth draft and the Personal Agent Protocol (PAP), in development by Meta and Sierra, are an important start. Web Bot Auth verifies which agent is sending a request, though not what it may do, and neither initiative yet conveys that role. Visa's Trusted Agent Protocol (TAP), Mastercard Agent Pay, and American Express's Agentic Commerce Experiences (ACE) kit add payment-network signals about the agent and the purchase it intends to make, but they too stop short of the person's role.
Data Moves in Both Directions
The risk is not confined to financial transactions. Corporate purchasing data and policies can flow into consumer agent platforms through personal agents the business never approved, a form of shadow AI. This can be as simple as a user uploading a travel policy or supplier list to make their personal agent follow company rules. In the other direction, personal data can leak into corporate expense and procurement records.
What Merchants and Employers Should Decide Now
Merchants and e-commerce sites first need to decide whether they will do business with personal agents at all. Either choice carries business risk. Those that do should require agents to declare the role in which they are acting, for now by asking for it during checkout. They should also confirm costly or risky transactions directly with the person rather than relying on the agent's assertion alone. Standards groups and payment networks should add a role field to their agent protocols so this declaration can move out of the checkout page and into the request itself. Employers, for their part, should decide whether personal agents may carry out transactions that affect the business, and if so, under what policy and with what evidence.
Closing Thoughts
Agentic commerce turns a customer login into a four-party question of delegation and role. Identity teams that treat the agent as just another session will be left reconstructing intent after the fact, usually in the middle of a dispute. The CIAM Impact Day in Frankfurt on 18 November will explore these questions in depth.
