AI agents can't just walk in

AI agents are already handling emails and writing code at work. Now they're moving into everyday tasks, from finding a birthday present to grocery shopping. Having an agent take care of the shopping sounds convenient, until it reaches a website that doesn't want it there.

That was the problem facing Meta's Muse. Designed to carry out tasks on behalf of users, Muse connects through public APIs where available and falls back to navigating a website through a browser when there isn't one. But when customers tried using it to shop on Amazon, they received a warning that continued access by an unauthorized AI agent violated Amazon's Conditions of Use.

The retailer had already asked Meta to remove Amazon from the experience, saying Meta hadn't disclosed that Muse would access its store, and the agent wasn't identifying itself as AI.

A different problem emerged at Walmart. Walmart partners with Muse, but customers still struggled to complete purchases when human-verification checks appeared to interrupt the agent. The retailer confirmed the blocks weren't intentional.

One retailer refused access. Another wanted the agent there, but its existing security measures interfered. Similar disputes over agent access are affecting other major websites.

For developers, the problem is the gap between what an agent can accomplish and what an external service permits it to do.

A browser agent can interact with websites designed for humans, navigating checkout pages and filling in forms without dedicated agent functionality.

The user's permission to complete a task, however, doesn't automatically authorize the agent to access a third-party service.

Yelp, for example, restricts non-human traffic to participants in its paid data licensing program. An agent might be capable of using the website, but improving its navigation won't change that requirement.

Developers need to establish whether the service offers an authorized route.

That might be an API, an MCP server, or structured tools exposed through the website itself. The distinction that matters is whether the agent uses a route the service supports, within the permissions that route provides.

Browser access can be approved too. Shopify extended WebMCP support to checkout, allowing compatible browser agents to interact with the buyer's active checkout through structured tools. When an operation requires the buyer's involvement, control returns to the customer.

Services can allow agents to retrieve information or prepare transactions without authorizing them to complete every action. Shopify's MCP interfaces provide one example of how those boundaries can be enforced.

How permissions change what agents can do

Suppose you're building a shopping agent. A customer asks it to find a pair of running shoes and purchase the right size.

The agent selects a suitable product and prepares to check out. But finding the shoes and spending the customer's money require different permissions.

Shopify's UCP MCP interfaces demonstrate one implementation, with three access tiers.

Anonymous agents can search the catalog and manage a cart at the lowest rate limits. Signed agents provide an HTTP Message Signature to establish their identity and can prepare a checkout, but cannot complete purchases. Token agents use issued bearer tokens, with purchase completion and order access requiring the appropriate permissions.

These are Shopify's specific tiers, rather than requirements imposed by MCP. The broader principle is that identifying an agent and authorizing an operation are separate decisions.

Permissions can also depend on the context of a request. For example, Shopify requires buyer IP information for calls to merchant-facing UCP MCP tools, including read-only operations. Global Catalog requests are exempt. An unattended scheduled task without a buyer present cannot satisfy that requirement.

For developers, the important decision comes before checkout: which operations does the service permit, and does the agent have the credentials and buyer context required to perform them?

Handling an access failure

Back to the running-shoe agent. The product is selected and checkout is ready, but something prevents the purchase from proceeding.

Four situations need different handling.

1. The service requests identification. Under the Web Bot Auth IETF draft, a 403 or 429 response containing an Accept-Signature header can request a signed message. The agent should inspect the challenge and use an authorized signing mechanism if supported. Signing requirements differ between integrations, and identifying the client doesn't automatically authorize every operation.
2. The agent lacks permission. An integration might permit checkout preparation without authorizing the agent to complete a purchase. Repeating the call won't change its permissions. The workflow needs an appropriately authorized credential or a supported handoff to the buyer. For example, Shopify documents a continue_url that allows the customer to finish a checkout through the merchant's storefront.
3. The service applies a rate limit. When an endpoint returns 429with Retry-After, the agent should respect the specified delay and apply backoff with jitter. For state-changing operations, retries also need to be safe. Where the service supports idempotency keys, reuse the original key when retrying a purchase or similar action to avoid processing it twice.
4. The service deliberately refuses access. If a retailer prohibits the agent from shopping there and provides no authorized alternative, the agent should stop. It can retain verified results and explain the restriction to the user, but changing identities or bypassing the block shouldn't be part of its recovery strategy.

Agent evaluations should test these failures alongside successful purchases. They need to establish that the agent respects permissions, handles retries without duplicate transactions, and doesn't report success when an operation was refused.

Giving agents access without giving them everything

Teams running websites and APIs face the corresponding problem of deciding what automated clients should be allowed to do.

Charles Schwab has been blocking unauthorized agents attempting to access customer accounts, while planning MCP servers that would let approved external AI tools check balances and perform research without moving money.

That offers customers some of the benefits of agent-based assistance without granting external agents the authority to transfer funds.

For service operators, the starting point is deciding which existing functions should be available to agents and enforcing the appropriate permissions. Developers also need clear documentation describing the supported operations and authentication requirements.

In Designing websites for people and AI agents with WebMCP, Angie Jones explains how websites can expose structured functionality while preserving their existing application-level access controls. The same principle applies to MCP servers.

The boundaries are still being drawn

Some services offer structured interfaces with limited capabilities. Others require commercial arrangements or reject particular agents altogether.

The open question is how consistently services will communicate their access boundaries, and whether agents will be able to recognize those limits before a customer's task fails halfway through.