Assumptions
- Your workflow can browse or inspect pages that contain untrusted text.
- The application decides which browser actions are available.
- Anthale can evaluate the content path before page text or browser results are reused.
Secure the browser workflow
1
Treat every page as untrusted content
Assume page text, rendered labels, metadata, and hidden instructions are untrusted until the next boundary check
says otherwise. A familiar-looking interface is not a trust signal.
2
Separate reading from acting
Keep page inspection and navigation separate from actions such as form submission, purchase, deletion, or external
messaging. A model should not turn a page instruction directly into a side effect.
3
Evaluate browser output before reuse
Run Anthale before browser results, copied snippets, extracted text, or page summaries are fed back into the model
or shown to a user.
4
Constrain destinations and credentials
Use allowlisted domains, isolated sessions, and the smallest possible credential scope. Do not let one workflow
browse broadly with the same privileges it uses for sensitive actions.
5
Require approval for high-impact browser actions
Put confirmation or approval in front of submits, sends, purchases, destructive changes, or actions that affect an
external account.
6
Log page provenance and action decisions
Record which URL, domain, page source, or browser tool produced the content, and log whether the model only read,
proposed, or actually executed an action.
What this looks like in code
Common failure patterns
- The model reads page text and immediately executes the next browser action without a validation step.
- Allowed browsing domains are broader than the workflow requires.
- Browser credentials have more privilege than the action path needs.
- Teams log the final action but not the page or domain that shaped it.