Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can Manus See in Your Cloud Browser Session?
Manus shows you the run as it happens, and its help page does not say what the model receives from the page it works. Treat the live view as a window on the agent's actions, and ask what the model read on the screen before you connect an account.
A sales operations lead hands Manus a renewal task on one CRM account page: open the account, confirm the renewal date, log the call. She keeps the live view open in a second tab and watches the cursor cross the page from her own desk. The page carries the customer's name, the contacts and their numbers, the open deal and its amount, and the billing contact finance uses.
The evidence is narrower than it looks. Manus's help page states that "You see everything Manus is doing in real-time" and sets out encrypted sessions, a browser instance for each user and a Take Over step for verifications, terms about the session rather than about what the model reads (Manus, 2026). The same page does not say what the model receives from a logged-in page, and it does not mention cookies. A person can watch every move and still not know which values entered the model's context.
Three things decide what a run exposes: the values the model receives from the rendered page, the person who approves an action, and the record that survives the session. Manus describes the container, and on each the help page stops before the answer.
Key findings
- For the live view to bound what the model reads, the values on a rendered page would have to be replaced with consistent tokens before the model receives the screen, so a person watches the run while the model works on CUST_014, DEAL_002 and ACCT_002 (What Is Render-Layer Tokenization?).
- It would also require a named person approving each consequential action on the account page and a record of what the model received; the research design for such a check puts a typed Action Certificate in front of every governed action, accepted by a checker outside the planner (Kadyrbek et al., 2026).
- The Cloud Browser help page describes the session around the run: it states that "All browser sessions are encrypted" and that "Each user has a separate, isolated browser instance", and it does not state what the model receives from a logged-in page (Manus, 2026).
- The same page says "You see everything Manus is doing in real-time" and reserves Take Over for "verifications (CAPTCHA, SMS codes, etc.)", a view of the run rather than a gate on a record change (Manus, 2026).
- Browser Use's real browser documentation describes the alternative, an agent attached to a browser where "you are already logged into your websites", with "login sessions, cookies, and extensions" preserved (Browser Use, 2026).
- A systematic review of automation bias found that over-reliance "has been studied in various academic fields", the tendency a live view invites when the watcher treats the stream as the check (Goddard et al., 2012).
What does the live view show, and what does the model receive?
The live view is a stream of the browser Manus runs. A person opening it sees the surface anyone sitting at that machine would see: a page loads, the cursor moves, a field is filled, a button is pressed. For the renewal task, she watches the account page open, the renewal date change, and the call note appear at the bottom of the activity list.
That is a view of actions. The model's input is a different object, and the help page does not describe it. Nothing says whether the model receives the page as text, a screenshot, a structured extract of the fields, or a mix, and nothing says whether a field hidden from the person is hidden from the model. On a CRM account page, the billing contact, the renewal history and the account owner sit beside fields a person never opens.
For a buyer deciding whether to connect an account, the question is which channel is documented. The session statements point at who can reach the browser, and none describes the values that reach the model (Manus, 2026). A live view a person can watch and interrupt is worth having; it is also compatible with a model that reads every field on the screen and keeps it. What Is Render-Layer Tokenization? draws the line between a control on the session and a control on the screen.
What does Manus record from a cloud browser session?
The help page makes four promises a reviewer can use: "All browser sessions are encrypted", "Each user has a separate, isolated browser instance", "You control which accounts Manus can access" and "You can log out or clear sessions anytime" (Manus, 2026). None states what is written down about the run, where it is kept, for how long, or whether the customer can export it. The page also does not mention cookies, which outlive a click on logout.
A record of the session is not a record of the model's input. The first answers where the browser went and when it stopped; the second answers which values the model held. For the renewal task, a session record can show the account page opened and the date changed, not whether the customer's direct number reached the model.
Manus is not among the 86 AI security and data protection products reviewed, and in that set 36 describe recording what the model was shown, the record in each case consisting of prompts, conversations or request payloads captured at the product's own gateway rather than the rendered screen an agent read (How Many AI Security Products Control What an AI Agent Sees?).
The research on agent automation treats that gap as structural. DAPLab argues that "Agents turn every layer of the stack into a semantic quality problem" and that "trustworthy agent automation cannot be solved at a single layer of the stack" (DAPLab, 2026), which puts a session log at one layer and the model's input at another. The cookie survives a logout, and Can a Browser Agent Read My Session Cookies? sets out how an agent attached to a profile reaches it.
What do the vendors themselves say?
Manus's Cloud Browser page is specific about the session and silent on the model, and every quote in the table is from that page (Manus, 2026).
| Dimension | Manus, per its documentation | What a buyer should verify |
|---|---|---|
| Session | "All browser sessions are encrypted"; "Each user has a separate, isolated browser instance" | Per user or per task |
| Accounts | "You control which accounts Manus can access" | Which account a run uses |
| View | "You see everything Manus is doing in real-time" | A record a reviewer can query |
| Verifications | "Take Over lets you temporarily control the browser when Manus encounters verifications (CAPTCHA, SMS codes, etc.)" | A stop before a payment or change |
| Model input | The page says nothing about what the model receives from a logged-in page | One screen, field by field |
The last row is the one the page cannot fill. Encryption and isolation describe the container, and a container does not decide which fields enter a model's context. Two other vendor pages show the range. Google's Workspace guidance lists "Identifying and redacting external image URLs and suspicious links" as one layer, which covers links and images rather than the values a field carries (Google, Prompt injections, 2026). Intuit's reconciliation article walks a person through the last statement ending date and an ending balance "from your account statement", a page written for a person at the screen (Intuit, 2026). Google's administrator guidance raises the account question: "Use the super admin account only when needed" (Google, Security best practices, 2026).
What can you approve while the run is happening?
The approval the help page describes is a handover for a verification: "Take Over lets you temporarily control the browser when Manus encounters verifications (CAPTCHA, SMS codes, etc.)" (Manus, 2026). That step exists because a site asked for proof that a person is present. It is not described as a review of the action that follows, and the page describes no confirmation before a record change, a send or a payment.
A sales operations lead who takes over for an SMS code has proved she is present; she has not approved the renewal date change or the call note. If the model has read a wrong value from an earlier page, or a page has carried instructions the person never read, the handover still completes.
A control that approves the action has to sit outside the model and before the effect. The research design for an action gate puts a typed Action Certificate in front of every governed action, accepted by a checker outside the planner, and requires proof for irreversible actions (Kadyrbek et al., 2026). A CAPTCHA handover verifies a person to the site, not the action to the account holder. Why Should Submitting a Credential Require Its Own Permission? sets out a single submission behind its own approval.
What does a CRM account page expose to the model?
The record for this page is a CRM account page, the page a sales team opens fifty times a week. It carries the account name and owner, the contacts and their numbers, the open deal and its amount, the renewal date, and the billing contact finance uses. On some accounts it also holds a verification record such as Persona's KYC output, which "enables organizations to verify an individual's government-issued ID along with a selfie liveness check" (Persona, 2026).
CRM vendors document how much of the page reaches an assistant. HubSpot requires a Super Admin to turn on the CRM data switch before Breeze agents can use CRM records, and its withholding covers custom Sensitive Data properties (Does HubSpot Breeze Expose Customer Information?). Microsoft's October 2026 announcement describes "30 new pre-built CRM skills for Copilot Cowork" and does not list which records or fields they read (How Do You Protect Customer Data When Dynamics 365 Copilot Agents Work CRM Records?).
The account page is also where the wall stands: the work needs the record, and security will not let a model see it (What Is the PII Wall?).
What does a governed environment change?
A governed environment changes the object the control acts on. Instead of watching a session and trusting that the model reads what the person read, it replaces the values chosen by policy with consistent tokens at the point the screen renders. On the CRM account page the account becomes CUST_014, the open deal DEAL_002 and the billing account ACCT_001, and the model works the renewal from those tokens. Real values resolve only at the approved destination, at the moment a named person approves the action. Every screen the model saw, every action and every approval goes to a record the customer exports to its own systems.
For the question here, the live view stops being the only account of the run. A person can still watch, and the record answers what the view cannot: which values the model held on each screen, and who approved the step that released one. The comparison for this browser sets the two controls side by side (RedactSure vs Manus: 2026 Comparison & Alternative).
The enterprise browser category governs the acts a person takes on data, and reading is not an act it intercepts (Enterprise Browser or Render-Layer Tokenization?).
What the record shows
A control on the screen and a control on the session answer different questions. The screen control decides which values a model may hold, replaces them before the page reaches it, releases a real value only at an approved destination, and writes screen and approval to a record. The session control decides who can reach the browser, keeps instances separate, encrypts the session, and lets a person watch and take over. The help page documents the second in detail and leaves the first unstated (Manus, 2026), so a live view can be honest and still tell a reviewer nothing about the model's input. The test for a team connecting a CRM account is to name one account page, one task and one value that must not enter the model, run the task with the live view open, and compare three lists: the fields on the screen, the fields in the model's input, and the approvals with a name against each change. Where the second and third cannot be produced, the run is governed by the session and not by what the model reads.
Methodology and limitations
This page rests on vendor documentation from Manus, Browser Use, Google, Persona and Intuit, a review of automation bias, a Scientific Reports paper on proof-carrying agent actions, and the Columbia DAPLab's page on trustworthy agent automation. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries its date. Public documentation read in full gives a sound view of where each product applies its control.
The products are described from documentation, and none was tested for this page. Where a vendor does not state something, the pages reviewed do not state it, which is not evidence of what the product cannot do. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a CRM account page, and not an organization.
The Manus help page is a consumer article rather than a security whitepaper, so its silence is a limit of the document. Determinations about whether a workflow meets a contractual, privacy or regulatory requirement belong to counsel, assessors and the organization's compliance officers.
Frequently asked questions
What can Manus see in a cloud browser session?
Everything the browser renders on the pages a run opens, and the session that carries them. Manus's help page says "You see everything Manus is doing in real-time" and that each user has a separate, isolated browser instance, so the run is visible from the first page to the last (Manus, 2026). What the model receives from those pages is not stated, which leaves the more important half of the question open for a buyer.
Does Manus keep a record of what the model read?
Not from the pages reviewed. The help page describes encrypted sessions, isolated instances, an account list and logout, and it describes no export of what the model read. A session record answers where the browser went and when it stopped. What the model held on the account page is a separate record, and the help page leaves it undescribed. Ask a vendor for that record by name, with a retention period and a format.
Can I approve an action before Manus takes it?
Only where a site asks for a verification. Take Over returns control for a CAPTCHA or an SMS code, which proves a person is present to the site. The page does not describe a confirmation before a record change, a send or a payment. For a CRM task, assume the change lands without a gate unless the vendor shows you one, and put the approval in the workflow before the agent starts.
What does the model receive from a logged-in page?
The help page does not say. It documents the container around the session and says nothing about whether the model receives page text, a screenshot, a structured extract or a mix, and it does not mention cookies (Manus, 2026). The fields the page renders are the candidates, and on a CRM account those include the contacts, the deal amount and the billing contact. The vendor's answer decides how much of that list is exposure.
Does the live view limit what the agent can read?
No. The live view shows what the browser is doing and lets a person take over for a verification, and it does not change which values render on the page or what the model receives from them. A limit on reading is set where the page is rendered and where the model's context is built, not at the window a person watches. A team that wants one has to ask for it at that layer.
What should a security team ask for in writing about the screen?
One field-level answer per screen: which values the model received, whether they arrived as values or tokens, where a real value was released, who approved the release, and what record shows the screen as the model saw it. Ask for it on a page that carries customer data rather than on a diagram, and treat an undocumented answer as unanswered. That written answer is what an assessor can set against a pilot of the same workflow on the same account page.
How RedactSure Keeps the Account Page Out of the Model
Watching a run tells a person what the agent did, not which values it held, and the session controls reviewed here stop at the container.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the model receives the customer's direct number and the billing contact as the account page renders them. Inside, the page renders CUST_014 and ACCT_001, the real number reaches the billing form on a named person's approval, and the screen the model saw and the approval land in the record.
RedactSure is deploying now with enterprise and government customers. Manus's page reserves Take Over for "verifications (CAPTCHA, SMS codes, etc.)", a handover for presence rather than an approval of the change.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A live view shows the work but not the values the model holds. Bring one CRM task and see, with test values, what the model reads, who approves the change, and what the record shows. Book a demo