Silent agents that shop, book, and sign in for human customers are arriving without identifying themselves. Blocking all of them costs you a customer. Allowing all of them exposes you to significant risk. This blog post outlines a third option: selective action.
Agents: Yes or no? Most of the pain from AI agent traffic comes from businesses applying one answer to that question to their entire property. Almost no business should use either answer everywhere.
Selective action is a better approach than either blocking everything or allowing everything. With selective action you can:
- Find out what is already reaching you
Find out what is already reaching you
- Set policy based on your definition of acceptable use
Set policy based on your definition of acceptable use
- Make verification the path to “yes”
Make verification the path to “yes”
- Keep the browsing door open while identity catches up
Keep the browsing door open while identity catches up
What is a silent agent?
A silent agent is automation acting through an ordinary browser or customer session without providing a verifiable agent identity. It may be a legitimate assistant acting for the customer, an unauthorized agent exceeding its mandate, or malicious automation imitating agent behavior.
When human and automated activity occur within the same authenticated session, distinguishing between the two becomes more challenging. Without explicit agent identification, businesses must rely on behavioral and technical signals that don't always tell the full story: Relax detection to accommodate legitimate agents, and you risk exposing your business to malicious automation; tighten it, and you risk blocking customer-authorized activity.
A session-hijacking paradox
The silent agents Meta Muse and Instinct work this way today. OpenAI Dots adds a twist: It’s signed in the cloud, but silent when it falls back to the customer's own computer. OpenAI tells their customers, “If a website blocks the cloud browser, ask your dot to try your connected computer.” That’s the challenge. When agents do not sign their requests, a shopping agent that’s buying sneakers for a real human customer and a reseller bot imitating one can look remarkably similar.
The agentic ecosystem is evolving rapidly, and businesses took notice quickly. Amazon cut Muse off from its store on September 20 after Meta refused to remove Amazon from the agent. Amazon said Muse did not identify itself and appeared to store customer credentials. JPMorgan blocked external agents from customer accounts on October 13, and Citi, Schwab, and Bank of America drew similar lines within the same week.
Axios reported that banks are finding third-party agents inside customer accounts, and that some of those agents appear to act beyond what the customer asked for. Retailers have hit a different problem: Shoppers are complaining that an agent could not finish a purchase, usually because anti-bot controls scored it as automation rather than intentionally blocking that specific agent.
Most of the responses so far fall into two buckets:
- Block agents outright at login and at money movement
Block agents outright at login and at money movement
- Provide read-only access, letting an agent see an account without acting on it
Provide read-only access, letting an agent see an account without acting on it
Both responses are reasonable holding positions, but neither is a strategy, because both answer a yes-or-no question when the real question is which actions an agent should be allowed to take.
Visibility, insight, and selective action
Our position is that automated traffic should be governed by what it came to do and how much the site can verify about it, not by whether the word “agent” applies. That requires three things in sequence:
- Visibility: To see agentic traffic separated by purpose instead of lumped into one bucket
Visibility: To see agentic traffic separated by purpose instead of lumped into one bucket
- Insight: To know which agents declared themselves and which were inferred from behavior
Insight: To know which agents declared themselves and which were inferred from behavior
- Selective action: To allow an agent to browse your catalog while still scoring every checkout attempt for automation risk
Selective action: To allow an agent to browse your catalog while still scoring every checkout attempt for automation risk
Four imperatives follow from that, and they are spelled out at the end of this post: Know what is already reaching you, decide per endpoint rather than per site, treat verification as the way to say yes, and keep the browsing door open while the industry builds agent identity.
What makes an agent silent
For most of the history of bot management, any automation worth welcoming announced itself. Search crawlers published their user agents and their IP ranges. For example, a site could look up Googlebot, confirm it, and treat it differently from an anonymous scraper. That arrangement worked because the bot operator wanted to be recognized.
Consumer agents unintentionally broke the arrangement. They were built to use the web the way a person does, so they drive a browser, click through pages, fill in forms, and work around the friction that a human would work around.
- Muse runs in a virtual machine in Meta's cloud with a built-in browser.
Muse runs in a virtual machine in Meta's cloud with a built-in browser.
- Instinct keeps a persistent cloud desktop and operates it with the user's own stored credentials, including email and payment details.
Instinct keeps a persistent cloud desktop and operates it with the user's own stored credentials, including email and payment details.
- Dots runs as a cloud agent from OpenAI.
Dots runs as a cloud agent from OpenAI.
From the server's point of view, each one is a browser session: The User-Agent string says browser; their behavior says automation.
Authenticated risk: Beyond catalog browsing
This matters because of what sits on the other side of that session. An agent browsing a product catalog is a privacy question at most. An agent signed in with a customer's credentials is a different thing entirely. Instinct's own terms appoint it as the user's agent for binding transactions, and its privacy notice names unintended payments and manipulation through hidden instructions as risks of using it. Early testers documented both: One planted instructions in an email and watched the agent follow them, while another had an email sent on their behalf without approval.
So when banks say that they cannot tell whether an action inside an account was user-directed, they are describing a real gap, not a detection failure they can buy their way out of. The agent is in the session legitimately, using credentials that the customer handed over. Nothing in the request says otherwise.
What businesses are reporting
The reports arrive in two flavors depending on whether the agent shows up in banking or in commerce.
Banking: Unverified actions in authenticated accounts
In banking, the concern is action inside an authenticated session. Axios reported that major U.S. banks are detecting third-party agents operating in customer accounts and that some appear to take steps beyond what the customer requested. The banks’ own public statements have been consistent since mid-October:
- JPMorgan is keeping external agents out of retail accounts.
JPMorgan is keeping external agents out of retail accounts.
- Citi is restricting them.
Citi is restricting them.
- Schwab says it stops agents trying to move client money.
Schwab says it stops agents trying to move client money.
- Bank of America requires human approval before money leaves an account.
Bank of America requires human approval before money leaves an account.
- Chase has told customers not to hand their credentials to third parties.
Chase has told customers not to hand their credentials to third parties.
- Several banks are moving toward read-only access as the compromise.
Several banks are moving toward read-only access as the compromise.
The current trajectory of autonomous AI agents mirrors the early days of financial account aggregation: a messy, unauthorized, UI-scraping phase driven by consumer demand that inevitably forces platforms to move from active resistance into standardized protocols. In the 2010s, aggregators like Plaid, Yodlee, and Mint bypassed the lack of bank APIs by collecting user credentials, spinning up headless scripts to mimic human sessions, scraping data, and bypassing security checks.
Today, autonomous bots and agents are running the exact same playbook.
Commerce: The threat of abandoned revenue
In commerce, the concern is a customer who cannot complete a purchase. Amazon blocked Muse in September and now notifies shoppers when the agent tries to buy something on their account. Reporting from TechCrunch lists Yelp, eBay, Zillow, Pizza Hut, Adidas, and several airlines among sites where users say agents have been turned away. Sometimes that is the result of an intentional policy. In other cases, existing anti-bot controls detect automated purchasing behavior and respond the way they were designed to respond.
Underneath both banking and commerce is volume that was already large before any of these agents launched. Akamai's July 2026 State of the Internet reportfound that nearly half (47.9%) of all AI bot traffic across Akamai’s global network from July 2025 to December 2025 was in the commerce vertical. It also found that commerce organizations had placed more than 90% of AI bot activity in a monitor-only category and allowed roughly three-quarters of the remaining activity without restriction.
Most businesses, in other words, were watching AI traffic rather than governing it, well before agents started reaching for the checkout button.
Why the obvious responses fall short
Blocking every agent is the fastest answer and the easiest to defend internally. At login and for money movement, blocking may also be the most appropriate security decision for now. Applied to an entire site, however, blocking stops being a security decision and becomes a commercial one. The agent is acting for a customer who wants to buy something, and the block lands on that customer. Shoppers who encounter the block do not conclude that their agent needs better credentials; they go to a site that works.
Read-only access is a more considered version and it holds up better, though it answers a narrower question than it appears to. Reading an account is not risk-free when the agent then acts on what it reads in some other system, and plenty of valuable actions are neither a read nor a money transfer, including booking, rescheduling, changing an address, and redeeming a reward. Read-only buys time rather than settling policy.
The third response, allowing an agent through because it is recognized, is the one that tacitly carries the most risk. Recognition today mostly means matching a signature: a pattern of headers, fingerprints, and behavior that a known agent tends to produce. Signatures can be imitated. Any exemption written against a signature is inherited by whatever imitates it well enough, and the traffic most motivated to imitate a shopping agent is the traffic that a retailer wants least at checkout during a launch.
That is the trap. Blanket blocking costs revenue, blanket allowing hands an exemption to the next thing wearing the same costume, and read-only postpones the decision. Stop asking whether to allow agents and start deciding which actions to permit.
Visibility: Group AI traffic by intent
A single “AI bots” category cannot carry a policy, because the traffic inside it wants opposite things. A crawler collecting your product descriptions to train a model, a search crawler indexing your site so your brand appears in an AI answer, and an assistant fetching a single page because your customer asked a question are three fundamentally different transactions.
In August 2026, we split that category in the Akamai Bot Directory into three:
- AI training crawlers — Collect content at scale to train models (e.g., GPTBot, ClaudeBot, and Meta-ExternalAgent).
AI training crawlers — Collect content at scale to train models (e.g., GPTBot, ClaudeBot, and Meta-ExternalAgent).
- AI search crawlers — Index sites for AI search and source citations (e.g., OAI-SearchBot, Claude-SearchBot, and PerplexityBot).
AI search crawlers — Index sites for AI search and source citations (e.g., OAI-SearchBot, Claude-SearchBot, and PerplexityBot).
- AI fetchers and agents — Reach a page in real time to answer a question or complete a task (e.g., ChatGPT-User, ChatGPT Agent, GoogleAgent-Mariner, and suspected silent agents).
AI fetchers and agents — Reach a page in real time to answer a question or complete a task (e.g., ChatGPT-User, ChatGPT Agent, GoogleAgent-Mariner, and suspected silent agents).
This division provides businesses with more granular control over actions that would otherwise contradict one another: Restrict training crawlers to protect content that the organization has not licensed; welcome search crawlers so the content stays visible in AI answers; and treat real-time agents as the customer-driven traffic they usually are — one policy per category, set by the business.
Visibility must also extend past the catalog. The traffic that worries a bank is not browsing; it is signed in. Monitoring agent activity in authenticated sessions is a different measurement from tracking it on content pages, and a business needs both views before it can begin to manage its exposure.
Insight: Know the difference between declared identity and inferred behavior
Categories reveal what kind of traffic arrived. The next thing to question is how you know what you know about each agent, and there are two very different answers.
Some agents declare themselves in a way that can be checked. They publish a key, sign their requests, and can be verified at the edge rather than taken at their word. Those agents are known, and a known agent can carry its own policy — including at checkout — because recognition does not depend on anything that can be copied.
Everything else is inferred. We attribute agents from observed characteristics and label them as suspected, which is why reporting shows an entry like “Muse Agent (suspected)” rather than a confirmed identity. That label is genuinely useful; it tells you an agent is reaching your site, roughly how much of it there is, and where it goes. It does not tell you that the next request carrying the same pattern came from the same agent, and a policy written as though it does will eventually grant access to something you did not intend.
Behavioral risk scoring is what remains when attribution is unavailable, and it is the control that still works when agents use deceptive techniques. By analyzing how a session moves rather than what it claims to be, behavioral analysis holds up against an agent built to look like a browser and against a reseller bot built to look like a shopper.
It is also why legitimate agents sometimes get stopped at checkout. That outcome is the system working as designed: Until agents can authenticate, some legitimate agent traffic will land in the unverified bucket.
The practical consequence for a security team is to read the two signals — category/label and behavior — together. Category and label tell you who is arriving and in what volume. Behavior tells you what that session is doing right now. Neither alone is enough to define policy.
Selective action: Decide per endpoint, not per site
A catalog page and a checkout page carry different risks. An agent reading product descriptions for a customer is doing something that standard browsers have always done. Businesses usually want that traffic because it leads to sales, and because AI assistants are becoming a route to discovery.
The same agent submitting an order, however, is doing something that moves inventory and money, and that deserves the same scrutiny that’s applied to any automation. Login sits closer to checkout than to the catalog. So does anything that changes an account.
This is what selective action means in practice:
- One policy for content, where most AI traffic can be monitored or allowed
One policy for content, where most AI traffic can be monitored or allowed
- A different policy at the transaction, where every request is scored for automation regardless of what it calls itself
A different policy at the transaction, where every request is scored for automation regardless of what it calls itself
- A third policy at authentication, where the question is not whether the session is automated but whether the person behind it is the account holder and whether this is a recognizable action
A third policy at authentication, where the question is not whether the session is automated but whether the person behind it is the account holder and whether this is a recognizable action
Set that way, the outcome looks like what most retailers already see: An agent can browse the catalog for a customer but gets stopped when trying to buy. This keeps the discovery path open, applies existing controls where the money is, and leaves the business free to change its mind on any single endpoint without reopening the whole policy.
The same logic answers the question that we hear most often, which is how to let a specific agent complete a purchase. The move that works is not an exemption written against a signature, since anything imitating that signature inherits it. What works are authentication and verification. Once an agent proves who it is, it can have its own policy, including at checkout, and the business can grant access to a verified party rather than to a pattern.
Where this is heading: The future of agentic identity
Every part of this problem originates with the same missing piece. An agent cannot prove who it is or who it works for, so sites fall back on inference, and inference cannot support businesses’ intended decision-making.
That piece is being built now. Web Bot Auth, a draft in the Internet Engineering Task Force that we support, lets an agent sign its requests so a site can verify the origin cryptographically instead of trusting a header.
Visa's Trusted Agent Protocol builds on the same signature approach for payments, and we integrated it so that merchants can tell whether an agent is browsing or paying and connect that agent to the consumer it represents. Know Your Agent, from Skyfire, adds the identity layer that binds an agent to a verified organization or user, and we joined Experian Agent Trust ecosystem alongside it. In June 2026, we combined these pieces into an agentic security framework covering identity, observability, trust, and edge enforcement.
Bridging the gap: What operators need to do today
Agent operators have a part in this too. Any operator can register with Akamai and have its traffic verified, which turns an inferred signature into a declared identity that merchants can write policy against. The agents getting stopped at checkout today are, for the most part, agents that have not done this yet. Silent agents cannot be allowed through safely until they do.
This work is still in progress, and businesses have to run their sites in the meantime. That is the case for governing by action now and letting identity raise the ceiling as it arrives. A business that has already separated checkout content from login will be able to say “yes” to verified agents when verification shows up at its edge. A business still deciding between “block everything” and “allow everything” will be starting from scratch.
Four steps to take now
Four steps that you can take now include:
- Find out what is already reaching you
Find out what is already reaching you
- Set policy per endpoint
Set policy per endpoint
- Make verification the path to “yes”
Make verification the path to “yes”
- Keep the browsing door open while identity catches up
Keep the browsing door open while identity catches up
Find out what is already reaching you
Pull your AI traffic by category and look at where it lands: content pages, login, checkout, or account changes. Most teams are surprised by the volume and by how much of it continues to be monitored with no decision attached. You cannot set policy on traffic you have not measured.
Set policy per endpoint
Decide separately for browsing, for transactions, and for authenticated sessions. If the answer is the same in all three, it should be a conclusion you reached rather than a setting you inherited.
Make verification the path to “yes”
When a partner or an agent operator asks for access to your checkout, the answer should be registration and verified identity — not an exemption for a signature. Point operators to the registration process. An exemption written against a pattern is an exemption for anything that can copy the pattern.
Keep the browsing door open while identity catches up
Agents acting for real customers are a growing route to your business, and the cost of shutting them out of discovery is paid in sales rather than in incidents. Hold the line where the money moves and leave the catalog reachable.
Prepare for the agentic era
The businesses that handle this well will not be the ones that guessed correctly about which agents to trust. They will be the ones that could see what was arriving, knew how much of it they could verify, and could act on one endpoint without disturbing the rest.
To talk through your current AI traffic categories and transactional policy, contact an Akamai expert.
Further reading
About the author
Brent Maynard
Brent Maynard is the Senior Director, Security Technology and Strategy at Akamai.



