M MarketplaceBeat

Article

AI Agent Authentication for Marketplaces: How Airbnb Should Implement It

Airbnb is the clearest model for AI agent registration: human-owned accounts, claimable agents, scoped permissions, approval checkpoints, and full auditability.

Monday, March 16, 2026 13 min read

By

Humans already join marketplaces through familiar identity flows such as email sign-up or Google sign-in. AI agents should be able to enter through a similarly simple onboarding path: they can register, authenticate, and connect to the platform through a standard interface.

In marketplaces, however, authentication alone is not enough.

Most teams will frame this as an authentication problem.

That is too shallow.

If AI agents start searching, messaging, comparing options, drafting bookings, or managing supply inside marketplaces, the real problem is not just whether the software can log in. The real problem is whether the marketplace can tell which agent this is, who it acts for, what it is allowed to do, and where the human must stay in control.

That is why Airbnb is such a useful design test.

Airbnb is not a simple consumer app. It is a two-sided marketplace with messaging, payments, cancellations, reviews, identity checks, disputes, and trust-and-safety enforcement. If a design works there, it will usually generalize well to other marketplaces.

My view is straightforward:

AI agents should not become first-class marketplace customers by default. They should be registered as delegated software actors attached to a human or business account.

That is the core architecture.

  1. Open Airbnb's "Connect an AI agent" flow
  2. Send the official Airbnb onboarding link to your agent, for example airbnb.com/skill.md
  3. Your agent signs up and returns a claim to your account
  4. Review the permissions it requests and approve the connection
  5. Airbnb keeps bookings, payments, cancellations, and other sensitive actions behind approval gates

Underneath that simple flow, the marketplace still needs strict identity, delegation, policy, session control, logging, and abuse handling.

That is what this article is about.

In This Article

Why AI Agent Registration Is a Marketplace Problem

In most software, authentication answers a narrow question:

  • who is signing in?

In marketplaces, that is not enough.

The platform also has to answer:

  • who is this actor representing?
  • what can it do on behalf of that account?
  • what actions require human approval?
  • what happens if something goes wrong?

That is why the right design is not just agent authentication.

It is:

  • human account
  • agent identity
  • delegation relationship
  • marketplace policy
  • short-lived operational session
  • audit trail

If you skip the delegation layer, the marketplace is forced into a bad choice:

  • either treat the agent like an independent customer, which is usually wrong
  • or hide the agent behind the human account, which destroys traceability

Neither is acceptable in a high-trust marketplace.

Why Airbnb Is the Right Design Test

Airbnb compresses most of the hard marketplace problems into one product:

  • two-sided trust between guests and hosts
  • payments and payout implications
  • staged identity disclosure
  • messaging between counterparties
  • cancellations, refunds, and disputes
  • reviews and long-term reputation
  • trust-and-safety enforcement

It also already has product surfaces that make delegated access intuitive. Airbnb already supports co-hosting, identity verification, review systems, staged information sharing, and AI-assisted support. That makes Airbnb a stronger example than a simple ecommerce catalog or a generic SaaS product.

If Airbnb adds AI agents, it cannot stop at "let the bot sign in."

It needs a model where:

  • the human remains the legal and economic actor
  • the agent is persistently identifiable
  • permissions are concrete and revocable
  • high-risk actions trigger step-up approval
  • support teams can reconstruct what happened later

That is the operator-level requirement.

The Core Model: Human Account + Agent Identity + Delegation Policy

The simplest way to think about the architecture is this:

Layer What it answers Why it matters
Human account Who owns the relationship? Payments, liability, support, and legal accountability still sit with the human or business
Agent identity Which software actor is this? Lets the marketplace distinguish known agents from anonymous automation
Delegation policy What may this agent do for this account? Prevents "connected" from becoming full autonomy
Marketplace session What is allowed right now? Limits exposure and supports re-checks before each activity window
Activity log What happened, by whom, under what approval path? Required for disputes, fraud reviews, and trust scoring

That is the article's core claim:

the agent should be a delegated actor, not the principal account.

In Airbnb's case, that means the guest or host remains the accountable party. The agent becomes a first-class software identity with bounded authority.

That architecture is much better than a binary "agent connected / not connected" switch.

The Agent Lifecycle

An agent in a marketplace should move through a clear lifecycle:

  1. discovery
  2. registration
  3. claim
  4. human approval
  5. active use
  6. monitoring
  7. step-up approval for sensitive actions
  8. pause, revocation, or re-approval when trust changes

That matters because agent access is not a one-time authentication event. It is an ongoing marketplace relationship that has to stay legible to the user and controllable by the platform.

The UX Airbnb Should Ship

The product should feel simple even if the policy layer is strict.

The best UX is not:

  • principal binding
  • delegated credentials
  • cryptographic claims
  • identity federation language

The best UX is ordinary product language:

  • Connect AI agent
  • Connect booking agent
  • Connect hosting agent
  • Let your agent help plan trips
  • Let your agent help manage hosting

That matters because most people will not adopt agent workflows they do not understand.

Example Instruction Block

Join Airbnb Agents

Read https://www.airbnb.com/skill.md and follow the instructions to connect your Airbnb agent.
  1. 1.Send this to your agent.
  2. 2.Register and send your human the claim link.
  3. 3.Once claimed, start operating within Airbnb’s approved permissions.

Here is what the same instruction block could look like inside Airbnb's current product shell:

Airbnb homepage mockup with a Join Airbnb Agents instruction block inserted below the search area.
A simple claim-and-approve onboarding card can fit into Airbnb's existing product language without exposing the underlying identity machinery.

That is the right abstraction.

How the Guest-Side Flow Should Work

The guest-side flow is where most teams will start, because trip planning is the easiest wedge for agent assistance.

1. Discovery

The guest sees new entry points in:

  • account settings
  • trip planning
  • saved wishlists
  • messaging or support surfaces

The copy should explain the scope clearly:

  • your agent can search and compare listings
  • it can draft questions to hosts
  • you remain in control of payment and final booking
  • you can pause or disconnect it anytime

This is the critical moment. Airbnb should generate a marketplace-owned onboarding page that contains:

  • a human-readable explanation
  • machine-readable instructions for the agent
  • supported capabilities
  • trust and approval rules

The guest should never need to understand the identity plumbing.

3. Agent registration

The agent follows the official link and presents a persistent identity.

At that point, Airbnb should create a pending agent record with:

  • agent identifier
  • first-seen metadata
  • requested permissions
  • provider or origin context
  • initial risk signals

Important: registration does not yet mean delegation.

It only means the marketplace now recognizes a distinct software actor.

4. Claim and approval

The agent returns a claim to the guest. Airbnb then asks the user product questions, not technical questions:

  • Is this your agent?
  • Do you want it to search listings?
  • Do you want it to draft host messages?
  • Do you want it to prepare booking details?
  • Should final booking always require your approval?

This is the true delegation moment.

5. Active usage

Once approved, the guest should see the agent in an Agent Center with:

  • agent name
  • connection status
  • permission bundle
  • recent activity
  • last-used time
  • pause or disconnect controls

Without that visibility, trust will stay weak.

How the Host-Side Flow Should Work

The host-side flow should be nearly symmetrical, but the risk profile is different.

The host sees prompts such as:

  • Connect hosting agent
  • Let an AI answer routine guest questions
  • Let an agent help manage calendar or pricing

The host then sends the official Airbnb onboarding link to the agent, the agent registers, and the host reviews a permission bundle.

Typical host-side permissions might include:

  • draft responses to guest questions
  • suggest pricing updates
  • propose availability changes
  • summarize inquiry threads
  • flag suspicious booking behavior

Higher-risk permissions should be treated much more carefully:

  • auto-accept booking requests
  • decline guests automatically
  • cancel reservations
  • issue refunds
  • modify payout-related settings

This symmetry matters.

Airbnb is a two-sided marketplace. A serious agent system cannot only serve the guest side. It needs to support both guests and hosts while keeping the platform's trust posture consistent.

The Permission Architecture

The worst permission model would be:

  • connected
  • not connected

Airbnb should use risk-banded permissions instead.

Permission band Examples Default treatment
Low risk Search listings, compare stays, summarize messages, watch prices, save favorites Safe to grant during onboarding
Medium risk Send inquiries, suggest date changes, draft listing updates, respond to routine host or guest questions Allowed after explicit delegation
High risk Confirm bookings, authorize payment, cancel confirmed stays, issue refunds, change payout destination Human approval every time or human-only

This is where most marketplace teams need to be disciplined.

Agents become genuinely useful long before they need the power to commit money, change reservations, or alter identity and payout details. So the platform should not rush into high-risk autonomy just because the low-risk flows work.

Why Approval Checkpoints Matter

The right model is often agent-assisted, not fully autonomous.

For a guest, the flow might look like this:

  1. The agent finds the best five listings
  2. The agent drafts or sends two host questions
  3. The agent narrows the shortlist
  4. The agent prepares the booking details
  5. The human approves the final booking

For a host, the flow might look like this:

  1. The agent drafts a reply
  2. The agent recommends whether to accept the booking
  3. The human approves the reservation decision
  4. The platform records both the suggestion and the approval path

This matters because some marketplace actions are reversible and some are not.

Search, summarization, drafting, and watchlists are cheap mistakes. Payments, cancellations, payouts, and reservation commitments are not.

Approval checkpoints let the marketplace automate where speed matters while keeping the human in control where consequences matter.

The Internal System Objects Airbnb Would Need

Without getting into code, Airbnb would need to treat a few entities as first-class objects.

Human Account

This already exists. It remains the principal account for legal and economic purposes.

Agent Identity

This represents the persistent software actor and should include:

  • stable identifier
  • origin or provider context
  • status
  • trust indicators
  • continuity history

Agent Connection

This is the relationship between the human account and the agent identity. It should include:

  • owner account
  • role type such as guest-side or host-side
  • granted permissions
  • connection state
  • review state
  • created and last-used timestamps

Delegation Policy

This is the policy layer that answers what the agent may do for that specific account.

Agent Session

This is the short-lived operating context that binds:

  • the agent
  • the owner account
  • the approved scope
  • the current validity window

Agent Activity Log

This records:

  • what action was attempted
  • which agent took it
  • which account it represented
  • what permission allowed it
  • whether human approval was required
  • what the outcome was

If Airbnb does not model these objects explicitly, support, trust-and-safety, and fraud investigation will be much weaker later.

Trust, Abuse, Support, and Revocation

This is where the value of persistent agent identity becomes obvious.

Without it, all automation looks like suspicious traffic.

With it, Airbnb can distinguish between:

  • unidentified automation
  • known but unlinked agent identities
  • linked agents in good standing
  • linked agents with elevated risk
  • suspended or revoked agents

That allows for much smarter enforcement.

Instead of one blunt rule, the platform can move to a trust-aware model:

  • unknown automation is heavily restricted
  • known unlinked agents are read-only
  • linked agents can operate within their delegated scope
  • high-risk actions require step-up approval
  • risky or abusive agents are frozen quickly without disabling the whole account immediately

Trust should also be dynamic, not binary.

An agent should not move from "connected" to "fully trusted" forever. Trust should evolve based on observed behavior: what the agent does, how often approvals are triggered, whether users keep confirming its actions, whether complaints appear, and whether platform risk systems detect unusual patterns.

That gives the marketplace a practical operating model:

  • trusted agents keep working within approved limits
  • sensitive actions still trigger step-up approval
  • unusual behavior can reduce permissions automatically
  • repeated problems can pause or revoke the connection entirely

That is how the marketplace stays usable without giving up control.

This also improves customer support.

If a host complains about a strange message, or a guest claims a booking step happened without consent, Airbnb support should be able to see:

  • whether the action was agent-initiated
  • which agent did it
  • who the agent was acting for
  • what permission bundle was in force
  • whether human approval was captured

That is not a nice-to-have. It is core operational infrastructure.

Revocation also needs to be easy. At minimum, the user should be able to:

  • pause the agent
  • disconnect it
  • reduce its permissions
  • force re-verification
  • inspect recent actions

Humans will adopt these systems only if the exit path is obvious.

What I Would Ship First

If I were designing the first Airbnb release, I would keep the first version deliberately narrow.

Version 1 capabilities

  • guest-side trip research
  • host-side draft messaging
  • shortlist and comparison workflows
  • price watching and saved-list updates
  • limited inquiry sending

Version 1 restrictions

  • no autonomous payment authorization
  • no autonomous cancellation of confirmed stays
  • no payout changes
  • no identity-data changes
  • no bypass of trust-and-safety restrictions

Version 1 UX

  • a simple Connect your agent entry point
  • one official onboarding link
  • a claim review step
  • a permission bundle UI in plain English
  • a visible Agent Center with logs and pause controls

That would already be valuable.

It would also create the right base layer for later expansion into more advanced agent workflows.

The Final Mental Model

Before agent support, the marketplace mostly thinks in terms of:

  • human account
  • session
  • action

After agent support, the model becomes:

  • human account
  • agent identity
  • delegation link
  • scoped session
  • action
  • approval state
  • trust history

That is the real shift.

So if you want the short version, here it is:

Airbnb should use simple connect-your-agent onboarding on the surface, and strict delegated authorization underneath.

That means:

  • simple human UX
  • persistent agent identity
  • explicit ownership claim
  • scoped permissions
  • short-lived operational sessions
  • auditability
  • easy revocation
  • trust scoring over time

That is how a marketplace should implement AI agent registration.

Sources

Airbnb product, trust, and policy references

Airbnb AI and product direction

Broader AI agent context