Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Is a Secure Environment for Nova Act in Regulated Work?
A secure environment for Nova Act in regulated work renders each page with consistent tokens in place of the values a claim carries, so the model acts on the record without holding the claimant's details. Ask where that substitution happens, who approves the payment, and what record the run leaves.
Claims operations teams that want alternatives to pointing Nova Act at a raw portal screen face a narrow problem with a long tail: the automation works, and every field on the page passes in front of the model on the way through. A single claim view carries the claimant's name, date of birth, policy number, bank account and diagnosis codes, and a browser agent reads the viewport rather than the four fields the task needs. The work is regulated, so the reviewer asks afterward which values the agent held while it finished, and who approved the payment that followed. AWS's data protection page states that information passed through Playwright "could still be collected in screenshots by AWS if it appears unobstructed on the browser when Nova Act is engaged in completing an action," which puts the rendered page at the center of the review (AWS, Data protection, 2026). What Is the PII Wall? describes the gap between the organizations experimenting with agents and the smaller number that have scaled one. A team that settles those questions can put Nova Act on regulated work.
Key findings
- For Nova Act to work a regulated claim without the exposure AWS warns about, the values on the rendered page would have to be replaced with consistent tokens before the model reads it, so the model acts on CLM_001 and ACCT_001 while the real account number resolves only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment, submission or record change, and a record of every screen the model read with the approver's name attached (What Is a Protected Browser for AI Agents?).
- AWS's data protection page names the screenshot exposure and tells developers to pass passwords through Playwright keyboard calls, and it does not describe a control that replaces the values a page renders before the screenshot is taken (AWS, Data protection, 2026).
- The page recommends that "you do not provide sensitive information within the act() statements, such as account passwords," which keeps a password out of the prompt while leaving every other field on the claim screen in the screenshot (AWS, Data protection, 2026).
- 1Password's write-up of its OpenShell integration states that "The agent can work with real systems without holding any credentials in its context" (1Password, 2026).
- Browser Use's Real Browser documentation states that it "allows you to automate your existing Chrome browser, so you are already logged into your websites" (Browser Use, 2026).
What does Nova Act receive when it opens a claims portal screen?
Nova Act drives a browser, and a browser gives up its viewport rather than a field list. AWS's data protection page tells developers to pass a password "directly to the browser using Playwright keyboard API calls," which describes the same surface: the value is typed into a page, and the page is what the model reads (AWS, Data protection, 2026).
Whatever the page renders arrives with the task. OWASP's entry on sensitive information disclosure states that "Personal identifiable information (PII) may be disclosed during interactions with the LLM," and a claim view is PII in every row (OWASP, LLM02, 2025). A person working the claim looks at the field the task needs; a screenshot has no such filter.
Content on the page can act as well as inform. The EchoLeak paper documents CVE-2025-32711 in Microsoft 365 Copilot, where the client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025). A portal that renders provider notes or an uploaded estimate offers the same surface, and the next act() call is the action an injected instruction can steer.
| Field on the claim screen | What the person working the claim sees | What the model reads in a governed environment | Why the reviewer asks |
|---|---|---|---|
| Claimant name | The name on the policy | CLM_001 | Ties the claim to a person |
| Date of birth | The date on the record | DOB_001 | Identifies the claimant with the name |
| Policy number | The policy reference | POL_001 | Links the claim to coverage |
| Bank account for the reserve | The account on file | ACCT_001 | Names the payment destination |
| Diagnosis codes | The codes on the claim | DX_001 | Health data the task rarely needs |
| Reserve amount | The amount under review | AMT_001, a figure the task does not use | The approver needs the real figure |
What does a secure environment wrap, and what does it leave alone?
The environment in the title is the browser session the agent reads, not the model and not the service that runs it. It governs what Nova Act is shown on a page rendered for the task: the claim screen, the payment tab, a document viewer, a settings page. It does not govern the SDK's own process, direct API calls, MCP servers, the terminal, the local filesystem or the platform's storage of prompts and screenshots. The page is the unit of control, and a single claim task crosses several of them.
That boundary is where data minimisation lands. Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (Regulation 2016/679, 2016). A policy that shows the model the fields the task needs and a token for the rest meets the standard on the screen, and counsel decides whether the record meets it.
Two things stay outside it. AWS's page scopes itself to "your deployment on the Nova Act AWS service as an AWS customer" and states that "The AWS shared responsibility model applies to data protection in Nova Act," which leaves service-side collection and retention to the contract (AWS, Data protection, 2026). The claim itself does not change: the real name, account and diagnosis codes stay in the system of record, and access and retention remain the organization's.
What do the vendors themselves say?
AWS's Nova Act page gives the developer two instructions and one warning. Passwords belong in "Playwright keyboard API calls" rather than act() statements, and data "could still be collected in screenshots by AWS if it appears unobstructed on the browser when Nova Act is engaged in completing an action" (AWS, Data protection, 2026). The password stays out of the prompt, and the typed value stays on the page.
A different AWS page documents the closest pattern for keeping the call itself outside the agent. With RETURN_CONTROL, "the agent hands the elicited parameters back so the application, not the agent, runs the API call" (AWS, Return control, 2026), which covers the call rather than the page the agent read.
1Password's OpenShell write-up documents the placeholder pattern from the sandbox side: inside the sandbox "the agent sees placeholders rather than real credentials," with the swap at an approved host (1Password, 2026). It covers a development sandbox and says nothing about a rendered portal page.
Browser Use's Real Browser page does not address the security or privacy risk of automating a logged-in profile, and a session that is already signed in renders every field the agent visits to the model (Browser Use, 2026).
| Dimension | What the documentation states | What a buyer should verify |
|---|---|---|
| Screenshot exposure | Data "could still be collected in screenshots by AWS" if it appears unobstructed | Whether anything governs the page before capture |
| Consequential call | With RETURN_CONTROL the application, not the agent, runs the API call | Which calls the application executes |
| Real value release | 1Password's gateway swaps a placeholder at an approved host | Whether the same release exists for a rendered page |
| Signed-in session | Browser Use automates an existing signed-in Chrome | What the model reads on an authenticated page |
Which alternatives to a raw screen leave the values out of the model's context?
Four approaches come up, and each one governs a different object. A sandbox bounds what the process can execute and reach. A vault or an egress gateway holds a credential and releases it at an approved host. Driving the browser a person already uses keeps the session and its logins. An enterprise browser governs what a person copies, pastes or downloads on a managed device, which is the distinction drawn in Enterprise Browser or Render-Layer Tokenization?, and it does not say what a model reading the same page receives.
Filling a field without reading the value is the documented version of the vault idea, and it stops at the fill. Browser Use's sensitive data documentation states that "the LLM only sees placeholders (x_user, x_pass)" and that "real values are injected directly into form fields after the LLM call," and the page says nothing about the page that follows the fill (Can a Browser Agent Fill In a Form Without Seeing the Values?).
The approach that changes the count renders the page differently. Replace the values with tokens before the model reads the screen, resolve the real value only at the approved destination, and a hijacked agent leaks placeholders rather than a claim, the scenario worked through in What Can a Hijacked Agent Leak If It Only Has Placeholders?.
What does a governed environment change?
A governed environment acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on CLM_001, ACCT_001 and DX_001 rather than the claim. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the policy and approves each payment, submission or record change, and every screen, action and approval is written to a record that exports to the organization's monitoring.
The approval is a decision about one action, and the person making it needs the record in front of them. OWASP defines excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, LLM06, 2025), which puts the fix outside the model. OWASP's prompt injection entry recommends that teams "Restrict the model's access privileges to the minimum necessary for its intended operations" (OWASP, LLM01, 2025).
For a claims task, the image the model reads carries CLM_001 where the claimant's name was and ACCT_001 where the account was, so an injection that reaches the model collects tokens. The real values appear only at the destinations a person approved: the claim record at submission and the payment rail at the reserve payment.
A browser control that stops a person copying or downloading a claim governs an action on the page; it does not state what a model reading the same page receives (RedactSure vs Chrome Enterprise Premium: 2026 Comparison & Alternative). The change sits in what the agent is shown when it arrives, and in the record of who allowed the action.
What the record shows
A regulated reviewer can check three things: what the model received on the rendered page, who approved the action, and what record the run left behind. On this record the evidence points one way. AWS warns that unobstructed page data "could still be collected in screenshots by AWS," and the two documented designs that keep a value away from the agent, a placeholder swapped at an approved host and an application that executes the call, both act outside the model. The environment that wraps Nova Act therefore has to change the page before the screenshot. A claims team should run the check on its own portal: open one claim with a test value, capture the screen the agent receives, and search the image and the transcript for the account number. If the value appears in either, the control sits after capture.
Methodology and limitations
This page rests on AWS's Nova Act data protection page and its Bedrock return-control page, 1Password's OpenShell write-up, Browser Use's Real Browser documentation, three OWASP entries, GDPR Article 5(1)(c) and the EchoLeak paper, together with existing RedactSure research pages. Vendor pages were read between October 20, 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 to a page.
No product named here was tested for this page, and "not described in the pages reviewed" means the pages reviewed. 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 claims portal task with tokens and an approver, not an organization. Determinations about whether a workflow meets a regulatory standard belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What is a secure environment for Nova Act in regulated work?
One that changes what the model reads on the page, not only where the agent may go. Nova Act still opens the claim, reads the screen and proposes the payment, but the values in that screen are replaced with consistent tokens before the model reads them, the real values resolve only at the destination a named person approved, and the run leaves a record of what the model saw. The platform, the SDK and the system of record keep their own controls.
Does Nova Act see the whole claim screen, or only the fields it needs?
The whole screen it is given, because browser automation reads a rendered page. The claimant's name, policy number, bank account and diagnosis codes arrive together even when the task needs one field. A person can ignore what they do not need, and a screenshot cannot. That is why the field set on the portal matters more than the wording of the prompt.
Does a sandbox around Nova Act change what it reads?
No, not by itself. A sandbox bounds what a process can execute and which hosts it can reach, and the screenshot is taken inside whatever browser runs in that sandbox, so every rendered field still reaches the model. Sandboxing is worth doing for the execution side, and it leaves the reading side where it was. The check that settles the question looks at the page, not the process boundary.
Who should approve the payment the agent prepares?
A named person, per action, outside the model. The approver should see the claim as the model saw it, with tokens in place of values, the destination the payment will reach and the amount in the claim's terms, then approve or refuse that one action. A standing permission for a run is not an approval. The name on the approval is what a reviewer reads a month later, when the transcript alone cannot say who allowed the money to move.
What record should the environment keep?
A record of each screen the model read, each action the agent proposed and took, and each approval with the approver's name and the time. It should export to the organization's own monitoring, because the reviewer has to reconstruct what the model saw before it acted. A chat transcript is not that record: it can show tokens without showing the page they came from, and it rarely shows who allowed the payment.
Does a placeholder protect the account number the agent pays from?
It protects the model's context, not the payment itself. A placeholder such as ACCT_001 keeps the account number out of the screenshot, the transcript and anything the model writes, while the real number resolves at the payment destination when a named person approves the release. The account still exists in the system of record, and access to it stays a separate control. Test where the real value appears, not whether the model saw a token.
How RedactSure Keeps the Claim Values Out of the Screenshot
A browser control that only limits where an agent may click still hands the model every field a claims page renders. AWS warns that data "could still be collected in screenshots by AWS if it appears unobstructed on the browser" (AWS, Data protection, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: Nova Act opens claim CLM-2288, and the screenshot carries the claimant's name, policy number and bank account. Inside the governed environment: the page renders with CLM_001, POL_001 and ACCT_001, the model submits on those tokens, and the real account resolves only at the payment destination a named approver confirmed.
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 screenshot of a claim is the artifact a reviewer will ask to see. Bring one claim of your own and watch, with test values, what the model reads and where the account number resolves. Book a demo