Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can Grok Bot See When It Browses for You?
Everything the portal renders in the session the Bot holds, because every Bot on an account shares one cloud computer and its browser logins, and xAI's pages describe that machine rather than a filter on what the model reads. Ask what the model receives from each portal screen, and whether any value is replaced before it reads them.
A procurement analyst hands a Grok Bot one supplier invoice to reconcile, and the Bot opens the vendor portal in the browser session the account already holds. The invoice page carries the supplier's legal name, the remit-to bank account and routing number, the tax ID on file and the clerk who receives payment notices, while the task names a single line of it. The model receives the whole page, every field included. xAI documents the machine the Bot works from and the sessions that machine keeps, which settles where the work runs and leaves open which of those fields the model is shown. That gap is worth settling before an agent is pointed at a portal that renders bank details, because a page read once stays in the model's context for the rest of the run. What Is Render-Layer Tokenization? defines the control that changes the answer, and Is It Safe to Give Grok Bot Access to Your Company Systems? records the wider review of the same product.
Key findings
- For Grok Bot to keep a supplier's bank details out of the model's view, the values on the portal page would have to be replaced with consistent tokens before the model reads it, so the agent works on SUPPLIER_001 and ACCT_001 and the real account number resolves only at the approved destination (What Is Render-Layer Tokenization?).
- It would also take a named person approving each payment or bank-detail change the agent proposes, and a record of what the model received on each screen, exported to the customer's own monitoring (What Is Supervised Delegation?).
- Grok Bot's published documentation does not state that values on a page are replaced before the model reads them; its pages describe the machine, the browser and the logins that machine holds (xAI, 2026).
- The overview puts Bots on "a persistent cloud computer with a browser, filesystem, and terminal" and says they are "included with every paid individual Cursor plan and with the Cursor Teams plan," which places the work and not the reading (xAI, 2026).
- The portal's own controls govern the person: Chase's business page offers to "Assign your employees varying levels of access" and to "Require a second approver on transactions with Dual Control," settings that decide what a signed-in user may do rather than which fields the page draws (Chase, 2025).
- A design-patterns paper for agents that read untrusted input proposes "principled design patterns for building AI agents with provable resistance to prompt injection," a property of the run rather than of the screen (Beurer-Kellner et al., 2025).
What does Grok Bot receive from a page it opens?
The overview describes "Bots you can keep around: AI teammates with names, jobs, and context that compounds over time," each working on "a persistent cloud computer with a browser, filesystem, and terminal" (xAI, 2026). One machine serves them all: "All of your Bots use the same cloud computer, sharing its files, browser sessions, and app logins," while "between users, isolation is strict" (xAI, 2026). So the browser a Bot drives is signed into whatever the account signed into, and a vendor portal opened there renders the page that account would see, with every panel the portal draws. Grok Bot is one of the 9 of 15 AI agents whose pages document keeping passwords or credentials away from the model, and 0 of the 15 describe doing the same for the customer data a working page displays, such as the supplier bank details here (Do AI Agents Ask Before Making a Payment?).
What the model receives is that rendered page. A screenshot or a page tree arrives with the fields the portal puts on the screen, and the statements from the documentation describe the machine, the sessions on it and the boundary between users. The boundary that would matter here runs across a page, and none of the pages reviewed draws it.
The live page on Grok Bot records the same reading for the wider product, including the shared computer and the app logins every Bot inherits (Is It Safe to Give Grok Bot Access to Your Company Systems?). What that review adds is the consequence: a value the model reads on one page is available to every later step, including one whose instructions arrived from the page.
What does a vendor portal render for an agent using your login?
The record is a supplier master page on a vendor portal, opened to reconcile one invoice. It renders the supplier's legal name, the remit-to bank account and routing number, the tax ID from the W-9 and a table of the last four payments. The navigation on the same screen lists the other suppliers her role can reach, because a portal is built to show a buyer everything needed to pay a supplier.
The portal's access model governs the person. Chase's business page offers to "Set daily transaction limits and approval thresholds" and to "Control which accounts employees can see" (Chase, 2025). Dual control is the strongest setting and it is still about the transaction: a second person approves the payment, while the account panel the agent reads renders the same numbers for both (Chase, 2025).
One design choice changes where the page lives. The PCI Council's FAQ draws a line by page type, between a merchant page that embeds a processor's payment form and one that redirects the customer to it: the criterion "only applies to e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form" and "does not apply" where the merchant's page "redirects customers" to the processor (PCI Security Standards Council, 2025).
A browsing agent's prompt is built from the page it reads (Can a Browser Agent Copy Customer Data From a Web App Into a Prompt?), and the fill mechanics that keep a typed value out of the model do not change what the page displays (Can a Browser Agent Fill In a Form Without Seeing the Values?).
What do the vendors themselves say?
Microsoft's Copilot Studio governance page says data policies control an agent's "knowledge sources, actions, connectors and skills," and that admins have "full visibility into maker audit logs in Purview," a set of controls over agents an organization builds (Microsoft, 2026). The policies set what an agent may reach and the logs record what its makers changed.
Amazon Bedrock Guardrails works at the model call: "The input is evaluated against the configured policies specified in the guardrail," and then the response is evaluated the same way (AWS, Guardrails, 2026). That is a decision about text on its way into and out of a model, made after the page has drawn.
A per-field policy on what a model receives from a rendered screen is not described in the pages reviewed. What is described is where the machine runs, which sources and actions an agent is configured with, and what a guardrail evaluates on the way through.
| Dimension | Grok Bot, per its documentation | What a buyer should verify |
|---|---|---|
| Machine | "a persistent cloud computer with a browser, filesystem, and terminal" (xAI, 2026) | Whether the portal session belongs to the account or to the agent |
| Sessions | "All of your Bots use the same cloud computer, sharing its files, browser sessions, and app logins" | Which work accounts are open on that machine today |
| What the model receives | The page the browser renders; no field-level policy stated | One screen, field by field, as the model took it in |
| Approver for a payment | The plan and the machine are described, and no approver for a payment appears | A person's name against the payment |
| Record | No record of what the model read appears | What the customer can export after one run |
The middle column is thinner than it looks: Grok Bot's pages answer where the work runs, and the questions a portal raises, which fields the model reads and who approves the payment, stay open.
What should a security team ask for in writing about what the model reads?
The first ask is the screen: what does the model receive from each rendered page, field by field, and is any value replaced before the model reads it? A vendor that answers with a list of blocked sites has answered a different question, because those narrow where the agent goes and not what the page shows.
The second is identity. A separate agent identity is what makes a log readable, and the AWS guidance asks for designs where "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, AGENTSEC03, 2026).
The third is the approver: a named person for each payment or bank-detail change, outside the model, with the approval recorded. The fourth is the record: what was on each screen, what the agent did and who approved it, exportable to the organization's monitoring.
The fifth is what happens if the context leaks. OWASP's entry names the outcome as "unauthorized data access, privacy violations, and intellectual property breaches" and notes that "Personal identifiable information (PII) may be disclosed during interactions with the LLM" (OWASP, 2025). If the context leaves, covered firms need an incident response program and "must generally notify affected individuals within 30 days" (SEC, 2024).
A step a site reserves for a person is worth keeping with the person, which is what 1Password and Browserbase describe for autofill (Can a Browser Agent Get Past Two-Factor Authentication Without Seeing My Codes?).
What does a governed environment change?
A governed environment acts on the screen before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so a supplier page renders as SUPPLIER_001, ACCT_001 and TAX_002, the invoice line stays legible, and the agent can still reconcile the invoice and prepare the payment. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. The real values resolve only at the approved destination, at the moment of an approved action.
The other two parts are accountability. A named person approves each payment or bank-detail change, and a remit-to change is the action worth a second pair of eyes. Every screen the model read, every action and every approval with a name goes into a record the organization can export.
For this page's record the difference is concrete. Before, the portal draws the remit-to account beside the invoice line, and the model's copy carries it into every later step. Inside, the same page renders with ACCT_001 where the account number sat, and the real number appears only at the destination the payment manager approved.
Its scope is the rendered page. A value the agent reads from a file, a terminal, an API response or an MCP tool is outside this control, and this page's question is about the browser. The comparison for this vendor sets the design beside Grok Bot's own pages (RedactSure vs Grok Bot: 2026 Comparison & Alternative).
What the record shows
For a payables team, what the model receives is decided at the screen, where the portal draws the remit-to account beside the invoice line. xAI's pages describe the machine, the browser and the sessions a Bot holds, and the portal's roles, limits and dual control decide what the analyst may do, so each of those controls leaves the drawn page in front of the model. The conclusion is narrow: a page read once stays in the model's context for the run, and a control at the machine, the role or the transaction does not change what the page shows. The test takes one supplier record: open the portal page the Bot will use, ask it to reconcile one invoice, then compare the fields the page rendered with what the transcript and the screenshots contain. The fields in both lists are the exposure, and the ones that differ are the control.
Methodology and limitations
This page rests on xAI's Grok Bot overview, a bank's business access page, the PCI Council's FAQ on SAQ A eligibility, Amazon's Bedrock Guardrails documentation and its Well-Architected guidance, Microsoft's governance page, OWASP's entry for sensitive information disclosure, an SEC rule release and a design-patterns preprint, with RedactSure research pages for the control class. The sources were read between October 21, 2026 and October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
None of the products on this page was tested, and the statements come from documentation; not described means the pages reviewed. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The supplier record describes a record type, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
What can Grok Bot see when it browses a vendor portal for me?
The page, as the portal draws it for the signed-in account. xAI's overview says each Bot works on a shared cloud computer, and that all Bots on an account share its files, browser sessions and app logins. A portal opened there renders the supplier's record, the remit-to bank account and the payment history, and the model receives what the page shows. The task names one invoice and the page carries more, so list what one portal screen displays.
Does the shared computer change what one Bot can read?
No, it widens the set of pages a run can reach. Isolation is strict between users, and every Bot on one account shares the browser sessions and app logins, so a page one Bot signed into is a page another Bot can open. The account is the boundary, not the Bot. Ask which services that account is signed into today, then treat each as a page a model may read on any run.
Do the portal's roles and dual control keep the bank details out of the model?
No. Roles and dual control decide what the signed-in user may do. Chase's business page offers varying access levels, transaction limits and a second approver, and those settings govern the transaction rather than the display. The panel that renders the remit-to account is part of the page either way. A control on what a person or an agent may do is worth having, and it is not a control on what the model reads.
Is a guardrail at the model call enough?
Only for the text its policy covers. Bedrock Guardrails evaluates the input against configured policies and then evaluates the response the same way, which is a filter on the model's stream rather than on the page. A supplier's account number may not match a pattern tuned for card numbers, and a filter broad enough for everything stops the work. A guardrail reduces what reaches the model; it does not decide which fields the page renders.
What record should I ask for after the run?
One that names the screens, the actions and the approver. The AWS guidance asks for logs that attribute every action to an agent or a human actor, which a Bot using a person's session cannot give you. Ask what the agent read on each screen, what it did, who approved it, and how that record is exported to the organization's monitoring. A conversation transcript is a start, and it is not that artifact.
What would make the answer different?
A field-level decision made before the model reads the page. If the values a policy names were replaced with consistent tokens as the portal renders, the model would work on SUPPLIER_001 and ACCT_001 and the real number would resolve only at the approved destination. The page would still function and the record would show what the model received. That is the change to ask for, and the shared computer does not make it.
How RedactSure Keeps a Supplier's Bank Details Out of the Model's View
Roles, limits, dual control and a guardrail at the model call govern what a person or an agent may do, and none withholds a field from the page. xAI's own overview says every Bot on an account shares one cloud computer with its browser sessions and app logins.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the portal draws the remit-to account beside the invoice line, and the model's copy of that page carries the number into every later step. Inside, the same page renders with ACCT_001 where the account sat, the invoice still reconciles, and the real number appears only at the destination the payment manager 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 page read once sits in the model's context for the rest of the run. Bring one portal screen from your workflow and see, with test values, what the model reads, who approves the payment and what the record holds. Book a demo