Akamai Reports AI Bots at 47.9% of Commerce Traffic

Akamai published new commerce-security findings on July 15, 2026, reporting that AI bots accounted for 47.9% of commerce traffic observed across its network as of December 2025. The company framed the change as both a security and governance problem: automated agents can be legitimate customers, crawlers, or assistants, while malicious operators can use similar interfaces and behavior to commit fraud or attack APIs.

The main findings

• AI bots represented 47.9% of commerce traffic on Akamai's network as of December 2025.
• AI training crawlers generated more than 70% of the AI bot triggers described in the report.
• Web attacks targeting APIs increased 9% year over year in the reported dataset.
• Akamai said Layer 7 DDoS activity against commerce approached three trillion events in 2025, with retail receiving most of that volume.
• The report described growth in phishing, malware, synthetic identity activity, and attacks that use or compromise agentic workflows.

Automation is not a single risk category

An AI crawler collecting public pages, a shopping assistant comparing products, an internal agent calling an authenticated API, and an attacker automating account takeover are all automated, but their permissions and impact differ. A policy that treats every automated request as hostile blocks useful activity. A policy that treats a convincing browser session as human can miss agentic abuse.

This is why classification and access policy must remain separate. Classification describes the likely client or behavior. The final decision asks whether that client may perform this action, at this rate, with this identity, on this route. Public content can tolerate different uncertainty from login, stored payment, loyalty balance, inventory reservation, or account recovery.

Why APIs sit at the center

Commerce interfaces increasingly depend on APIs for catalog search, pricing, accounts, payments, inventory, and fulfillment. Automated clients can call those interfaces without rendering the visible storefront. If monitoring exists only at the page layer, teams may miss the route where the business action actually occurs.

• Inventory every public, partner, mobile, and internal API that participates in a revenue or identity workflow.
• Require authorization at the resource and action level; a valid token should not grant unlimited automation.
• Measure calls by identity, route, result, and time window rather than only by source IP.
• Use idempotency and transaction controls so retries or parallel agents cannot duplicate sensitive actions.
• Protect the browser route and its backing API consistently to avoid a policy gap.

A practical agent-ready policy

1. Identify the operator when possible through authenticated credentials, published crawler verification, or an approved integration.
2. Bind permission to a purpose and route instead of granting a broad trusted-bot exception.
3. Collect network, request, client, and behavioral evidence without assuming any one field proves intent.
4. Use allow, monitor, throttle, challenge, and deny outcomes according to confidence and business impact.
5. Log the final decision and reason, then review allowed automation as carefully as blocked automation.
6. Keep a failover policy for decision-service errors so an outage does not silently disable critical safeguards or lock out all customers.

What teams should measure next

Separate human, known automated, unknown automated, and policy-violating traffic where the evidence permits. Track completion and failure for protected actions, not only request volume. A useful dashboard shows allowed, blocked, challenged, and errored decisions by route and reason, together with support reports, latency, account takeover indicators, and business outcomes.