Meta’s Muse Builds Hourly Person‑Pages for Contacts — Demand Verifiable Security Controls

Meta’s Muse Builds Structured Person‑Pages for People in Your Network

Researchers who obtained internal runtime files from Meta’s personal assistant, Muse, report that the system is designed to create and update a structured “page for every person in the user’s life.” Those findings, reported by WIRED on Oct 3, 2026 (Lily Hay Newman and Matt Burgess) and documented by researchers including Karan Joshi, describe an hourly process that compiles facts, relationship history, and suggested follow‑ups for family, friends, colleagues, collaborators and people you follow. Meta says Muse has been downloaded by “millions” of users, but it has not published precise counts for installs or how many people connect bank, messaging, or health services.

What the extracted files show

According to the runtime instructions researchers shared, Muse isn’t making free‑form notes. The files outline structured person‑pages with named sections such as:

  • Facts
  • History
  • The relationship
  • In common
  • Open threads
  • Strengthening

Documentation excerpts in the dump include guidance like a page may start “sparse” and then be filled out over time, and that Muse should use only the “evidence” available because invented details are worse than an empty page. The files list example items Muse might record: “Where they live, what they do, the threads that recur (the apartment move, the shared savings goal), ” and record “dates that matter” such as birthdays or anniversaries. History entries could include backstory like “the trip in March, the argument that got resolved, the milestone last week, ” and relationship notes could capture “how close they are, what it is built on, how they act with each other, and what it seems to need right now.”

Researchers say the system also generates actionable suggestions in a “Strengthening” section, things like “A reason to call, a date worth remembering, something they said to circle back on, a way to be there for them that matters.”

How Meta describes Muse’s protections

Meta provided contextual claims in response to the reporting. The company says each user runs in a dedicated virtual machine (VM) that stores user data and context and is inaccessible to other agents. Users can wipe memories or disconnect external services. Muse requests human confirmation before sensitive actions like sending an email or making a purchase. An audit log lets users review the agent’s activity and “future plans.”

“For any agent to be useful and actually help you achieve your goals, it needs to have context about you and those you interact with, ” Daniel Roberts (Meta spokesperson) told WIRED. “Muse gathers that based on public information and from what you’ve chosen to share, which is how it remembers the person who sent you an invoice is in fact the plumber who you previously hired to complete work in your bathroom or which flowers your spouse said they liked best.”

Meta also told WIRED that the files published by researchers were intended to be accessible for transparency. Researchers, however, report they were able to induce Muse to export internal runtime files via the chat interface; Karan Joshi documented this method and shared his findings with WIRED. Whether those exports were an intended transparency feature or an unintended exposure remains disputed and has not been resolved publicly.

What remains unclear, technical and policy gaps

  • Scope of deployment: “Millions” is Meta’s term; independent install and active‑use counts (including how many users connect banking, messaging, or health services) have not been published.
  • Where VMs run: Meta claims per‑user VMs, but it has not disclosed whether those VMs run on‑device, on Meta servers, or in third‑party cloud infrastructure, nor has it published cryptographic or attestation details that would let customers verify isolation.
  • Retention and deletion mechanics: Meta documents a wipe capability, but there is no public verification about whether wipes remove backups, derived inferences, or downstream models trained on aggregated signals.
  • Third‑party data and consent: It’s not clear how person‑pages treat non‑users who appear in a customer’s network, what notice those people receive, or how regulators’ requirements (for example, GDPR transparency and purpose limits) are being met.
  • Evidence‑only guidance in practice: The instructions ask Muse to avoid inventing details, but there is no public audit showing how the system handles ambiguous signals or whether it produces inferred assertions that exceed available evidence.
  • Intentional transparency vs. vulnerability: Researchers published runtime files (mouse.dev and other writeups), but the provenance and chain of custody for those artifacts, and whether they were intended to be exportable, remain open questions.

Why researchers and ethicists are concerned

The issue is not memory itself. Personalization and persistent context are what make assistants useful. The worry is Muse’s person‑pages act as an organized, hourly‑updated map of users’ social lives: who you’re close to, what’s unresolved, and cues on how to “strengthen” ties. Those are sensitive signals, and the structured format makes them an easy target.

“What it seemed like to me, from all these prompts, system skills data, and things that they’re feeding into Muse, is that they want to understand your relationships that you have with real people, ” says Karan Joshi. “They’re trying to know you like a friend, which is honestly pretty creepy.”

Carissa Véliz, associate professor at Oxford’s Institute for Ethics in AI, framed the core asymmetry: “We are giving AI systems much more information about us than we are getting information from them.” Miranda Bogen, director of the Center for Democracy and Technology’s AI Governance Lab, noted Muse “appears to have more emphasis on relationships and personal contacts than rivals’ systems, ” and warned that assistants are “actively soliciting users to plug their whole lives in, their emails, calendars, financial institutions, everything in order to be helpful assistance.”

Concrete misuse scenarios are easy to imagine. A bad actor that obtains person‑page data would have ready cues for social engineering, such as recent life events, unresolved loan requests, or relationship stressors. An advertiser or recommendation engine that sees “strengthening” prompts could weaponize them for persuasion. Non‑users profiled indirectly face privacy harms without notice or recourse. For example, a person‑page that records a recent layoff and an open thread about loan assistance would provide strong, targeted signals for a convincing scam.

What security and product teams should demand from vendors

Treat relationship‑aware agents as a new class of highly privileged data store. Vendor promises are not enough. Require verifiable evidence. Ask for:

  • Architectural attestation: A technical design document showing where per‑user VMs run (on‑device vs. cloud), the isolation model, and an attestation you can verify. If VMs run server‑side, require a third‑party audit of access controls and admin privileges.
  • Cryptographic guarantees: Details on encryption‑at‑rest and in‑transit, key management practices, and whether customer‑managed keys or hardware security modules (HSMs) are supported.
  • Deletion and provenance guarantees: Clear retention timelines, a specification of what “wipe memory” removes (backups, derived features, model artifacts), and logs proving deletion operations were executed.
  • Red‑team / security testing: A dated red‑team report showing whether internal files can be exported via user interfaces, plus remediation timelines and CVE disclosures for vulnerabilities tested.
  • Third‑party assurance: Recent SOC2/ISO27001 reports or independent penetration test summaries covering the exact features you plan to use.
  • Data provenance labeling: A way to see and export the source of each person‑page claim (public info vs. connected service vs. inferred) so downstream users can assess trustworthiness.

Contractual protections should include breach notification timelines, limits on marketing use of relationship data, and explicit restrictions on commercializing inferences about other people’s social ties.

Practical steps for users and executives

  • Limit connections: Don’t link bank, health, or enterprise systems unless you’ve verified and accepted the vendor’s retention and deletion proofs.
  • Prefer local or customer‑key modes: If the product offers on‑device processing or customer‑managed keys, prefer those options; they materially reduce risk if implemented correctly.
  • Use memory controls and audit logs: Regularly review what Muse records, check the audit log for “future plans, ” and perform targeted wipes for sensitive threads you don’t want persisted.
  • Treat Muse as a privileged endpoint: Include it in asset inventories, apply endpoint protections, and run threat models that assume person‑page data could be exfiltrated.
  • Limit actions on behalf of others: Avoid using the assistant to send payments or messages to third parties without manual review; those flows broaden legal and social risk.

Key takeaways, quick questions you should be able to answer

  • Does Muse build persistent profiles of people I know?

    Yes. Extracted runtime instructions and Meta’s documentation describe an hourly process that can create and update a structured “page for every person in the user’s life” with sections like Facts, History, In common, Open threads, and Strengthening (as reported to WIRED on Oct 3, 2026).

  • How were internal files revealed?

    Researchers, including Karan Joshi, reported they were able to induce Muse to export internal runtime files via the chat interface; Joshi shared his findings with WIRED. Whether those exports were an intended transparency feature or an unintended exposure has not been publicly resolved.

  • What protections does Meta claim, and are they verified?

    Meta says each user has a dedicated VM, users can wipe memories or disconnect services, Muse seeks human confirmation before sensitive actions, and an audit log records activity (statement via Meta spokesperson Daniel Roberts). Those are company claims; Meta has not published the technical attestations or independent audits necessary for external verification.

Where this sits in the bigger picture

Persistent memory and richer context are central to useful AI assistants. They let tools follow up on promises, remember preferences, and surface timely suggestions. But when memory shifts from describing a single user to cataloguing relationships and recommending ways to influence them, the privacy stakes rise sharply. Meta’s existing access to vast social data makes this feature politically and legally sensitive in ways a generic to‑do list is not.

For leaders, the practical test is simple: if a feature maps other people’s lives and proposes actions to influence those relationships, treat it as high utility and high liability. Demand verifiable controls, independent audits, and contractual protections before allowing it near corporate data or executive accounts. Regulators and privacy advocates will follow fast; being proactive is better than reactive.

0