How does an AI agent get past phone verification and 2FA?

Most of the agents do not get past the 2FA, because in order to pass it they need their own identity: a phone number, an email address and a device that can receive codes and approve logins. Today most agents have none of these, so they stop at the verification screen. The fix is to give each agent its own legitimate resources for the accounts it is allowed to use, not to trick the check.

Why the problem exists

A language model can decide to sign up for a service. It cannot receive a text message. Verification flows assume a human with a phone, and they assume it for good reasons: they exist to keep out bots and to protect accounts.

Here is what an agent typically runs into:

• SMS codes. The service sends a six digit code to a phone number. The agent has no number, so it cannot read the code.
• Email confirmation. Easy to say, annoying in practice. The agent needs an inbox it controls, and shared inboxes tend to get flagged or mixed up between runs.
• Authenticator apps and push approvals. The second factor lives in an app on a phone. A browser agent cannot open that app.
• Number quality checks. Some services reject certain kinds of virtual numbers and only accept numbers that look like normal mobile subscriptions. Which services do this changes over time.
• Device trust. After a login, many services remember the device. A fresh environment every run means the same verification again and again.

So the usual outcome is a human in the loop who types the code in. That works for one account on one afternoon. It breaks for a workflow that runs every day.

What agents actually need

Solving this problem requires more than providing an agent with a phone number. There are several components involved in giving an agent a usable identity.

1. An account identity

The agent needs an account it is authorized to operate, along with the credentials and permissions required to access it. This could be an account created specifically for the agent or an existing account whose owner has delegated access.

2. Communication resources

Email addresses and phone numbers allow agents to receive account notifications, confirmation links and verification codes. These resources need to be accessible to the agent and managed without mixing data between unrelated accounts.

3. Authentication capabilities

Agents need a way to complete supported authentication flows, whether that involves entering an OTP, accessing an authenticator app or responding to an authorized approval request.

4. A persistent device environment

Authentication doesn't end with the first login. Services may remember devices, maintain sessions and require additional approvals later.

A persistent device allows the agent to return to an existing environment rather than starting from scratch with every execution. Session validity still depends on the individual service and its security policies.

Not every agent needs all four components. An agent working entirely through APIs may only need an API key or OAuth credentials. But when its workflow involves native mobile apps, these additional resources become important.

What you can do today

There are several ways to handle agent identity and authentication today. The right approach depends on how frequently the agent operates and which services it needs to access.

Use API keys or OAuth.

If a service supports API access or delegated authorization, use it. OAuth allows access to be scoped and revoked, while API integrations avoid unnecessary UI-based authentication. This is generally the cleanest and most reliable option.

Keep a human in the loop.

For occasional workflows, a person can receive the verification code or approve a login. It's simple and appropriate when an agent only needs access occasionally.

Use hosted email and phone number services.

Providers offer inboxes and phone numbers that can be integrated into automated workflows. However, availability, regional coverage and acceptance vary across services. You may also end up managing several providers to cover different requirements.

Use passkeys or hardware security keys.

Where supported, passkeys and hardware keys can provide stronger authentication without relying on traditional passwords and SMS codes. However, integrating these into an agent workflow requires appropriate credential management and authorization.

These approaches solve individual parts of the problem, but managing accounts, authentication resources and persistent mobile environments together remains a challenge.

The broader infrastructure requirements are explored in our article, Giving an Identity to the AI Agents.

How Matix and Mobilerun approach it

Matix is a mobile runtime for AI agents. It provides isolated, stateful real phones that agents can control through an API.

One important part of this is persistence.

Instead of starting with a blank device every time, an agent can work with a mobile environment that retains its app state and authorized sessions. It can open apps, interact with authentication screens and access supported mobile workflows.

For example, when an authorized account requires an authenticator app, the agent can interact with that app on its device, subject to the authentication flow and the service's policies.

This makes the device more than an environment for tapping through apps. It becomes part of the infrastructure an agent uses to maintain access to its accounts.

The broader agent identity stack can also involve phone numbers, email addresses, eSIMs and network connectivity. These components complement the mobile runtime by giving agents the resources needed to communicate with and access services.

Mobilerun is the open-source framework that makes mobile automation possible on top of this infrastructure. Developers can use it to describe and execute workflows on mobile devices, while Matix provides the underlying runtime.

The distinction is simple:

• Matix: The mobile infrastructure and persistent device environment.
• Mobilerun: The open-source framework agents use to interact with mobile apps.

Which identity resources are available directly through Matix, including phone numbers, email, eSIMs and regional coverage, depends on the current product offering.

A note on authentication and account access

Matix is designed for agents operating accounts and devices they are authorized to access.

It does not bypass authentication requirements or grant permission to access third-party accounts. Verification checks remain governed by the service provider's policies.

An agent should not impersonate a human, circumvent identity checks or attempt to access accounts without authorization. Some verification processes are specifically designed to require a real person, and those requirements should be respected.

When Matix is not a fit

A mobile runtime isn't necessary for every agent. In many cases, simpler solutions are better.

• The service offers API access. Use its API or OAuth integration instead of automating a login screen.
• The verification requires a real person. Government ID checks, face scans and signed documents are intended to establish human identity. An agent should not stand in for a person.
• You don't have authorization to access the account. Having a phone number or device doesn't grant permission to use an account.
• You only need occasional verification. If an agent logs in once every few months, human approval may be simpler and cheaper.
• Your workflow requires unsupported regional resources. Phone numbers and eSIM availability depend on the regions and services currently supported by the platform.

The goal isn't to automate every authentication process. It's to give agents the infrastructure to operate independently where automated access is permitted.