Browser automation is where an AI agent stops being a chat interface and starts operating inside real systems. It can open private dashboards, read customer records, click buttons, fill forms, download files, upload attachments, copy text between applications, and submit changes under a logged-in user session. That capability is useful, but it also creates a wide security boundary. A prompt injection hidden in a web page can become a business action. A confusing page can cause the agent to click the wrong control. A weak approval screen can hide where data is going. A downloaded file can become the next untrusted input.
This checklist is for teams building or buying browser-using AI agents. It focuses on practical controls that should be in place before a browser agent touches production accounts, customer data, admin panels, billing systems, internal tools, or write-capable workflows.
1. Treat the browser session as a privileged tool
A browser session is not just a viewport. It may contain cookies, tokens, saved accounts, tenant context, admin privileges, private URLs, autofill values, and access to systems the model itself should never see directly. The agent should not inherit a broad human browser profile by default.
Use dedicated agent sessions with the minimum account permissions needed for the workflow. Separate testing, staging, and production sessions. Do not let the agent use a developer’s everyday browser profile. If a workflow requires admin access, treat that workflow as high risk and add stronger approvals, trace logging, and rollback steps.
2. Restrict allowed origins and paths
Browser agents should not roam the internet freely when the task only needs a known set of applications. Define allowed domains, paths, and account contexts for each workflow. A billing workflow may need the billing dashboard and CRM, but not arbitrary websites. A support workflow may need the help desk and knowledge base, but not production database consoles.
Block navigation to unapproved origins by default. If a page redirects to an unexpected domain, the agent should stop and ask for review. This matters because prompt injection often tries to move the agent toward attacker-controlled pages, callback URLs, paste services, file hosts, or fake login pages.
3. Label page content as untrusted input
Everything the browser reads from a page should be treated as untrusted data. A web page, support ticket, document preview, issue comment, or analytics dashboard can contain text that tells the agent to ignore prior instructions, reveal hidden data, change destinations, or click a dangerous button. The agent should not treat page text as system instructions.
Prompt templates should clearly separate trusted instructions from page content. Tool results should be wrapped with labels such as “untrusted page text” or “user-controlled content.” The browser controller should prevent page content from changing the agent’s allowed tools, destination allowlists, approval rules, or identity.
4. Limit click and submit actions
Reading a page is lower risk than clicking a button or submitting a form. The agent should classify browser actions by risk. Low-risk actions may include opening a page, expanding a section, or copying visible text. Higher-risk actions include submitting forms, sending messages, changing permissions, deleting records, issuing refunds, purchasing items, publishing content, or changing configuration.
High-risk browser actions should require explicit confirmation. The approval prompt should show the page URL, target element, action type, affected record, form fields, and likely business effect. A button label alone is not enough. Many dangerous actions look harmless if the user only sees “Continue” or “Save.”
5. Show form diffs before submission
Browser agents often fill forms faster than humans can inspect them. Before submission, show a diff of what changed: original values, proposed values, hidden fields if accessible, destination URL, and required fields. This is especially important for customer communication, billing, access control, policy settings, and production configuration.
The user should be able to approve, edit, or cancel. If a form contains sensitive values such as tokens, passwords, customer identifiers, or financial data, the review screen should redact where possible while still making the risk understandable.
6. Isolate downloads
Downloaded files are another untrusted input channel. A page can ask the agent to download a file that contains malicious instructions, sensitive data, macros, unexpected file types, or oversized payloads. Downloads should land in an isolated workspace, not a shared user directory.
Scan downloads before use, restrict executable file types, record file source URLs, and attach downloaded files to the agent trace. If the agent reads the file, the contents should be labeled as untrusted. If the agent uploads or forwards the file, that outbound action should go through approval.
7. Control uploads and attachments
Uploads are data movement. A browser agent that can upload files can leak internal documents, logs, exports, screenshots, source code, or customer data. Do not let the agent choose arbitrary local files. Provide a narrow file picker or an approved workspace for each task.
Before upload, show the file name, source, size, content type, destination page, destination account, and reason for upload. For sensitive files, add policy checks and require human confirmation. If an upload is sent to an external domain, treat it as a high-risk outbound action.
Browser sessions can accidentally mix accounts. A user may be logged into a personal account in one tab and a company account in another. The agent may land in the wrong tenant, workspace, or environment. This is a common source of silent mistakes.
Display the active account, tenant, workspace, and environment before any write action. For production workflows, require the agent to verify the tenant or account against the expected task context. If the browser state does not match the requested customer, project, or workspace, stop the run.
9. Prevent credential and autofill exposure
Autofill and password managers can leak secrets into a browser session. The agent should not see saved passwords, recovery codes, private keys, or personal payment methods. Disable unnecessary autofill in agent sessions and avoid sharing human password-manager state with the agent runtime.
If credentials are needed, use server-side token exchange, scoped service accounts, or just-in-time access rather than exposing raw credentials to the browser. Any credential shown on screen should be redacted in screenshots, traces, logs, and model-visible text.
10. Record a replayable trace
A browser agent should leave an audit trail that explains what happened. Record URLs, page titles, tool actions, selected elements, form fields, approvals, downloads, uploads, errors, and final outcomes. Screenshots can help, but they should be redacted when they contain sensitive data.
The trace should answer three questions: what did the agent see, what did it decide, and what did it change? Without that evidence, a team cannot debug wrong actions, investigate data exposure, or prove to a customer that a workflow was controlled.
11. Add rollback and containment paths
Every write-capable browser workflow needs a rollback story. If the agent changes the wrong record, sends the wrong message, uploads the wrong file, or modifies configuration, who can undo it? How quickly can the session be revoked? Which logs prove the scope?
Before launch, document the disable switch, account revocation step, affected-system owner, rollback command or UI path, customer communication owner, and retest requirement. Browser automation feels simple until an action lands in production. Recovery should not be improvised during the incident.
12. Test hostile pages and confusing UI
Do not only test happy paths. Create test pages and records that include hostile instructions, misleading buttons, fake login prompts, hidden text, invisible form fields, external links, and documents that ask the agent to leak data. Also test ordinary UI confusion: duplicate buttons, stale pages, modal dialogs, pagination, disabled controls, and validation errors.
The expected behavior should be explicit. The agent should ignore hostile page instructions, stop on unexpected origins, ask for approval before risky actions, display form diffs, block unknown downloads, and preserve a useful trace. Repeat these tests when prompts, browser controllers, models, tools, or allowed domains change.
Practical launch rule
If a browser agent can operate inside a logged-in account, it needs production-grade boundaries before it touches real users or real data. The minimum launch set is dedicated sessions, origin allowlists, untrusted page labeling, approval for submit actions, file isolation, upload controls, account verification, redacted traces, and rollback steps.
Related resources
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
- AI Agent Data Exfiltration Checklist
- MCP Security Checklist for AI Agents
- AI Agent Tool Permissions Checklist
For a broader launch review, use the AI Agent Readiness Self-Assessment or request an AI Agent Readiness Audit.