Meta's Muse code reveals a Trusted Network with invites and safety codes

RUNTIMEWIRE INVESTIGATION — Original analysis

Original reporting by RuntimeWire, based on documents, reverse engineering.

Why it matters

A connection system could let personal agents coordinate across users. The names in Muse's web code outline invitations and approvals, while leaving the data-sharing permissions and working behavior unresolved.

Reporting record

Meta's Muse web code contains references to a feature called Trusted Network, with a contact picker, invitations, connection-request reviews and safety-code screens. The names outline a system for connecting people inside Meta's personal agent, although the public files do not establish what those connections allow.

RuntimeWire found the references while inspecting 69 JavaScript files delivered by muse.ai on October 1st. They appear across catalogs for user interactions, screen views, application surfaces and logging. The interaction catalog and screen-view catalog describe several steps in the same connection flow.

Instinct has already announced a working version of the underlying idea. In a September 13th post, founder Noah Shinn said its Trusted Person network was available to all Instinct users. He described assistants finding meeting times, coordinating dinner for 10 people and adjusting recurring tennis sessions when someone's calendar changed.

The potential competitive development is Meta building a comparable connection system into Muse. Agent-to-agent coordination is an inference from the Muse references. We did not recover the implementation of those screens or observe two Muse agents communicating.

The connection flow inside the code

The clearest clues are the actions Meta has named. The interaction catalog includes adding a person, choosing a contact, accepting an invitation, canceling an invitation and disconnecting. It also contains chat_trusted_network_connection_request_review_click, placing a connection-review action inside chat. Those identifiers are present in the captured JavaScript.

The screen-view catalog names a Trusted Network overview, individual person views, invitation screens, an invite-link view and connection requests. A separate surface catalog names settings_trusted_network_contacts. The logging catalog includes Trusted Network settings and chat connection requests.

That gives the finding a fairly specific shape: people choose contacts, exchange invitations, review a connection and can later remove it. The code also names a safety-code decision, retry and close action, with corresponding safety-code and safety-code-access screen views. The interaction and screen-view catalogs are the evidence for those steps.

Safety-code terminology deserves attention, but the files do not explain its meaning. We cannot establish whether it verifies cryptographic identities, requires a human to compare a code, or serves some other purpose. A screen name cannot answer those questions.

These are instrumentation declarations. Such catalogs can retain experiments, abandoned interfaces or features unavailable to most users. The references establish that Meta distributed this vocabulary in its web client. They do not establish a launch date, an enabled account flag or a working service.

Instinct already gave agents a way to coordinate

The Muse traces arrive in a market where another personal agent has publicly described connections between users' assistants. Instinct's announcement ties its Trusted Person network to practical coordination, with users naming the people their assistant may contact. Its founder's earlier introduction explicitly describes an Instinct-to-Instinct communication protocol.

Muse's references are consistent with a permissioned contact system that could support similar coordination. The captured files do not establish that Muse follows Instinct's design, supports the same tasks or communicates with another company's agents. They also cannot date when Meta began work on the feature. Similar naming provides no evidence of copying.

Meta has already expanded the ways Muse can interact with outside services. RuntimeWire covered developer-built connectors on September 18th and the small-business expansion on September 29th. Those are public releases and supply context for the connection traces.

If Meta uses Trusted Network to let agents coordinate, it will need to explain the permission attached to each relationship. Sharing a free time slot is different from exposing a calendar's contents. Planning dinner could involve preferences, location and budget. These are examples of decisions a connection system would have to handle, rather than behaviors this inspection observed.

The browser also contains Confidential VM recovery code

The same inspection recovered executable client helpers for Confidential VM enrollment, recovery and reconnection. This finding concerns implementation detail for an announced feature: Meta described Confidential VM on September 8th, saying it was in use with a small tester group and planned for broader delivery later in the year.

The recovery asset checks for a 32-byte recovery secret, imports a non-extractable WebCrypto key and clears a temporary copy of the secret. It uses HKDF, a key-derivation mechanism, with a VM-specific label. The label contains hatch:rv-luks:v1:. Meta's security documentation identifies Hatch as Muse's internal code name.

That asset stores a CryptoKey in a browser database named hatch-cvm-credentials. Its storage and retrieval helpers check the active owner and session binding, rejecting or removing credentials that fail those checks. It also defines enrollment, connection and reconnect states. These are implemented functions, giving us more concrete evidence than the Trusted Network catalogs.

A separate telemetry policy helper suppresses the inspected client telemetry path for confidential sessions and several related states. That control does not establish that every part of Muse stops collecting telemetry. Nor can browser-side recovery helpers verify Meta's server-side encryption or confidentiality claims.

A restricted privacy transport and other feature traces

The public assets contain an OHTTP transport helper, alongside a configuration endpoint and relay endpoint hosted on Fastly. Its request validator requires credentials to be omitted, referrers suppressed and redirects rejected. It restricts endpoints, methods, headers and media types. We did not observe relay traffic or establish which Muse feature invokes this transport.

Other references describe shared-agent rooms, invitations, member management and revoked permissions. Shared Agents already had a reporting record: TestingCatalog demonstrated a creation flow on September 10th. The current route catalog and interaction catalog supply additional vocabulary; they do not demonstrate a new release or a connection to Trusted Network.

The catalogs also include an /edit-space/:slug route and events for selecting an element, submitting an annotation and changing or resizing a viewport. Those names suggest visual editing of generated artifacts. We recovered declarations, rather than an operational editor, in the route and interaction assets.

What the advertising code establishes

Muse's web assets also implement advertising measurement components for Meta Pixel, Google Ads, Campaign Manager, DV360, TikTok and Snapchat. The inspected measurement code refers to page categories, paths, signup events and advertising click identifiers. It checks consent and VM telemetry policy; some components can additionally require a confirmed standard VM.

We did not capture network traffic showing which vendors received requests, and this inspection provides no evidence that conversations or VM file contents were sent to advertising systems. Meta's security explanation says Muse conversations and VM data are excluded from its ad systems. Finding measurement code does not establish a breach of that promise.

How we investigated

I fetched the public Muse pages and followed the JavaScript URLs they referenced, then the additional chunk references inside those files. The capture ran from 6:56 p.m. to 7:03 p.m. Chicago time on October 1st and produced 69 JavaScript files totaling 3,960,274 bytes. We indexed 43 evidence locations with source URLs, SHA-256 hashes, exact offsets and surrounding code.

We checked the findings against Meta's announcements and earlier reporting, including Instinct's network announcement and TestingCatalog's Shared Agents report. Memory-import events also appear in the build; previously posted community runtime documentation already describes that feature. We did not independently authenticate that community snapshot and used it only as prior-disclosure context.

The analysis used public files and a logged-out browser observation. Requests to /shared-agents and /get_cvm returned HTTP 401. Four source-map URLs explicitly referenced by the acquired code returned 404. We did not bypass access controls or test a signed-in account.

This is one dated capture. We have no earlier web build to compare against, so it cannot tell us when the Trusted Network references were added. The retained sources and evidence index allow readers to check the code findings independently, even if Meta replaces the live assets.

Muse's code gives us the names of the connection steps. The permission model remains unresolved: what does accepting an invitation allow another person, or their agent, to learn and do?