Dear OpenAI, My Agent Needs Its Own Wallet
AI agents use human-in-the-loop to hide a big problem: our digital identity infra isn't ready for agents. Agent providers will likely bear liability, so they should lead in creating agent wallets.
OpenAI’s Operator, an agent that can perform tasks on the web browser for you, is shaking up the AI agent landscape, making people wonder what this could mean for other agent developers and for how consumers navigate and transact on the internet. For a fintech nerd like me, the announcement underscored the need for critical identity and payment infrastructure.
Operator leaves high friction points to consumers. Operator relies on web-based browsing (see my article for the tradeoffs of web-based vs. API based browsing), conducting a search for the consumer and then throwing the ball back so the user can log in, check out, and solve CAPTCHA. It also will decline sensitive tasks such as banking transactions or those requiring high-stakes decisions.
There are many reasons for OpenAI to build a “takeover mode” (i.e., giving the user back the control of the browser during high-friction/high-risk steps). Practically, some argue that this is the best way to perform reinforcement learning, having a user monitor and train an agent’s behavior as it navigates the internet. Others argue that some consumer friction is good to build trust around delegation. It’s like training a new intern: have them send you a few draft emails before you get comfortable letting them send them off on their own.
The more discrete reason: our identity infrastructure is a mess, and has not been able to keep pace with the rapid development of AI agents. AI agent developers are relying on cumbersome “human-in-the-loop” authentication or outdated tactics like cookie copying and screen scraping. This isn’t for lack of trying. Many of them are piecemealing an identity solution based on what’s available in the market. Established network providers like Visa and Mastercard are lagging in developing robust "Know Your Agent" (KYA) procedures and still do not issue agent credentials, based on recent interviews with insiders.
We need strong integrations between AI agents and our existing identity infrastructure for the full potential of AI agents to actualize. Just as advanced fraud prevention helped establish trust between buyers and sellers in the early days at PayPal, so too will a robust identity infrastructure build trust with AI agents.
AI agents are a new intermediary. They sit between consumers and the organizations they want to engage with, forging relationships built on trust. For consumers, agents must provide reliability and convenience. For organizations, they must add value without increasing risk—offering new revenue streams, boosting engagement, and nurturing loyalty.
Today, AI agents are asking to borrow your wallet. Most AI agent developers are relying on a full authentication model—where the agent uses the user’s own credentials. Operator has a text box where you can save your details to populate your checkout (the equivalent of having a book of passwords on your desk). Beyond the obvious privacy concerns, regulators discourage this model because it muddies the question of who is liable for contested behavior. For instance, if the agent misuses data or performs unintended actions, it may be unclear who should be held responsible—the user, the agent provider, or the third party with whom the agent transacted.
In reality, AI agent providers will likely bear the liability. While AI regulation is still being written, we can look at examples of how liability has been handled with other autonomous actors:
In algorithmic trading, a glitch in Knight Capital’s software bought $7 billion in stocks within an hour. Knight Capital was not permitted to reverse most of those trades, given regulatory restrictions on trade reversals following the 2010 Flash Crash, resulting in a $440 million loss. Liability for most electronic trades, including those executed autonomously, falls directly to the organization operating the autonomous system.
In autonomous vehicles, if a hardware defect or software bug causes an accident, the manufacturer generally bears the blame. If possible, manufacturers will pass liability along to component suppliers. Vehicle owners may also be liable if they fail to maintain the vehicle, skip software updates, or override self-driving features.
In electronic payments, liability predominantly flows toward the party using outdated authentication methods. For in-person (card-present) transactions, the least secure participant (e.g., the party not using EMV chip technology) is held responsible for the loss. For online (card-not-present) transactions, merchants and their acquirers, who are responsible for preventing fraud on their platforms, typically shoulder the burden. However, if fraud rates soar, merchants can be kicked off the network.
In these cases, liability will fall on the technology provider/developer. It is particularly true if the AI agent providers are consumer facing. Taken together, these precedents suggest that AI agent providers will likely face liability, particularly if they target consumers.
Liability will incentivize agent providers to provide agent identifiers, to build trust and to create an audit trail for when things go wrong. This means that AI agent providers are likely to issue agents their own credentials, enabling them to act as a distinct, identifiable entity. This would be comparable to having an authorized user on your credit card. In this case, the actions of the AI agent would be clearly attributable. While the AI agent provider would likely be legally responsible for the agent’s actions, clear delineation of identity makes it simple to assign fault.
Meanwhile, organizations are motivated to either ban or formally recognize AI agent. Organizations must decide how to respond once they know AI agents are on their platforms and engaging on behalf of consumers. Providers like Uber and Instacart are partnering directly with OpenAI and accepting AI agent browsing of their websites. Others may ignore the shift, treating AI-driven requests as if they were human. Others might ban agents altogether, implementing tests to ensure a person is behind the action. The savviest might choose to formally recognize AI agents, giving them unique credentials and thus better security and clear accountability.
Some companies may pretend nothing has changed. As long as the login credentials check out, they won’t question whether a human or AI is behind the screen. While most organizations do this today, this approach likely won’t last forever. Merchants are typically liable for unauthorized transactions. If an AI agent makes an unauthorized transaction using a consumer’s credentials, a card issuer could argue that the merchant did not have sufficient authentication measures.
Other organizations may try to block AI agents entirely, imposing strict liveness testing to ensure human interaction. Violations would breach user agreements and shift liability back onto consumers and AI agent providers.
Forward-thinking organizations may embrace AI agents, providing AI agents with distinct authentication pathways. This approach recognizes the growing reality of AI intermediaries and seeks to capitalize on their potential benefits while mitigating some of the liability they would otherwise experience if blissfully ignorant.
The approach chosen will likely vary based on the risk profile of the industry. A retailer might tolerate unidentified agents browsing, while a streaming service or government agency might not. Ultimately, if AI agents come with trustworthy, independent identities, organizations have an incentive to welcome them. Verified agents can become legitimate, manageable players in digital ecosystems.
What AI Agent Providers Need to Succeed
AI agent developers (particularly consumer facing ones) need their own suite of identity solutions to safely and securely onboard consumers and verify, authenticate and authorize agents. Specifically, developers will need:
Robust User Onboarding: When onboarding new users, AI agent providers must verify and authenticate human identities to reduce risk, ensure compliance, and limit liability. For this, a strong, secure onboarding process is key. To conceptualize the risk, consider ElevenLabs, a voice-generation service that initially required no ID or payment. A Vox reporter exploited this service to gain access to Lloyds Bank accounts, and 4chan members used it to create offensive celebrity impersonations. Because of potential liability, ElevenLabs quickly introduced strong ID verification and authentication measures.
Strong links between human and AI agent identifiers: Developers need a robust way to connect an AI agent’s identity with a human’s. Today, providers like Anon are enabling onboarding to AI agents using only Google’s single sign on. While single-sign on is convenient for consumers and provides some authentication, it is not sufficient for all industries. It also doesn’t solve the friction at the checkout page.
Precisely defined credentials: Today we’re comfortable oversharing: we give our driver’s license, including our full name, date of birth, and address, every time we verify we’re over 21 at the bar. However, because agents are stochastic, over-provisioned access significantly increases the potential damage of unwanted behavior. With that same information, an AI agent can open a Venmo account, apply to lease an apartment, or create a new cell phone plan.
Dynamic credentialing: Developers of consumer AI agents will likely be managing a fleet of agents to support various use cases for consumers. This creates a many-to-many mapping between consumers and agents, where agents need to be dynamically provisioned with the specific individual’s credentials necessary to complete the task. Solving for dynamic credentialing will make auditing, compliance and remediation simpler.
Narrowly defined scope and permissioning: Narrowly defining an AI agent’s access only works as well as the platform’s ability to enforce it. Developers try to restrict what an agent can do through prompting, but this is risky if the underlying system doesn’t technically limit those actions. For example, if an agent is only meant to read one text file yet the platform lacks file-level permissions, the agent could still open other files—even if we explicitly told it not to. If the platform does not support fine-grained access controls, then the agent by default will have more capabilities than it needs to complete its task. MIT researchers even suggest multi-point enforcement: you should not only explicitly limit the scope of an AI agent, but also communicate these limitations to the service the agent is interacting with.