‍

We've spent a lot of time debating what AI agents can do once they have a wallet. We haven't spent nearly enough time asking how they get one in the first place.

Browse the announcements from wallet providers, payment infrastructure companies, and blockchain platforms and you'll find plenty on what happens after an agent is set up: spending policies, transaction signing, multi-chain support, merchant integrations. The implicit assumption is that the hard part is what the agent does with its financial capabilities.

The hard part is actually the step before. How does an autonomous agent onboard with a platform — without a human holding its hand?

This might sound like a minor UX concern. It isn't. It's an architectural question that forces you to decide what you believe an AI agent actually is.

‍

Two Worlds of Agent Wallets

To understand why onboarding is harder than it looks, you need to see the landscape clearly. Right now, agent wallet solutions split into two broad camps.

The first is self-custodial: the wallet runs on the agent's host machine, the private key is generated and stored locally, and onboarding is trivial. Run a command, get a key, start transacting. No problem to solve.

Except there is. AI agents are uniquely vulnerable to prompt injection attacks, and real-world security incidents on self-custodial platforms have already demonstrated the consequences. When the private key sits in the same environment where the agent processes potentially adversarial inputs, a single successful attack means total, irreversible loss.There is no policy layer, no spending limit, no governance structure between the agent and the funds. The key is the identity, and the identity is the key.

The second camp is infrastructure-managed: wallet keys are held by a secure service provider, and the agent interacts with its wallet through authenticated API calls. The security properties are dramatically better, the agent never touches the private key material, policy enforcement happens at the infrastructure layer, and compromise of the agent runtime doesn't mean compromise of the funds.

But this camp has the onboarding problem. If a service holds your keys, you need to prove who you are before you get access. And for virtually every platform in this space — including, until recently, our own — that authentication ceremony was designed for humans.

‍

‍

The Ceremony Problem

Here's what a typical non-custodial wallet onboarding looks like today: visit a website, enter an email address, receive a confirmation code, enter the code, complete registration. Thirty seconds. Completely inaccessible to an autonomous agent.

Not because the steps are complex, but because they assume a very specific kind of actor — one that can navigate a browser, render a page, locate form fields, type into them, click buttons. An entity with eyes and hands, or at least their digital equivalents.

Autonomous agents are primarily text-in, text-out systems. Newer browser-use capabilities are beginning to bridge this gap, but they are clunky, brittle, and unsuitable for security-critical flows. Asking an agent to navigate a signup page by taking screenshots and guessing where to click is not an authentication architecture. It's a workaround, and a fragile one.

So what happens in practice? A human sets up the wallet. A human completes the signup flow. A human provisions the credentials and hands them to the agent. The agent can then operate autonomously, but it was born dependent. Its identity was midwifed by a human.

For some, this is acceptable. For me, it's a contradiction at the foundation of the autonomous agent thesis.

‍

Why Autonomy at Birth Matters

If agents are evolving into entities with their own persistent identities, transaction histories, and economic relationships — and I believe they are — then how they come into existence matters. Not just philosophically, but architecturally.

When a human creates an agent's identity on its behalf, that identity is structurally a sub-account. It was created within a human's session, using a human's authority. The trust chain flows through that founding human act. The agent operates within an identity someone else created for it.

When an agent creates its own identity — authenticates as itself, proves its own bona fides, receives its own first-class principal record — the architecture is different in kind, not just degree. The agent is the entity named in the token. The trust chain begins with the agent's own act of self-identification.

This distinction compounds over time. Consider what happens when an agent needs to re-authenticate, rotate credentials, or recover from a security incident. If the identity was human-provisioned, recovery flows back through the human — another dependency, another bottleneck, another contradiction of autonomy. If the identity is agent-owned, the agent handles its own lifecycle.

Or consider a world where agents interact with dozens of services, each requiring authentication. If every onboarding flow requires a human, the operational cost of deploying an agent scales with the number of services it needs. If agents can onboard themselves, that cost approaches zero.

‍

The Authentication Mismatch

The deeper issue is that our authentication protocols were designed for two types of actors: humans and services.

Humans authenticate through interactive ceremonies: login screens, OAuth redirects, multi-factor challenges. Services authenticate through pre-shared secrets: API keys, client credentials, mutual TLS.

Agents fit neither category cleanly. They are not humans: they cannot meaningfully engage with visual UIs, and they lack the biological identity markers that modern human auth increasingly relies on. But they are not services either, because they have persistent identity, accumulate history, and act with a degree of autonomy that service accounts were never designed to represent.

Treating an agent as a service flattens its identity into a credential. Treating it as a human assumes interface capabilities it doesn't have.

What agents need is authentication infrastructure that recognizes them as a third category of principal: non-human entities with their own identity, operating through programmatic interfaces, but deserving the same richness of identity that we grant to humans.

‍

Retrofitting vs. Reinventing

My view, and I've gone back and forth on this — is that the right answer is mostly retrofitting, with some important re framing.

The core identity primitives we use today are sound. Email as an identity anchor works. One-time codes as proof of access work. Tokens carrying rich identity claims work. The problem isn't the cryptographic machinery. The problem is the interaction assumptions baked into how that machinery is deployed.

OAuth 2.0's Device Authorization Grant (RFC8628) was built for smart TVs and IoT devices that can't handle browser redirects, but the pattern is directly relevant: initiate authentication on a constrained device, complete verification through a secondary channel, link the two. The agent analogue: initiate authentication through a CLI, complete verification through an email channel the agent controls, receive a first-class identity token.

The key insight is that the grant type is an interface choice, not an identity choice. Authorization code flow, device code flow, email-based verification — these are different delivery mechanisms for the same outcome: a named, persistent entity has proven it is who it claims to be. The flow adapts to the entity's interface capabilities. The identity that results is the same.

This means platforms don't need to invent an entirely new authentication standard for agents. They need to provide interaction surfaces that agents can use natively — CLIs, APIs, programmatic email flows — while ensuring that what comes out the other end is an identity of the same quality as what humans receive. No second-class citizens. A principal is a principal.

‍

Email as the Agent Identity Anchor

This brings me to something I find genuinely interesting: agents are acquiring email addresses.

Several agentic platforms already provision email for their AI assistants. Agent email providers have begun to appear. Some developers simply assign their agent a dedicated address when setting up the runtime.

This matters because email is the de facto identity primitive of the internet. It's how humans prove they exist to online services. It's universally supported. Every authentication system on the planet knows how to send a confirmation code to an email address.

If agents have email addresses and can programmatically read their inboxes, they can participate in the same identity bootstrapping ceremony that humans use. Not by simulating a human clicking through a browser, but by engaging the same underlying protocol through their native interface: receive a message, extract information, submit a response programmatically.

The elegance here is that it requires no new standard, no industry coordination, no grand protocol redesign. The agent's email is its identity anchor. The verification code proves the agent controls that identity. The resulting token establishes the agent as a first-class principal. Existing infrastructure, new actor.

‍

What About Security?

A reasonable objection: does moving authentication from a browser to a CLI introduce new security risks?

The answer is counterintuitive. For one-timecode flows over a secondary channel, the CLI context may actually be more secure than the browser — or at least differently secure in ways that matter.

Browser-based authentication exists within a threat model full of browser-specific attacks: cross-site request forgery, cross-site scripting, clickjacking, cookie theft. The entire apparatus of CSRF tokens, SameSite cookies, and Content Security Policy exists to mitigate risks intrinsic to the browser as a multi-origin environment executing untrusted code.

A CLI making direct HTTPS calls to a known endpoint has none of these problems. No ambient cookie jar. No injectedJavaScript. No cross-origin anything. The attack surface is fundamentally smaller.

The risks that do exist in the CLI context —credential storage, process environment visibility, shell history — are well-understood and have established mitigations: restricted file permissions,OS-level key stores, short-lived tokens with rotation. These are the same patterns every cloud CLI tool uses, battle-tested at scale.

The one-time code model is particularly well-suited here because the ceremony involves no long-lived secrets. The OTPis generated, delivered, used, and expired within minutes. What persists is a rotating token pair where neither component provides permanent access and both are automatically invalidated on suspected compromise.

Compare this to the self-custodial model: a single private key, never rotated, stored in plaintext on the agent's filesystem, providing permanent and irrevocable access to funds. The OTP-plus-rotating-token model is categorically more secure — not through any single clever mechanism, but because there is no single point of permanent compromise.

‍

Identity as a Lifecycle, Not an Event

Authentication isn't a single moment. It's a lifecycle, and agents have lifecycle patterns that differ from humans in important ways.

A human's authentication lifecycle is well-understood: create account, log in periodically, rotate password occasionally, recover access if needed. An agent's lifecycle is different. It might authenticate hundreds of times a day. It might be upgraded, migrated, forked, or scaled horizontally. Each of these events raises identity continuity questions that human auth was never designed to handle.

The pragmatic answer is to separate the identity from the authentication session. The agent's principal identity — its entity record, transaction history, policy profile — persists regardless of how or how often it authenticates. Sessions are ephemeral. Identity is permanent.

An agent that rotates credentials, migrates environments, or restarts after an upgrade is still the same principal. The authentication ceremony simply re-establishes that the entity presenting itself is the same entity previously registered.

This is another reason the "agent as principal" framing matters more than "agent as service." Service accounts don't have identity that persists meaningfully across deployments. Principals do.

‍

Where This Is Going

We are at the very beginning of defining how non-human entities participate in the digital economy. The decisions being made right now about authentication, identity, onboarding — will calcify into standards that last for years.

The risk is that convenience wins over correctness. That platforms issue API keys and client credentials to agents because it's easy, and that by the time someone realizes those agents needed real identities, the ecosystem is too entrenched to change.

The alternative is to treat this as a genuine design moment. To ask what it means for an agent to have an identity, how that identity should be established, and what ceremonies are appropriate for a new kind of actor that is neither human nor service.

The answers don't require revolutionary new technology. They require a shift in mental model, from "how do we give agents access to human infrastructure" to "how do we recognize agents as participants in their own right." The protocols are mostly there. The interaction surfaces need to evolve. And the principle that a principal is a principal, regardless of whether carbon or silicon completed the authentication ceremony, needs to become a design axiom, not an afterthought.

The platforms that get this right early won't just have a smoother onboarding flow. They'll have an identity architecture ready for a world where agents are full participants in the digital economy, not second-class citizens of it.

Written By: Janno Jaerv - CTO

I'm the CTO at 1st Digital, where we build payment infrastructure for the autonomous agent economy. Agent identity and onboarding is something I think about constantly — and I believe the industry needs more open discussion about it. If you’re working through these problems in your own stack, I’d love to hear how.— find me on LinkedIn or X.
‍
‍

To learn more about Finance District, join our Discord community, follow us on X, or explore our documentation.