Meta Muse Publishes Signing Keys. What Should Sites Trust?

An AI agent can identify itself correctly and still make a request your application should reject.

That is the practical issue behind signed agent traffic. On November 11, 2026, we checked Muse’s public HTTP message signatures directory. The HTTPS endpoint returned HTTP 200, the directory content type, and two Ed25519 public keys.

That is concrete evidence site owners can inspect themselves. It is also a narrower finding than “all Muse traffic is now identifiable.” We did not capture and verify a live Muse browsing session for this article, measure its signing coverage, or establish when the directory first appeared.

Our recommendation: keep verified identity, observed behavior, and application permission as separate pieces of evidence.

What we checked on muse.ai

The endpoint is:

https://muse.ai/.well-known/http-message-signatures-directory

Our response contained a JSON Web Key Set with two entries. Both declared kty: "OKP" and crv: "Ed25519", alongside public key material and a key identifier. The response used application/http-message-signatures-directory+json.

You can inspect the current response without an account:

curl --fail --silent --show-error \
  https://muse.ai/.well-known/http-message-signatures-directory \
  | python3 -m json.tool

This command inspects a directory; it does not authenticate a visiting bot. Keys can rotate, so a later response may differ. We have deliberately left key values out of suggested application rules: a pasted key can become stale, and a key identifier alone is not a valid signature.

Meta describes Muse as a personal agent running on a dedicated VM with its own browser. That architecture makes the distinction useful: your site can receive browser activity performed for a person without that person directly operating the browser you observe.

A signing identity is more useful than a copied name

A client can put a recognizable name in a user-agent string. It can also send a header claiming a familiar signing identity. Neither text field authenticates the sender.

HTTP Message Signatures, RFC 9421, defines how to sign selected components of a message. Verification checks the signature over those components using the relevant key. The verifier’s requirements determine which parts of a request must be covered and which signatures are acceptable.

For bot identity, Web Bot Auth adds a profile and key-discovery workflow. It uses IETF drafts built on HTTP Message Signatures. It should not be described as though the entire bot-authentication ecosystem were already one finalized RFC.

The important operational distinction is between a claimed identity and a signature validated under your verifier’s trust policy. An arbitrary domain publishing a key does not become Meta because its requests contain the word “Muse.”

What a valid signature still cannot tell you

Even an authenticated operator identity leaves several application questions open:

A signed product-page request might fit your public browsing policy. The same identity repeatedly attempting coupon redemption deserves a different decision. A signature does not replace account authorization, payment checks, or limits on expensive endpoints.

Unsigned requests also need their own category. Without evidence about signing coverage, “no signature” is an absence of verified identity, rather than proof that the request is an impostor.

A practical workflow for signed and unsigned AI traffic

Start with observation before changing broad access rules.

1. Record the verification outcome. Keep claimed, verified, invalid and absent identities distinct. Preserve the verifier’s reason and version so an investigation can distinguish an expired signature from a missing one.
2. Validate at a trusted boundary. Use a maintained verifier and its documented profile. Check required signed components, validity windows and replay protections. Never fetch arbitrary client-supplied key URLs without destination restrictions and resource limits.
3. Carry trusted results into the application. If your edge forwards an identity result, prevent direct-origin access or client-supplied headers from forging it. Forward the minimum context your application needs.
4. Join identity to actions. Compare requests to public pages with form submissions, login attempts, cart changes and order activity. Keep sensitive form values, credentials and payment data out of investigation logs.
5. Apply policy to the action. A verified operator can receive a specific browsing policy while account and transaction controls continue to apply. Investigate unsigned traffic using other available evidence.

For transport context, our JA4 investigation guide explains how to collect and interpret fingerprints without treating a hash as a client identity. Our free JA4 decoder helps read the format; it does not authenticate Muse.

Where WebDecoy fits alongside Cloudflare

Cloudflare can provide controls and identity verification at the edge. WebDecoy adds a place to investigate the bot activity your installed sensors observe and understand what that traffic did on your site.

Use the integration appropriate to your coverage: browser instrumentation observes activity that executes it; server or edge collection is needed for requests that never run JavaScript. Inspect the available detection evidence alongside session and application context before deciding on a response.

Keep AI crawler activity separate from referral visits, too. An agent fetching a page is not evidence that an AI answer cited you or sent a customer back.

This article’s directory check is not a claim that WebDecoy verified a Muse session or can name every Muse visit. It provides a concrete starting point for asking better questions of your own traffic.

Install WebDecoy to see the bot traffic your integration observes, then investigate the requests and actions behind it. Already using Cloudflare? Keep those protections in place and add the visibility you need inside your application.