The Safe Browser Chore Demo

Setup: what the audience sees

The reveal is watching the model move from instruction to visible action. The best version keeps the scope boring and safe so the audience notices the workflow rather than worrying about data exposure.

The setup matters because Claude demos fail when the prompt hides the goal, mixes private data into a public reveal, or asks for a finished answer without giving the model a way to expose assumptions.

• Use a non-sensitive public workflow, such as collecting public conference dates or comparing documentation pages.
• Close sensitive apps and documents before the demo.
• Use a task where the correct outcome is easy to inspect.

What this does not prove

It does not prove autonomous desktop work is safe for sensitive domains. Anthropic describes computer use as a research preview with evolving risks.

<task>
Use the browser to collect public information from three official event pages and
produce a comparison table.
</task>
<scope>
- Only use public websites.
- Do not log in anywhere.
- Do not open email, banking, health, legal, HR, or customer-data apps.
- Ask before leaving the browser.
</scope>
<output>
Create a table with event name, official URL, date, location, and one uncertainty
or follow-up question per event.
</output>

The reveal: what should happen

• Claude should ask for or respect app permissions rather than silently taking broad control.
• The output should include source URLs and uncertainties.
• A good demo makes stopping and supervising the agent feel normal.

Verification steps

A demo becomes useful when the audience can inspect it. Use the steps below to turn the reveal from theater into a repeatable workflow.

1. Click each official URL and verify the date/location row.
2. Check that Claude did not use unofficial aggregator pages when official pages were available.
3. Inspect browser history or task trace if the product surface provides one.

Guardrails

• Never demo with financial, health, legal, HR, customer, or credential surfaces.
• Assume visible screen content can be processed.
• Treat prompt injection as a live risk when browsing the web.

Variations

• QA a public marketing page against a checklist.
• Gather public product pricing pages into a comparison table.
• Walk through a non-authenticated documentation task.

FAQ

Why make the task boring?

A low-risk task lets viewers see the permission model, supervision pattern, and failure modes without exposing sensitive data.

Can I use this with internal dashboards?

Only after a separate risk review. The public demo should avoid authenticated or sensitive systems.