AI Agent Traffic: What Amazon’s Block of Meta’s Muse Means for Enterprise Security

AI Agent Traffic: What Amazon’s Block of Meta’s Muse Means for Enterprise Security

by | Sep 22, 2026 | Compliance, Network Security, Seimless

Over the weekend of September 20, 2026, Amazon shut Meta’s new Muse personal AI agent out of Amazon.com. Shoppers who asked Muse to buy something got a blunt message: continued access by an unauthorized AI agent violates Amazon’s Conditions of Use. Headlines framed it as a retail turf war. For security leaders, it is something bigger: the first high-profile, consumer-scale collision over AI agent traffic — and a preview of decisions every enterprise will have to make about the autonomous software now knocking on its digital front door.

This post breaks down what happened, why the courts won’t settle it for you, what the numbers say, and how financial services, healthcare, and insurance organizations can build an AI agent traffic policy that is enforced at the network — not just written in a terms-of-service page.

What is AI agent traffic? AI agent traffic is network and web activity generated by autonomous AI software acting on a person’s or organization’s behalf — logging in, browsing, filling forms, calling APIs, and completing transactions. Unlike classic crawlers, AI agents often use real user credentials and mimic human browsing, which makes them hard to tell apart from people or attackers unless they identify themselves cryptographically.

What Happened: Amazon vs. Meta’s Muse, in Brief

Meta introduced Muse in September 2026 as a personal agent that “takes action”: it can open browsers, fill forms, send email with approval, and make purchases through Stripe Link. TechCrunch covered the debut on September 8. Within two weeks, GeekWire reported that Amazon had blocked it after first asking Meta to remove Amazon from the experience voluntarily.

Amazon’s stated objections are the ones security teams should notice:

  • No self-identification. Amazon says Muse accessed the store without identifying itself as an agent or reaching any prior agreement.
  • Credential custody. Amazon says the agent captures and stores customer credentials and, when instructed, can reach order history and other account data.
  • Amazon’s position, as reported by TechCrunch, is that third-party apps that buy on a customer’s behalf “should operate openly.”

Meta’s side matters too. The company says Muse cannot see users’ passwords or payment methods; credentials sit in secure storage and are used for authentication without being exposed to the model. Meta also describes a dedicated secure VM, a separate “Sentinel” agent that approves internet-bound actions, and audit trails. Forbes and Bloomberg framed the standoff around commerce, and the money is real: Amazon’s advertising business depends on humans seeing sponsored placements, while Oppenheimer’s Jason Helfstein estimates Meta would need about 115 million subscribers at $20 a month to reach $28 billion in AI revenue — a target he doubts it will hit.

Both companies can be partly right. That is exactly the problem: when an AI agent shows up, the receiving system usually cannot verify either company’s claims in real time.

Why AI Agent Traffic Is a Security Story, Not Just a Retail Feud

Strip away the brands and you have three questions every CISO will face this year:

  1. Who is this? Is the session a human, a declared agent, a scraper, or an attacker using a stolen session token?
  2. On whose authority? Did the account holder actually delegate this action, and within what limits?
  3. Who holds the keys? Where do the credentials live, and what happens when that third-party vault is breached?

We call this the undeclared agent problem: software that uses a legitimate person’s identity but never announces that software, not a person, is at the keyboard. Undeclared AI agent traffic looks almost identical to account takeover (ATO). The same signals that flag fraud — a new device, headless browser fingerprints, machine-speed navigation — also flag helpful agents. Block too much and you break customer experience; block too little and you give attackers the perfect disguise.

We explored the inside-the-enterprise version of this in The Hidden Risk of AI-to-AI “Blind Agent Transfer”. The Muse episode is the outside-in version: agents arriving from someone else’s platform, carrying your customers’ credentials.

The Legal Backdrop: Why the Courts Won’t Manage AI Agent Traffic for You

Amazon has been here before. It sued Perplexity over the Comet browser’s shopping agent and won a preliminary injunction in March 2026. On August 4, 2026, the Ninth Circuit vacated that injunction. As Cooley’s analysis summarizes, the court held that when an agent’s communications route through the user’s own computer, it is the user — not the AI developer — who “accesses” the site under the Computer Fraud and Abuse Act.

The ruling builds on the Supreme Court’s narrowing of the CFAA in Van Buren v. United States (2021). It also left doors open: contract and tort claims survive, and agents that act more autonomously or talk directly to target servers could still face liability.

The practical takeaway for enterprises is simple. Anti-hacking law is a slow, uncertain backstop for AI agent traffic. Your terms of service state a policy. Your network and identity controls enforce it. Amazon didn’t wait for a court — it enforced at the edge.

AI Agent Traffic by the Numbers

The scale is no longer theoretical. The 2026 Thales (Imperva) Bad Bot Report, released April 29, 2026, found:

Metric Figure Why it matters
Share of all web traffic that is automated Over 53% Humans are now the minority on the web
Growth in AI-driven bot attacks, year over year 12.5x Attackers are adopting agents faster than defenders
Bot attacks aimed at APIs 27% Agents skip the web page and go straight to the data
Share of bot attacks hitting financial services 24% Banking is the top target
Account takeover incidents targeting financial services 46% Credential-carrying traffic is the core risk

 

Federal data tells the same story. The FBI’s 2025 IC3 Annual Report logged $20.877 billion in reported losses, including 22,364 AI-related complaints totaling $893.3 million. The FBI also issued a November 2025 account takeover fraud alert citing more than 5,100 complaints and over $262 million in losses in less than a year. When legitimate AI agent traffic and ATO traffic look the same, both numbers get harder to manage.

Two Directions of Risk: Inbound Agents and Outbound Agents

Inbound: agents at your front door

If you run a banking portal, a patient portal, a claims system, or a B2B ordering site, agents like Muse are coming whether you invite them or not. Customers will ask their assistant to “pay my premium,” “download my lab results,” or “dispute that charge.” Every one of those sessions is AI agent traffic using a real customer’s credentials.

Financial services has seen this movie. Screen scraping by data aggregators was supposed to give way to secure APIs under the CFPB’s Personal Financial Data Rights rule (Section 1033). That rule is now enjoined while the Bureau reconsiders it. In the meantime, agents are reviving the old pattern — credential-based access through the front end — at far larger scale.

Outbound: agents carrying your keys

The quieter risk is inside your own walls. An employee who connects a personal agent to a corporate mailbox, a SaaS admin console, or a vendor portal has just placed company credentials in a third-party vault you never assessed. That is shadow AI with a credit card attached. We have already seen attackers go after exactly these stores — see our coverage of a Python backdoor stealing browser and cloud credentials and fake résumés used for credential theft. A centralized agent credential store is an even richer target.

How to Identify AI Agent Traffic: From User-Agent Strings to Cryptographic Proof

User-agent strings and IP allowlists were never proof of identity; they are a label anyone can copy. The industry is moving toward cryptographic proof:

The direction is clear: AI agent traffic should declare itself, prove its operator, and carry a scoped, revocable delegation from a human who authenticated strongly.

A 7-Step AI Agent Traffic Governance Framework

  1. Decide your policy in writing. Allow declared agents, allow them only through an API, or block them. Choose per system: a public catalog and a wire-transfer page deserve different answers.
  2. Inventory where agents already touch you. Use web logs, WAF data, and endpoint detection to find headless browsers, automation frameworks, and agent-hosting IP ranges.
  3. Offer a front door. Give legitimate agents an authenticated API with OAuth-style scoped tokens, so they have no reason to scrape your UI.
  4. Require proof, not labels. Favor signed requests (RFC 9421 / Web Bot Auth) and verified operator keys over user-agent strings.
  5. Bind agents to scope and step-up. Agents may read a balance; moving money, changing a payee, or releasing records requires human step-up authentication.
  6. Govern outbound agents. Ban unmanaged agents from holding corporate credentials; route approved ones through enterprise identity and Security as a Service
  7. Log for accountability. Record agent identity, delegating user, scope, and action in tamper-evident logs, mapped to the NIST AI Risk Management Framework, the OWASP GenAI Security Project, and MITRE ATLAS threat techniques.

Why the Network Layer Is Where AI Agent Traffic Gets Decided

Amazon’s block worked because it happened before the agent reached the storefront. That is the lesson: policy that isn’t enforced in the traffic path is only a suggestion. This is the core idea behind NIST SP 800-207 zero trust architecture — and our own primer, What Is Zero Trust? — where every request is evaluated on identity and context, every time.

At ibm/SEIMless, we build that enforcement into the network itself through the Exodus portfolio:

There is also a quantum dimension. Agent identity is built on digital signatures and key exchange. Sessions recorded today can be decrypted later — the harvest now, decrypt later threat — and long-lived agent keys will need to move to NIST’s post-quantum standards such as FIPS 203 (ML-KEM). We covered that convergence in Agentic AI Security Meets Q-Day, and the federal deadlines in our Executive Order 14412 guide. The Exodus Quantum Resistant Network is designed so the trust you build for AI agent traffic today still holds after Q-Day.

What AI Agent Traffic Means for Financial Services, Healthcare, and Insurance

Financial services. Banks carry the heaviest share of bot and ATO attacks. The NYDFS Part 500 cybersecurity regulation now requires MFA for any individual accessing information systems — so an agent riding a customer or employee session must not become a quiet MFA bypass. Public companies should also weigh material agent-driven incidents against the SEC’s cybersecurity disclosure rules.

Healthcare. Patients will send agents to fetch records and book visits. The HIPAA Security Rule still requires access controls, audit controls, and person-or-entity authentication — obligations that apply no matter who, or what, is clicking.

Insurance. Quote, claims, and policy-change flows are prime targets for agent automation and for fraud hiding inside it. Scoped APIs and step-up rules for payout changes should come first.

Across all three, the network is where your answers become real. Solutions like SD-WAN alone don’t inspect identity — which is why we argued that SD-WAN is not ready for next-generation attacks and why network edge security is now the front line.

The Bigger Picture: Build Trust, Not Just Walls

AI agents will serve people well — in accessibility, in saved time, in better decisions. The goal is not to fear them. It is to make sure every agent that touches your business is honest about what it is, limited in what it can do, and accountable for what it did. Organizations that build that trust now will welcome the agent economy on their own terms. Those that don’t will be forced to choose between blocking customers and trusting strangers. As we noted when asking whether SaaS is dead, agents are becoming the new interface. Your security architecture has to be ready to meet them.

Frequently Asked Questions About AI Agent Traffic

Why did Amazon block Meta’s Muse AI agent?

Amazon says Muse accessed its store without identifying itself or reaching an agreement, and that it captured and stored customer credentials. Amazon displayed a notice that continued access by an unauthorized AI agent violates its Conditions of Use. Meta says Muse cannot see users’ passwords or payment methods.

Is it illegal for an AI agent to use a website on my behalf?

Not necessarily under federal anti-hacking law. In August 2026 the Ninth Circuit held that when an agent routes through the user’s computer, the user — not the AI developer — accesses the site under the CFAA. Contract and terms-of-service claims can still apply. This is not legal advice; consult counsel for your situation.

How can a company tell AI agent traffic from human traffic?

Behavioral signals like headless browsers and machine-speed navigation help, but they are unreliable. The stronger approach is cryptographic: signed HTTP requests (RFC 9421 and Web Bot Auth), verified operator keys, and scoped tokens issued through an authenticated API.

Should enterprises block all AI agents?

Usually no. Blanket blocking frustrates customers and pushes agents toward disguise. A better policy allows declared, verified agents through a scoped API, requires human step-up for high-risk actions, and blocks undeclared automation.

What is the risk of employees using personal AI agents at work?

Personal agents may store corporate credentials in third-party systems your security team has never assessed. That creates shadow AI exposure, weakens MFA, and concentrates keys in a vault that attackers will target.

How does quantum computing affect AI agent security?

Agent identity depends on signatures and key exchange that today use RSA and elliptic-curve cryptography, which large quantum computers are expected to break. Recorded sessions can be decrypted later, so long-lived agent keys and sessions should move to post-quantum cryptography and quantum-resistant networking.

Contact us | Our Blog | Our Services | See Previous Post….

QKD vs PQC: Why Washington Chose Post-Quantum Cryptography — and Where Quantum Key Distribution Still Fits

QKD vs PQC: Why Washington Chose Post-Quantum Cryptography — and Where Quantum Key Distribution Still Fits

by | Sep 18, 2026 | Compliance, Exodus QRN, PQC, Quantum Security, Seimless

Every quantum-security conversation eventually reaches the same fork in the road: QKD vs PQC. Do you protect your network with quantum physics — quantum key distribution over dedicated fiber — or with new mathematics, the post-quantum cryptography algorithms NIST standardized in 2024? For years, vendors on both sides blurred the answer. In 2026, the U.S. government stopped blurring it. The National Security Agency, the Pentagon, and the Office of Management and Budget have all chosen post-quantum cryptography as the foundation of the federal migration, and the Pentagon has formally barred QKD as a security mechanism for its systems.

That doesn’t make quantum networking a dead end. The same White House that set the PQC deadlines is funding quantum networks for sensing, timing, and distributed computing. For CIOs and CISOs in financial services, healthcare, insurance, and the defense supply chain, the practical question is not which camp wins. It is what to build first, what to buy with confidence, and what to hold as an option. This guide answers the QKD vs PQC question the way regulators now expect you to answer it.

Quick answer — QKD vs PQC: Quantum key distribution (QKD) uses the physics of single photons to share encryption keys over a dedicated optical link and detect eavesdropping. Post-quantum cryptography (PQC) uses new math problems — such as NIST’s ML-KEM and ML-DSA — that run in software and hardware on existing networks and resist attack by quantum computers. U.S. policy treats PQC as the required foundation. QKD, where it is used at all, is a supplementary layer on specific links and never a substitute for PQC authentication.

QKD vs PQC in Plain Terms: Two Very Different Answers to Q-Day

Both technologies exist because of one threat. A cryptographically relevant quantum computer running Shor’s algorithm would break RSA and elliptic-curve cryptography, the public-key math that protects nearly every VPN, TLS session, and digital signature in use today. Adversaries already collect encrypted traffic to decrypt later, the harvest now, decrypt later strategy that makes this a present-day risk.

How quantum key distribution works

QKD sends key material encoded in the quantum states of photons. Because measuring a quantum state disturbs it, an eavesdropper on the line introduces detectable errors. The two endpoints compare samples, discard compromised bits, and keep a shared secret. The idea is elegant: security rests on physics rather than on an assumption that a math problem is hard. As the U.S. Department of Energy explains in its primer on quantum networks, these systems rely on superposition, no-cloning, and entanglement.

How post-quantum cryptography works

PQC replaces vulnerable algorithms with ones built on problems that neither classical nor quantum computers are known to solve efficiently. In August 2024, NIST finalized its first three PQC standards: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. In March 2025, NIST selected HQC as a backup key-establishment algorithm based on different math. PQC is software and firmware. It runs over the fiber, MPLS, broadband, and wireless links you already own.

What the NSA Says About QKD — and Why It Matters to Every Buyer

The clearest statement in the QKD vs PQC debate comes from the NSA. Its public guidance on quantum key distribution and quantum cryptography says the agency does not recommend QKD for National Security Systems and does not anticipate certifying or approving QKD security products unless its limitations are overcome. The NSA lists five of them:

  1. A partial solution. QKD produces keys but does not authenticate who is on the other end. You still need classical or post-quantum signatures to prevent a man-in-the-middle.
  2. Special-purpose hardware. QKD requires dedicated fiber or free-space optical equipment. It cannot be delivered as a software update or a network service.
  3. Cost and insider risk. Distance limits force “trusted relays,” secured facilities where keys exist in the clear and insiders become part of the threat model.
  4. Hard to validate. Real-world security depends on engineering, not theory. Hardware flaws can open side channels the physics never anticipated.
  5. Denial of service. The same sensitivity that detects eavesdropping lets an attacker disrupt the link simply by disturbing it.

The NSA concludes that post-quantum cryptography is the more cost-effective and easily maintained solution. For regulated enterprises, that statement matters beyond defense. Banking, healthcare, and insurance examiners anchor their expectations to NIST and NSA guidance, so a security architecture that cannot be mapped to those references is harder to defend in an audit.

The Pentagon Drew a Hard Line on QKD vs PQC

Defense leadership has gone further than advice. A November 18, 2025 DoD CIO memorandum, Preparing for Migration to Post Quantum Cryptography, states that components shall not use quantum confidentiality technologies — naming QKD, solutions that combine QKD with other key establishment, and quantum communications or networking — as a means of achieving confidentiality, authentication, or key distribution.

The Department of War then made the position permanent in its Post-Quantum Cryptography Strategy, announced in a June 23, 2026 release. The strategy repeats that QKD and quantum networking will not be used to achieve security, and adds a line every vendor should read twice: solutions that lack PQC authentication — migrating confidentiality only — will not be considered fully PQC. Its deadlines are blunt. All systems must support PQC by December 31, 2030 or be phased out, and all systems must use PQC by December 31, 2031. DefenseScoop reported that the strategy describes insecure communications in a quantum era as an “existential threat” to military operations.

If you sell to the defense industrial base, this is not an abstract debate. QKD does not count toward your PQC obligations, and a QKD-first architecture could be one you have to re-engineer.

OMB M-26-15 and Executive Order 14412: The Civilian Clock Is Running

On the civilian side, Executive Order 14412, signed June 22, 2026, set the federal PQC calendar we analyzed in our Executive Order 14412 deadline guide. Two days later, OMB issued Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography. It gives agencies 120 days — roughly October 22, 2026 — to submit PQC migration plans, calls for TLS 1.3 support by January 2, 2030, and targets completion of prioritized migrations by December 31, 2030.

Notice what the memo does not contain: any reference to quantum key distribution. The execution guidance is built entirely on NIST’s lattice-based and hash-based algorithms. The joint CISA, NSA, and NIST quantum-readiness factsheet takes the same path, focusing on inventory, vendor engagement, and PQC roadmaps. For federal contractors and the regulated industries that follow federal guidance, the QKD vs PQC decision has effectively been made for the compliance baseline.

Quantum Networking Isn’t Dead — Washington Is Funding It for Other Jobs

Here is the nuance most QKD vs PQC articles miss. The companion order, Executive Order 14413, Ushering in the Next Frontier of Quantum Innovation, directs agencies to prioritize research, testing, and evaluation of quantum sensing and quantum networking. Commerce is tasked with quantum-network-enhanced timing, Energy with networking for distributed quantum computing, and NASA with space applications.

The National Science Foundation describes the same direction in its June 2026 feature on quantum networks: linked sensors, GPS-free positioning, and pooled quantum processors, supported by regional test beds and quantum repeater research. So the federal message is consistent once you see it clearly. Quantum networks are a strategic technology for measurement and computation. For protecting data today, the government’s answer is post-quantum cryptography.

As FedTech Magazine’s 2026 federal QKD guide summarizes, CISA remains focused on the PQC migration and the DoD CIO’s post-quantum director has said QKD “does not meet our security requirements.” Infrastructure — dedicated links, endpoint hardware, and repeaters — remains the core obstacle for dispersed networks.

QKD vs PQC Side by Side: An Enterprise Comparison

Factor Quantum Key Distribution (QKD) Post-Quantum Cryptography (PQC)
Security basis Physics of photons; security depends heavily on hardware engineering Math problems believed hard for quantum and classical computers
Authentication None on its own — needs signatures Built in (ML-DSA, SLH-DSA)
Infrastructure Dedicated fiber or free-space optics; trusted relays over distance Runs on existing networks, devices, and clouds
Standards status Not approved for NSS; barred as a security mechanism in DoD NIST FIPS 203, 204, 205 final; HQC in progress
Compliance credit Does not satisfy federal PQC mandates Required under EO 14412, M-26-15, and DoW strategy
Scale and cost Point-to-point; high cost per link Scales like software; cost driven by inventory and upgrades
Best fit today Research, specialized dedicated links, defense-in-depth where policy allows Every enterprise WAN, data center, cloud, and endpoint

 

PQC has real costs too. Keys and signatures are larger — an ML-KEM-768 encapsulation key is 1,184 bytes versus 32 bytes for X25519 — which affects handshakes, constrained devices, and certificate chains. That is why crypto-agility, not a one-time swap, is the goal. Our certificate lifecycle management guide covers the operational side.

Where QKD Can Still Add Value — Honestly Scoped

The QKD vs PQC framing implies a winner-takes-all choice. It isn’t. Outside the Department of War’s systems and National Security Systems, an organization may choose to add physics-based key exchange as an extra layer — for example, between two owned data centers linked by dark fiber or wavelength services. Used this way, QKD is defense-in-depth on top of PQC, never a replacement for it.

Ask three questions before spending on it:

  • Is PQC authentication already in place on this link? If not, fix that first. Keys without authenticated endpoints are an open door.
  • Who controls the trusted nodes? Any relay where keys exist in the clear becomes a crown-jewel facility.
  • What happens during an outage? If an attacker can force the link down, your failover path must be PQC-protected, not legacy RSA.

A PQC-First Roadmap for Financial, Healthcare, and Insurance Networks

For most enterprises, resolving QKD vs PQC comes down to sequencing. We recommend a five-step path aligned with the federal timeline and our post-quantum cryptography migration playbook:

  1. Inventory your cryptography. Identify every protocol, certificate, key, and library — including in medical devices, branch appliances, and third-party SaaS.
  2. Protect data in transit first. Harvest-now attacks target traffic, so start with quantum-resistant tunnels for data in motion across your WAN and SD-WAN, and plan the exit from legacy links through MPLS replacement.
  3. Centralize key management. Crypto-agility depends on knowing where keys live and rotating them on demand. Exodus Key Management provides centralized generation, distribution, storage, and rotation.
  4. Secure stored data. Long-retention records — loan files, patient histories, claims — need protection for data at rest and database-level transparent encryption.
  5. Evaluate QKD last, and only where policy permits. Treat it as an optional layer on specific dedicated links once PQC coverage is proven.

How Exodus QRN Resolves the QKD vs PQC Dilemma

ibm/SEIMless spent two decades as a vendor-agnostic integrator before becoming an OEM, and that history shapes how Exodus QRN approaches quantum security. The platform is built around crypto-agility — the memory, compute, and flexibility to add post-quantum algorithms as standards mature — with quantum random number generation for high-quality key entropy and centralized encryption and policy management across physical, virtual, and cloud environments.

Where a client has the dedicated optical infrastructure and a policy environment that allows it, quantum key distribution can be layered in. But our design principle mirrors federal guidance: post-quantum cryptography carries the compliance and authentication load, and nothing depends on QKD alone. Paired with the Exodus NxtGen Firewall and zero-trust content security, Exodus QRN protects today’s traffic while keeping your options open for tomorrow’s quantum networks. You can read more about the architecture in our Exodus QRN infrastructure overview.

We believe security is ultimately about people: patients whose records must stay private for decades, families whose savings depend on trusted banking rails, and teams who deserve infrastructure that won’t be obsolete before it is paid off. Choosing well now protects all of them.

QKD vs PQC: Frequently Asked Questions

What is the main difference in QKD vs PQC?

QKD uses the physics of photons to share keys over dedicated optical links. PQC uses new mathematical algorithms, standardized by NIST, that run on existing networks and devices and resist quantum attacks.

Does the NSA approve quantum key distribution?

No. The NSA does not recommend QKD for National Security Systems and does not anticipate certifying QKD security products unless its limitations — authentication, hardware, trusted relays, validation, and denial of service — are resolved.

Can the Department of War or its contractors use QKD for security?

Not as a security mechanism. The DoD CIO’s November 2025 memo and the 2026 DoW PQC Strategy state that QKD and quantum networking will not be used to achieve confidentiality, authentication, or key distribution.

Does QKD satisfy Executive Order 14412 or OMB M-26-15?

No. The federal migration is built on NIST PQC algorithms. OMB M-26-15 does not mention QKD, and agency migration plans are due about 120 days after June 24, 2026.

Is quantum key distribution completely obsolete?

No. Executive Order 14413 prioritizes quantum networking for sensing, timing, and distributed computing. Where policy allows, QKD can add defense-in-depth on dedicated links, but only on top of PQC.

Where should an enterprise start with post-quantum security?

Start with a cryptographic inventory, then protect data in transit with quantum-resistant networking, centralize key management, and secure long-retention data at rest. Evaluate QKD only after PQC coverage is in place.

Contact Us | Our Blog | Our Services | See Previous Post…

Related reading: The Impact of Quantum Computing on IPsec · IBM and Cisco’s Quantum Networking Partnership · Why Quantum-Resistant Networking Is a Business Necessity · All ibm/SEIMless insights