Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can Meta Muse See Your Logged-In Accounts?
Where Meta Muse holds a session, it holds the page: on a connected business account it reads the connected assets, the people with access and the payout details the account screen renders, even though Meta's pages say it cannot see stored passwords or payment methods. Ask what the model receives on each account page before you connect another one.
A business account page is where an organization writes down its reach: the ad accounts and Pages it owns, the people who administer them, the tax identifier used for verification, the bank account that receives payouts and the card that pays for ads. An agent signed into that page reads all of it, and Muse works inside the accounts a person connects, on a computer Meta runs. The gap between teams experimenting with agents and teams scaling them is where the control question sits (What Is the PII Wall?). A shared login connected to save an hour a week hands the agent the view an administrator has, and that view decides where money lands. That Muse can act on an account is documented; what the page shows it is the open part, and the page is the business's own record under its own login. For example, a payouts page renders the full account and routing number in two fields, and those fields read the same to a clerk and to a model that never asked for them.
Key findings
- For Muse to be safe on a business account, the values on the page would have to be replaced with consistent tokens before the model reads it, so the payout account renders as ACCT_001 and the real number is released only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment and permission change, and a record of what the model received (What Should a Meta Muse Security Review Check?).
- Meta's Muse pages describe an approval gate, an audit trail and credentials the agent uses without seeing, and none of them describes a control that replaces the values a business account page renders before the model reads them (Meta, Newsroom, 2026).
- The newsroom page states that "Muse runs on its own dedicated computer in the cloud" and that "Muse checks with the person before sensitive actions like sending an email or making a purchase", which bounds where the agent works, not what the page shows it (Meta, Newsroom, 2026).
- The same page says users can review a full audit trail and that Muse cannot see stored passwords or payment methods though it can use credentials stored for it, which covers a saved login and leaves the payout details in view (Meta, Newsroom, 2026).
- Meta's agent guidance holds that "agents must satisfy no more than two of the following three properties within a session", and a business account page supplies all three: content from a connected asset, sensitive payment data, and a change of state (Meta, Rule of Two, 2025).
What can Meta Muse read on a logged-in business account page?
The record is a business account page, the settings screen an administrator opens to see what the business owns. Muse is one of Meta's agent surfaces, and Meta Business Agent answers customers on WhatsApp, Messenger and Instagram for over a million businesses (What Are Meta Business Agent's Privacy Risks?).
Muse reaches it through the session a person gives it. "Muse runs on its own dedicated computer in the cloud", so the agent works in a browser of its own, and the session it holds is the business's own (Meta, Newsroom, 2026). Where it has a session it has the page: every field the screen draws arrives in the model's context, including the ones nobody meant to show.
| Block on the business account page | What the screen shows | What the session returns |
|---|---|---|
| Connected assets | Every ad account, Page, Instagram profile and WhatsApp number, with its identifier | The asset list, and which accounts the person can spend from |
| People and roles | Names, emails and the role each person holds | Who can add an administrator, and who can remove one |
| Business verification | Legal name, registered address, tax identifier | The identifiers a support agent would ask for |
| Billing and payouts | Card on file, payout bank account, routing number | The account and routing number the page renders |
Meta draws a line at the password: Muse cannot see stored passwords or payment methods, though it can use credentials stored for it (Meta, Newsroom, 2026). That is custody for two values: the agent reaches the account without the password, and spends without the card number. The session remains, and it opens every other field.
Muse is one of the 15 AI agents reviewed. That line holds across the 15: 9 describe keeping passwords or credentials from the model, and none describes protecting the customer data on the screen (Do AI Agents Ask Before Making a Payment?).
A written rule does not narrow that. Agents "need insight into where things live, what rules to follow, and how to implement changes", and they take it from the page in front of them (Columbia DAPLab, 2026).
What do the vendors themselves say?
Meta documents the Muse design on a launch page and an agent security post. Both put the control at the action, and neither describes a change to the page before the model reads it.
| Dimension | Meta Muse, per its documentation | What a buyer should verify |
|---|---|---|
| Where the agent runs | "Muse runs on its own dedicated computer in the cloud" (Meta, Newsroom, 2026) | Whether that computer signs into the business's accounts |
| Passwords and payment methods | Cannot see stored passwords or payment methods, though it can use credentials stored for it (Meta, Newsroom, 2026) | Which other values on the page the model receives |
| Approval | "Muse checks with the person before sensitive actions like sending an email or making a purchase" (Meta, Newsroom, 2026) | Which actions count as sensitive, and who the person is |
| The record | A user can review a full audit trail (Meta, Newsroom, 2026) | Whether the trail shows the screen the model read or only the action |
| Session properties | "agents must satisfy no more than two of the following three properties within a session" (Meta, Rule of Two, 2025) | Whether the connected account session carries all three |
The last row is Meta's own rule for a session, and a business account page read by an agent that can then change a payout destination carries all three (Meta, Rule of Two, 2025).
Meta's safety write-up adds a Secure VM for each user, a Sentinel that approves every network egress, surrogate credentials and an activity log, with the agent reading page content within its permitted access (What Would an Enterprise Version of Meta Muse Need?). Those controls govern where the agent runs, not what the page shows.
What happens when a page Muse reads carries a hidden instruction?
A connected asset is a page the business does not control. A catalog feed, a Page bio, a supplier's invoice in a shared drive and a comment on an ad all reach the model as text, and any of them can carry an instruction the person never wrote, addressed to the agent, not the reader.
The measurement on web agents is blunt. Against the WASP benchmark, agents begin following an injected instruction in up to 86% of cases, though "even state-of-the-art agents often struggle to fully complete the attacker goals" (Evtimov et al., WASP, 2025). The same research group measured privacy leakage separately and found that web agents "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., AgentDAM, 2025).
Put the findings beside the session rule and the exposure is arithmetic: untrusted input from connected assets, sensitive data from the account page, and the ability to change state, in one session. An injection that lands does not need a password; it can ask the agent to point the payout account at another bank, and the agent has the page, the permission and the session to do it.
An approval gate narrows that. A person asked before a payout change can refuse, and the trail records the refusal. The gate does not change what the model read to prepare the change, and a page already read stays in the context for the rest of the run.
What should a security team ask for in writing?
The first question is about the screen: what does the model receive from the rendered page, field by field, and which fields does the vendor replace before the model reads them? Ask for the field list and the values as they arrive.
Then the account. Google's guidance says to "Use the super admin account only when needed", the right rule for an agent signing into a business's systems (Google, 2026). Connect a dedicated business account with the access the task needs, not the one that can change ownership.
Then the approval. Meta's page says Muse checks with the person before sensitive actions, and the question is who that person is and whether the check can be switched off. On other agents it varies: for Breeze Agents "The default is that approval is required," though users can switch it off and automatically triggered agents run without approval (AI Agent Index, 2026). An employer's access to that trail is not described in the pages reviewed (What Are the Risks of Using Meta Muse for Work?).
Intuit's instructions for entering vendor bank details say that "You'll need the account number for the vendor" (Intuit, 2021). If the page renders the number for the clerk, it renders it for the model, unless something replaces it first. OWASP's Top 10 for agentic applications lists the critical risks and covers the rest (OWASP, 2025).
What does a governed environment change?
A governed environment moves the control to where the page is drawn. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the payout account is ACCT_001 for the whole run, the tax identifier is TAX_001, and the connected assets keep placeholders of their own. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. The model works the task on the placeholders. Real values resolve only at an approved destination, at the moment of an approved action, so the number reaches the payout form the approver confirmed and no other page.
Two consequences follow for a business that runs an agent on its accounts. The first is that exposure stops depending on the page: a connected asset added last week, a billing block nobody reviewed and a page that did not exist at policy time all arrive as tokens. The second is that the record changes: a named person approves each payment and permission change, and every screen as the model saw it, every action and every approval goes to a record the organization can export.
The scope is the rendered page; a credential the agent reads from a shell, a file or an API call is outside it, and so is anything the agent learns from a source that never renders. The two designs are compared on the same payout record in RedactSure vs Meta Muse: 2026 Comparison & Alternative.
What the record shows
The control sits at the screen, before the model reads it: values replaced with consistent tokens for the run, real values released only at the approved destination, a named person approving every change, and a record of the screen as the model saw it. Meta's reach is documented, and so is its limit. Muse works the accounts a person connects, on a computer Meta runs, asks before sensitive actions and uses stored credentials without showing them. What the pages reviewed do not describe is any change to the page before the model reads it, so the payout account number, the tax identifier and the asset list arrive as values. That answers the title: the page Muse can read is the business's own account data. Name one connected account, open the page an agent would open, and write down the fields it draws; then ask which the model receives and which the vendor replaces. The list is short, and it is the test.
Methodology and limitations
This page rests on Meta's Muse newsroom page and its Rule of Two post, a web-agent security benchmark and a privacy leakage study from Meta's research group, the AI Agent Index entry for Breeze Agents, Google's administrator guidance, OWASP's agentic Top 10, Intuit's help page and a Columbia DAPLab post. Sources were read as of October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where a product applies its control, and quotations keep the vendor's or the study's wording.
No product named on this page was tested for it, and "not described in the pages reviewed" means the recorded pages do not state it. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The business account page is a record type, not an organization. Determinations about whether a workflow meets a contractual or regulatory requirement belong to counsel, assessors and the organization's compliance officers. Nothing replaces a pilot of one workflow on your own screens.
Frequently asked questions
Can Meta Muse see my logged-in accounts?
Yes, on any account it has been given a session on. Meta's page says Muse runs on its own computer in the cloud and can use credentials stored for it, and an agent working inside a signed-in session reads the page that session opens. On a business account page that includes the connected assets, the people with access, the tax identifier and the payout bank details. The page and the vendor's description are the evidence, and there is no third version of the account.
Does Muse need my password to read a connected account?
No. Meta says Muse cannot see stored passwords or payment methods, though it can use credentials stored for it. The password stays out of the model's context, which is the right design for that one value. The session it creates is a different object: it opens the account, and the pages behind it render to the model like any page. A saved login protects the password and says nothing about the payout number two clicks away.
Which accounts should I connect to Muse?
Only the ones the task needs, and never the account that can change ownership. Google's administrator guidance says to use the super admin account only when needed, and the same discipline applies to an agent that signs into a business's systems. A dedicated business account with a narrow role limits what an injected instruction can reach. It does not change what the page shows, so pair it with a control at the screen.
What does the model receive on a business account page?
The page as the browser renders it: the asset list with identifiers, the names and roles of people with access, the legal name and tax identifier, and the payout account and routing number. Meta's description does not say the model receives a reduced version, and the approval it documents comes after the reading. A field the page draws for a clerk is a field the model can read, whether or not anyone intended it.
Who approves an action Muse proposes?
The person using it, on Meta's account: Muse checks with the person before sensitive actions like sending an email or making a purchase. That is a real gate, and it stops an action the person would refuse. It is also a gate the person owns rather than a policy the organization sets, and it says nothing about what the model read before it proposed the action. Ask who that person is on a shared business account, and what that person can see.
What record shows what Muse saw?
A full audit trail the user can review, according to Meta's page, which records what the agent did. What the model read is a separate artifact, and the page does not describe one. A record of the screen as the model saw it, field by field and per run, is what a security team can query after an incident. Ask for the screen as well as the action, and ask who exports it.
How RedactSure Keeps a Business Account Page Out of the Model's View
The controls reviewed above decide what an agent may do, while the page it reads still renders the payout account. Meta's page says Muse "checks with the person before sensitive actions like sending an email or making a purchase", a decision at the action (Meta, Newsroom, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the business account page under the session a person connected, and the model reads the payout account number, the routing number, the tax identifier and the administrator roles. Inside: the same page renders ACCT_001, ROUTING_001 and TAX_001, the agent changes the payout destination on them, and the real number reaches the payout screen when the approver approves.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A payout account number on a business settings page is the value a finance team asks about first. Bring one connected account and see, with test values, what the model reads and who approves the change. Book a demo