Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can AWS See Passwords in Nova Act Screenshots?
Only where the page leaves the value in the clear. AWS's Nova Act guide says information that appears unobstructed on the browser could be collected in screenshots, so check what your own pages render and what replaces those values before the model reads them.
An order history page is the most ordinary screen a customer account owns: past orders, the total on each, the delivery address, the last four digits of the card, an invoice behind every line. A team that puts a Nova Act agent on that page to chase a refund has given the run a record of the customer's purchasing, and the run captures screenshots while it works. AWS's guide puts a condition on what those screenshots hold: information that appears unobstructed on the browser could be collected in screenshots by AWS. A password field renders dots, so the digits a customer types are never characters on the page. An account page renders the balance, the address and the account number as characters, and a screenshot of it carries them.
The question lands on whoever signs off the deployment. A security lead approving a Nova Act run on customer accounts has to answer two things: what the service collects while the agent works, and whether the page, rather than the agent, decided which values were visible. AWS answers the first and leaves the second with the application, since a service that only sees what the browser draws cannot vouch for a field the application masks.
Key findings
- For a Nova Act run to keep a customer's values out of the screenshot, the page would have to render consistent tokens before the model reads it, so the run works with ACCT_001 and the real account number resolves only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change and a record of what the model received while the run works (What Is an AI Control Record?).
- AWS's guide states the collection risk and recommends a typing route for passwords; it does not describe a step that replaces a rendered account value before the screenshot (AWS, Data protection, 2026).
- The same guide warns that if sensitive information is passed through Playwright, "the information 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).
- Browser Use's documentation for its own browser agent lists "Set use_vision=False to prevent screenshot leaks" among its controls, which treats the picture as a route the operator closes (Browser Use, 2026).
- The PCI Security Standards Council's FAQ on audio recordings states that "PCI DSS Requirement 3.3.1 prohibits storage of sensitive authentication data (SAD), including card validation codes and values, after authorization even if the data is encrypted", a rule scoped to audio (PCI Security Standards Council, 2026).
What does the Nova Act guide say AWS receives in a screenshot?
The guide scopes itself first: "This data protection section applies to your deployment on the Nova Act AWS service as an AWS customer", and the shared responsibility model applies (AWS, Data protection, 2026). Within that scope it describes the screenshot as a route the customer controls through the page: if sensitive information is passed through Playwright, "the information could still be collected in screenshots by AWS if it appears unobstructed on the browser when Nova Act is engaged in completing an action". The remedy is about typing. A team should not "provide sensitive information within the act() statements, such as account passwords", and should pass those values "directly to the browser using Playwright keyboard API calls". That removes the password from the act() statement and leaves the rendered page alone.
The record for this page is an order history page: each order, the total, the delivery address, the last four digits of the card, a link to the invoice. Read against the guide's condition, the totals, the address and the last four digits are unobstructed, because they sit on the screen as text while the agent works. A university account summary has the same shape, with "The Account Summary page provides a high-level view of your student account, including:" the total amount you owe, any holds, and a payment portal (North Carolina Central University, 2026).
Why does a masked password field read differently from an order history page?
A password input is drawn by the browser as dots. What the field holds is a string in the form, and what the page shows is a row of bullets, so a screenshot of a login form has no characters to collect. That is the mechanism behind the guide's condition: the value never needs to appear in the page's text for the form to submit it.
Browser Use's template for a different browser agent states that "The LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text", and tells an operator to "Set use_vision=False to prevent screenshot leaks" (Browser Use, 2026).
The limit of that design is the limit of masking. A placeholder covers the value the agent types into a field the operator has wired for it, and masking covers the field the site chose to draw as a password. Can a Browser Agent See My Password When It Logs In? walks through the login case, where the field is masked and the value is typed by design. The order history page behind that login is a different surface: no field is masked there, and the values are the page.
Password fields get a control the rest of the page does not: 9 of 15 AI agents reviewed for payment controls describe keeping passwords or credentials away from the model, and 0 describe swapping the customer data a page renders for tokens the agent can use (Do AI Agents Ask Before Making a Payment?).
Setting up a vendor in QuickBooks shows how quickly the surface changes: "To set up a vendor with open bills, select Set up Bank Transfers within the same line as the Payee", and "You'll need the account number for the vendor" (Intuit, 2026).
What do the vendors themselves say?
AWS describes the screenshot as a surface the customer controls through the page, and its guide documents no step that removes a value from the page before collection (AWS, Data protection, 2026). AWS's credential work sits at a third layer: the AgentCore Identity token vault is built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets", and the agent retrieves them with its own workload token (AWS, AgentCore Identity, 2025). That keeps a credential out of agent code, and it says nothing about a balance an application renders (Does AWS Bedrock Keep Company Credentials Away From Agents?).
The IAM guide adds the older rule that "IAM users with access keys are an account security risk", with the instruction not to provide access keys to unauthorized parties (AWS, Access keys, 2026). Both AWS pages govern a value the agent presents to a service. Neither governs a value a service presents to the agent.
| Dimension | AWS, per its documentation | What a buyer should verify |
|---|---|---|
| What a screenshot can hold | "could still be collected in screenshots by AWS if it appears unobstructed on the browser" | Which fields render as text |
| The route for a password | "passed directly to the browser using Playwright keyboard API calls" | Whether the field masks the value |
| Credentials outside the agent | A token vault for "OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets" | Whether it covers page values too |
| Attribution in the audit trail | "audit logs attribute every action unambiguously to either an agent or a human actor" | Whether the log says what the screenshot held |
The pattern is a vendor that documents custody of a credential the agent sends and stays quiet about the values the page returns. A buyer who reads only the credential pages will believe the problem is solved.
What record does a completed run leave for an auditor?
A completed run leaves the screenshot and whatever the service writes around it. The screenshot answers what the page showed; the audit trail answers who acted: AWS's Agentic AI Lens guidance says that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, AGENTSEC03-BP02, 2026). That standard tells an auditor the agent opened the page and changed a delivery address, and not whether the card's last four digits were in the frame.
The regulatory analogy is a recording. The PCI Security Standards Council's FAQ 1210 quotes Requirement 3.3.1, which "prohibits storage of sensitive authentication data (SAD), including card validation codes and values, after authorization even if the data is encrypted", and adds that where SAD is collected during a call "every effort must be made to prevent the data from being recorded" (PCI Security Standards Council, 2026). The FAQ is scoped to audio, so it does not settle how a screenshot is treated; it supplies the principle that a recording of a value is storage.
A measurement of agent skills drew on "98,380 skills collected from two major registries" and found credential theft through remote code execution to be one of two dominant attack strategies (USENIX Association, 2026). It covers skill registries rather than screenshots, and a password in a screenshot feeds the same market.
The gap to look for is a record that names the page, the fields that rendered as text, and the person who approved the run (What Is an AI Control Record?). A run that opened a page outside the application needs it more, since injected instructions arrive there (Is It Safe to Let AI Agents Read External Web Pages?).
What does a governed environment change?
A governed environment changes the order of operations on the page. The page is drawn, the values chosen by policy are replaced with consistent tokens before any model reads it, and the agent works on the tokens: the order total reads ORD_001, the account number reads ACCT_001. Real values resolve only at the approved destination, at the moment of an approved action, so the invoice the agent files can carry the real total while the screenshots the run keeps do not. A named person approves each record change, sees what the agent is about to do, and can pause the run. Every screen, action and approval lands in a record the customer exports to its own monitoring.
That is a different layer from the ones the vendors here document. Data discovery asks where regulated records live and which systems can reach them, which is the question a platform such as BigID answers when it will "Identify sensitive, regulated, confidential, proprietary, and business-critical data used by AI" (RedactSure vs BigID: 2026 Comparison & Alternative). The result is an inventory of the estate, and an inventory does not become the screen.
What Is the PII Wall? sets out why the lower layers finish before a page renders: they act on storage, transport and identity, and the rendered page sits above all of them. A control that arrives later, at egress or in the log, reads a copy of the page rather than deciding it.
What the record shows
The control that changes a screenshot sits at the rendered page, before the run takes the picture. A value the site draws as text is a value the model and the picture both receive; a value the site masks is not drawn at all. AWS's guide is explicit about the first case and offers no step for the second beyond keeping a password out of the act() statement, which changes what the agent writes and not what the page shows. The security lead should run the test on one page: open the account page the agent uses, in the same session, and read it as a screenshot would. If the balance or the account number appears as characters, the run collected it. Then open the same page behind the login and compare, because a masked field is the exception on that flow rather than the rule.
Methodology and limitations
The page rests on public vendor documentation read in full: AWS's Nova Act data protection page, Browser Use's sensitive data template, AWS's AgentCore Identity post and IAM guide, the Agentic AI Lens guidance, the PCI Security Standards Council's FAQ 1210 and two public knowledge-base pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 21, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it. The statements are the vendors' own, and "not described in the pages reviewed" means the sentences recorded for a page, not what a product cannot do. Vendor pages change, and this page carries its date. RedactSure is deploying now with enterprise and government customers. The record described is a record type, not an organization. Determinations about PCI DSS scope, retention or disclosure belong to counsel and to the organization's security officers, and nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
Can AWS see the password my agent types?
Only if the page draws the value where a screenshot catches it. AWS's Nova Act guide conditions collection on the information appearing unobstructed on the browser, and it recommends keeping passwords out of act() statements and passing them to the form through Playwright's keyboard calls instead. A password field masks what it holds, so the picture shows dots rather than characters. The guide does not promise that screenshots are filtered, which is why the field's own rendering is the thing to check.
What does the model receive from an order history page?
Whatever the page renders as text. An order history page typically lists each order, its total, the delivery address and the last four digits of the card, and an agent asked to check a refund reads all of it. AWS's guide does not carve out account pages; its condition is whether a value appears unobstructed. A team can see the same text by opening the page in the session the agent uses. What the model receives is set by the application.
Why does a masked password field read differently from an account page?
Because the site draws one and not the other. A password input renders as dots, so the screenshot holds dots and the typed value stays in the form. An account page draws balances, addresses and account numbers as characters, and a screenshot of it holds those characters. Masking is a property of the field the site chose, so it covers the login form and stops there. The account page behind the login has no such field.
What record shows which values the model saw?
Few vendor pages describe one. AWS's guidance for agents says audit logs should attribute every action to an agent or a human actor, which answers who acted and not what was on the screen. A record that answers the second question lists the page, the fields that rendered as text, and the person who approved the run. Without it, the screenshot is the only account of what the model saw, and it sits with the service that took it.
Who approves a record change the agent proposes?
No one, unless the workflow names a person. Nova Act's guide describes a run that completes the action it is given, and its controls concern what is passed into that run; a second signature before an order changes is not on the page. The approval has to come from the environment the run sits in, from a workflow that stops before the change. An audit log written afterwards is not an approval.
Is a screenshot of a payment page a PCI DSS problem?
The Council's rule is about storage: Requirement 3.3.1 prohibits storing sensitive authentication data after authorization even if the data is encrypted, and FAQ 1210 applies that rule to recordings. The FAQ is scoped to audio, so it does not settle how a screenshot is treated. What it establishes is the principle to carry into the question: a recording of a value is a form of storage, and prevention is expected where the technology exists.
How RedactSure Keeps the Account Page Out of the Screenshot
The guide's typing route keeps a password out of the act() statement and leaves the order history page's balances, addresses and account numbers in the picture. AWS says a value that appears unobstructed on the browser could still be collected in screenshots by AWS (AWS, Data protection, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the run reads the order history page as drawn: totals, delivery address, the card's last four digits, and the screenshots hold them. Inside, the same page renders ORD_001 and ACCT_001, and the real values resolve only at the invoice a named person 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
What a run leaves in its record depends on what the page rendered, and one test settles it for your own accounts. Bring one customer account and see, with test values, what the model reads and where the real value lands. Book a demo