Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Amazon Nova Act Safe to Use With Real Accounts?
No, not on a real account whose pages carry live customer data. AWS says a password passed through Playwright is still "collected in screenshots by AWS" if it appears on screen, so ask whether the page replaces the value before the model reads it.
A developer points Nova Act at a live retailer account to test checkout. The run signs in, opens the cart, confirms the shipping address, chooses the saved card and places the order, and the account ends with a purchase on it.
The question is what the model receives. AWS's Nova Act data protection page draws a line between the prompt and the screen. It tells developers to keep sensitive values out of the act() statement and pass them to the browser through Playwright keyboard calls. It then warns that a value passed that way can still be collected in screenshots if it appears unobstructed on the browser while Nova Act completes an action. A test card gives that warning nothing to collect. A real card, a customer's address and a purchase history give it plenty.
That difference sets the answer. The gap between a test account and a live one is the gap What Is the PII Wall? describes between teams experimenting with an agent and teams running one on real work. A synthetic account can be safe in the narrow sense that the screenshots have nothing worth taking. A live account asks whether the value is replaced before the model reads the page, who approves the order, and what record the run leaves. The checkout flow is the example throughout.
Key findings
- For Nova Act to be safe on a live retailer account, the values on the checkout page would have to be replaced with consistent tokens before the model reads the screen, so the customer and the card resolve only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving the order before it is placed and a log that attributes the action to the agent or to that person (AWS, Well-Architected, 2026).
- The gap sits between the prompt and the screen: AWS keeps a password out of the act() statement and does not describe a control that replaces the values a page renders before the model reads them (AWS, Data protection, 2026).
- The same page says a value passed through Playwright can still be caught on screen, because "the information could still be collected in screenshots by AWS if it appears unobstructed on the browser" (AWS, Data protection, 2026).
- A measured evaluation of web agents found that they "are prone to inadvertent use of unnecessary sensitive information," which is the habit a live checkout page rewards (Zharmagambetov et al., 2025).
- An adaptive-attack study bypassed 12 published defenses with an "attack success rate above 90% for most," so a classifier in front of the model cannot be the control a live account relies on (Nasr et al., 2025).
What does Nova Act read from a checkout page?
The record is a checkout flow on a live retailer account: sign in, open the cart, confirm the shipping address, choose the saved card, place the order, read the confirmation. Nova Act works it through act() statements.
AWS's data protection page scopes itself to service deployments: it applies "to your deployment on the Nova Act AWS service as an AWS customer" (AWS, Data protection, 2026). It tells developers not to "provide sensitive information within the act() statements," such as account passwords, and says those values should be "passed directly to the browser using Playwright keyboard API calls" (AWS, Data protection, 2026). A password handled that way never enters the prompt.
The screenshot sentence decides the live case. If a value 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). The page renders the name on the account, the address, the card's last four digits, the total and the confirmation number, and it does not say those screenshots are blocked or redacted.
The password may stay out of the prompt while the customer's data is rendered and captured. Can AWS See Passwords in Nova Act Screenshots? takes that question; the point here is what it leaves on a live account.
What changes when the model reads a real account?
On a test account the values are disposable: a test card, a test address and a test order produce screenshots whose contents cannot be spent. A live retailer account is different: the saved card is a payment method with a real limit, the address belongs to the customer, and the order history is a purchase record.
The research record describes the habit this rewards. A measured evaluation of web agents found that they "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025). A rendered checkout page offers the card's expiry date whether or not the next step needs it.
The page is also an input someone else can shape. A permissive information-flow analysis describes how "poisoned data retrieved from one component can change the model's behavior and compromise the entire system," including spreading confidential data to untrusted components (Siddiqui et al., 2025). A coupon field or a delivery note is a component the model reads, and Is It Safe to Let AI Agents Read External Web Pages? covers that route.
The account's safeguards assume a person at the keyboard: New York's regulator tells covered entities to consider "authentication factors that can withstand AI-manipulated deepfakes" (New York State Department of Financial Services, 2024), and an agent working through a session a person opened does not pass that test.
What do the vendors themselves say?
Three AWS pages bear on the question.
| Dimension | AWS, per its documentation | What a buyer should verify |
|---|---|---|
| What the model receives | The rendered page, and screenshots that can collect unobstructed values (AWS, Data protection, 2026) | Which fields appear, and whether any are replaced before the model reads them |
| API credentials | A token vault for OAuth tokens, API keys and client secrets, retrieved with the agent's own workload token (Douglas III, 2025) | Whether the store governs the browser page or only code the team wrote |
| Who approves an action | Not described in the pages reviewed | A named person, per purchase |
| The record | Logs that "attribute every action unambiguously to either an agent or a human actor" (AWS, Well-Architected, 2026) | Whether the log shows the agent or the person whose login it used |
AWS documents where an API credential lives and how to keep a password out of a prompt. It does not describe a control that changes what a checkout page renders before the model reads it, or an approval by a named person before the order is placed (AWS, Data protection, 2026).
That substitution is not documented in the field: Nova Act was outside the 15 AI agents and 86 AI security products reviewed, and not one describes an agent working from tokens in place of the customer data it reads (Do AI Agents Ask Before Making a Payment?; How Many AI Security Products Control What an AI Agent Sees?).
The AgentCore Identity post shows the custody model: the 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 (Douglas III, 2025). That protects a credential in the agent's code, not the card a page displays (Does AWS Bedrock Keep Company Credentials Away From Agents?).
Who approves the purchase, and what record does it leave?
On a live account the action that matters is the last one: placing the order. Nova Act's documentation describes how to keep the password out of the prompt and what a screenshot may collect; it does not describe a step where a named person approves the order before it is submitted, or an action record tied to the agent rather than to the account holder (AWS, Data protection, 2026). An industry review lists "Cursor's agent deleted PocketOS's production database via a single rogue API call" (Columbia DAPLab, 2026).
AWS's architecture guidance points the same way. The Agentic AI Lens asks that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, Well-Architected, 2026). An order placed inside a person's session is logged to that person.
Harvard's security guidance makes the approval half explicit: teams should "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University Information Security and Data Privacy, 2026). A purchase on a live account is all four. The record needs the screen, the action and the approver together. How Do I Know Which Credentials a Coding Agent Has Touched? makes the same point for coding agents. In the checkout flow the third party is the developer's own login.
What does a governed environment change?
A governed environment for this question is a control class that acts where the screen is rendered, before any model reads it. Values a policy names are replaced with consistent tokens for the whole run, so the checkout page the agent works shows CUST_001 for the customer and CARD_001 for the payment method. The real values resolve only at the approved destination, at the moment of an approved action, which for a checkout is the payment step a named person releases. Every screen as tokens and every approval is written to a record that exports to the organization's own monitoring.
Applied to the checkout flow, the class changes both halves of the problem. Before, the model reads the account holder's name, the address and the saved card, and the screenshot clause covers all of it. Inside, the model reads placeholders and can still complete the flow, because the page behaves the same; the real card resolves at the payment step and not in the transcript. The confirmation then shows the tokens the run used, and the record shows who approved the release.
The class has a boundary. It governs the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP. A developer who drives a browser agent from a shell and passes a password through an environment variable is outside it. The difference between the two designs is set out in Enterprise Browser or Render-Layer Tokenization?.
What the record shows
The control that decides this question sits in front of the model, at the point the checkout page is rendered. AWS documents the prompt rule and the screenshot warning, and it documents a credential vault for API tokens; it does not describe replacing the values on a live page before the model reads them, a named person approving the order, or a record that separates the agent's action from the account holder's. That makes the default answer no for a live retailer account whose pages carry a customer's data, and a qualified yes for a synthetic account built to test the same flow. A team should check its own setup by naming one checkout task, running it against a test account and a live account, and comparing the screenshots, the value the payment step received, and the name on the action that placed the order.
Methodology and limitations
Public documentation read in full gives a sound view of where each product applies its control. This page rests on AWS's Nova Act data protection page, its AgentCore Identity post and its Well-Architected Agentic AI Lens, three studies of web-agent privacy, information flow and adaptive attacks, a state regulator's AI guidance, a university security guide and an industry incident review. Vendor pages were read between October 16, 2026 and October 20, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation and none was tested for this page; "not described in the pages reviewed" means the recorded pages do not state the property, not that a product cannot do it. Vendor features change and the page carries its date. The example describes a record type, a checkout flow on a live retailer account, not an organization. RedactSure is deploying now with enterprise and government customers. Determinations about whether a flow meets a regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Is Amazon Nova Act safe to use with real accounts?
No, not by default on an account whose pages carry a customer's data. AWS tells developers to keep sensitive values out of the act() statements and to pass them through Playwright keyboard calls, and the same page warns that unobstructed values can still be collected in screenshots. Neither measure replaces the value the page renders, so the model still reads it. A synthetic account avoids that exposure; a live one needs a control before the screen reaches the model.
Does Nova Act read my password when it types it?
Not from the act() statement, if the developer follows AWS's guidance to pass the password "directly to the browser using Playwright keyboard API calls" rather than in the prompt. The password is still typed into a page the browser renders, and AWS warns that unobstructed information can be collected in screenshots. Whether the field is masked depends on the site's form; the account behind it is readable once the session opens. The prompt rule is not the screen rule.
Does AWS record the screenshots Nova Act takes?
AWS says a value passed through Playwright "could still be collected in screenshots by AWS if it appears unobstructed on the browser," so a screenshot of the run can include what the page showed. The page does not describe a setting that blocks or redacts those screenshots, and it gives no retention period. A team that needs one should ask AWS in writing before pointing the agent at a live account. The clause is a warning, not a control.
Who approves a purchase the agent makes on my account?
On the documented flow, no one beyond the person whose session the agent uses. AWS's Nova Act pages describe the prompt rule and the screenshot behavior and do not describe an approval step before an order is placed. AWS's Well-Architected guidance separately asks for logs that attribute each action to an agent or a human actor, which is the property a live account needs and the one a shared session blurs. Approval has to sit outside the agent's session.
What record shows what Nova Act did on a live account?
The order history and the confirmation email, both created under the account holder's login. Those show that a purchase happened and not what the model read on the way there, which value the payment step received, or who approved it. A record that answers the review question needs the screens, the action and the approver together. AWS's guidance describes the attribution requirement and not a page-level record for this flow. The order history answers a different question.
Can I test a checkout flow with a synthetic account instead?
Yes, and for many teams that is the right first step. A test card, a test address and a test order give the screenshots nothing worth collecting, and the flow can be repeated without touching a customer's data. The limit is what the test cannot show: a live account's saved payment method, order history and session are the fields that make the screenshot clause matter. The test should be followed by a decision about the live account.
How RedactSure Keeps a Live Checkout Page Out of the Model
A live checkout page hands the model the customer's name, address and saved card, and the screenshot warning covers all of it.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model reads the page as the browser renders it, with the card's last four digits, the address and the total, and a screenshot can carry them. Inside: the values become CUST_001 and CARD_001, the model completes the same flow on the placeholders, and the real card resolves at the payment step a named person approves.
RedactSure is deploying now with enterprise and government customers. AWS warns that unobstructed values "could still be collected in screenshots by AWS."
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A live checkout page is the fastest way to see the difference between a clean prompt and a clean screen. Bring one checkout task your team runs and see, with test values, what the model reads and who approves the order. Book a demo