Digital Product

An AI agent needs permissions, not your customer's password

Amazon blocked Muse; Walmart's CAPTCHA interrupted agents it intended to welcome. The engineering response is scoped access, not an open door.

Blaxline Editorial Team

Strategy & Engineering

Editorial image illustrating a blocked AI agent attempting to access a digital service

A customer asks a personal AI agent to check an order or make a booking. The agent reaches the business website and is stopped by a CAPTCHA. The visible failure is a browser challenge; the architectural problem is that the business has no reliable contract for delegated action.

These failures are already observable. TechCrunch reported on October 6, 2026 that Amazon blocked Meta's Muse from shopping on its site. Walmart, by contrast, said it wanted to support Muse, but some visits failed at human-verification challenges. The difference matters: an intentional commercial restriction is not the same as an anti-bot false positive.

Do not transfer the customer's entire session

A browser session can expose orders, saved addresses, account settings and payment options. An agent instructed to check delivery status needs none of the authority to edit those settings. Treat delegation as an independent authorization problem, not as a shortcut to reuse a password or browser cookie.

Start with an operation inventory: public product lookup; authenticated order lookup; reversible cart changes; and high-impact actions such as payment, cancellation or changing personal information. For every operation, specify input validation, who owns the business rule, the smallest permitted scope, a timeout, rate limits and a clear failure response.

The missing interface is a permission contract

An agent's identity and the customer's consent answer different questions. Knowing which software is calling does not prove that the customer authorized a refund. Similarly, a user instruction in a prompt is not server-side permission. The API must check the actor, delegated subject, resource, action and current authorization for each request.

For sensitive writes, require a fresh, explicit confirmation and protect against retries. An idempotency key can stop an interrupted network request from creating two bookings or charges. Log the action, result and consent reference without retaining unnecessary customer data. Provide a revocation path and a human handoff that preserves the case context.

What Poppy changes—and what it does not

On October 9, Sierra published a draft of Personal Agent Protocol, known as Poppy. It proposes discovery at /.well-known/poppy.json, agent identification, OAuth-based customer sign-in and scoped sessions that can operate across websites, APIs and company agents. It builds on existing technologies including HTTPS, JWT, OpenAPI and MCP. The business still decides which operations to expose.

That is a promising interoperability model, not evidence that every commerce site or agent already supports it. Teams should monitor the draft and test real partners rather than treating an emerging protocol as a universal production dependency.

Three practical routes

Block: appropriate for unknown traffic or sensitive systems that cannot authenticate delegated users. Document the restriction and provide a usable human alternative.

Partner: use an established channel where identity, commercial terms and permitted operations are negotiated. Check which customer information and audit events the business receives.

Expose a first-party interface: build a narrowly scoped API or company agent when direct customer relationships or specialized workflows justify ownership. This requires versioning, monitoring, abuse controls and a team responsible for maintenance.

Release tests that matter

  1. Prove that an anonymous agent can only read public information.
  2. Prove that an authenticated agent cannot exceed a narrowly scoped grant.
  3. Reject expired, revoked or replayed credentials.
  4. Require confirmation for payment, cancellations and other sensitive writes.
  5. Simulate retries, rate limits, downstream failures and transfer to a person.
  6. Verify that the audit trail identifies the action without leaking secrets.

At Blaxline, the design question is not whether to let every bot in. It is which customer tasks should be possible, through which controlled interface, and who will operate that interface after launch. A successful system completes an authorized task predictably and rejects an unauthorized one safely.

For the customer-channel perspective, see Pimentone's analysis of AI agent blocks. Explore the engineering implications of Shop MCP.

Frequently asked questions

Should websites let all AI agents through?

No. Public reading, authenticated access and high-impact actions need different controls. Unknown or abusive automation may be blocked.

Is Poppy already a universal standard?

No. Sierra published a draft in October 2026. Availability and interoperability must be verified for each integration.

Does OAuth alone make an agent safe?

No. OAuth supports delegated authorization; the application must still enforce scopes, business rules, confirmation, revocation and auditing.

SOURCES & REFERENCES

Explore the sources

The Blaxline Editorial Team brings together strategists, designers and engineers to examine how technology can make important business work clearer, more connected and easier to evolve.

KEEP EXPLORING

View all thinking
An AI agent needs permissions, not your customer's password