How Agents Receive 2FA Codes With a Phone Number

A browser agent that can fill login forms still stops at the SMS gate. Banks, airlines, and legacy SaaS portals text a one-time code to a phone number — and if every customer shares one inbox, Customer A's OTP lands where Customer B's agent can read it. Naïve is the autonomous company infrastructure that gives agents real-world capabilities, and /phone is the primitive that gives each tenant agent its own US number for inbound SMS, including 2FA codes, scoped and readable through the governed API. Part of the autonomous company use-case cluster.

This guide shows how to provision per-tenant phone numbers for agents that operate vendor portals: inbound works immediately, messages stay isolated per user, and agents read codes with explicit receive_sms permissions. Pair with /browser for the full no-API login loop.

This tutorial connects to the Multi-Tenant Playbook, no-API operator, and Introducing /phone.

Why 2FA breaks multi-tenant agents

The failure mode is identity collapse: one number serves every customer, so verification codes are not scoped to the tenant user the agent represents. /phone fixes this by binding each number to one user and surfacing inbound SMS only to that user's workspace.

Architecture

Four pieces work together:

• Users — one tenant user per customer.
• Formation — LLC + EIN for carrier (10DLC) brand registration.
• Phone — provision a US number; inbound SMS immediate.
• Browser — optional, for portal login automation.

Setup

npm install @usenaive-sdk/server

import { Naive } from "@usenaive-sdk/server";
 
const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });

Step 1 — Form the business (one-time prerequisite)

Phone provisioning requires a completed LLC and EIN for carrier brand registration:

naive verification start
naive formation submit

See formation docs for the full chain.

Step 2 — Create a tenant user and provision a number

const customer = await naive.users.create({
  external_id: "acme-portal-001",
  email: "ops@acme.com",
});
 
const client = naive.forUser(customer.id);
 
const { phone, campaign } = await client.phone.provision({
  ein: "12-3456789",
  area_code: "415",
  label: "Acme — vendor 2FA",
});
// phone.e164 is live for inbound SMS immediately

Each customer gets their own number. Inbound OTPs are stored against that number only.

Step 3 — Assign an agent with receive_sms permission

naive phone assign <phone-id> --agent-id <agent-uuid>

An agent without receive_sms is refused when it tries to read the inbox.

Step 4 — Poll for the OTP during login

When the browser agent submits credentials and the portal sends a code:

const messages = await client.phone.messages({ phoneId: phone.id, limit: 5 });
const latest = messages.items[0];
// Parse the OTP from latest.body and submit in the browser session

Subscribe to the sms.received webhook event for real-time flows instead of polling.

Step 5 — Release or revoke on offboarding

When the customer churns, release the number or revoke the agent session. A released number stops receiving new SMS permanently.

What this enables for portal operators

• Vendor portals without APIs — complete SMS-gated login loops.
• Per-customer isolation — OTPs never cross tenants.
• Audit trail — inbound messages are stored and queryable per number.
• Composes with /browser — the agent fills the form, reads the code, finishes login.

The agent still does the browser work. /phone is what makes the 2FA step real and scoped.

Related reading

• Introducing /phone — primitive overview
• No-API operator — browser + comms stack
• Introducing /browser — governed browser sessions
• Phone documentation — API reference