datasette-agent Browser Task Execution (browser_task) — Cross-Boundary Code Execution Risk

Technical Analysis

The entry point is a new agent-exposed capability, context.browser_task(), invoked from within agent tool code and executed client-side in the user's browser rather than server-side in a sandboxed environment. If an attacker can influence tool selection or arguments (via prompt injection, a malicious/compromised third-party plugin, or a poisoned tool description), they could cause arbitrary JS execution in the browser context, gaining access to the user's authenticated session, cookies, local storage, and same-origin API calls (effectively a stored/reflected XSS-like primitive delivered through the agent rather than a webpage). This crosses the boundary between the LLM planning/tool-call layer and the human-interface/browser layer, converting a tool-use decision into direct client-side code execution — a step change in blast radius compared to server-side tool execution. The severity depends heavily on what sandboxing, origin restrictions, and user confirmation gates are implemented around browser_task, none of which are detailed in the release notes.

Affected Systems

datasette-agent

Detection Signatures

• Tool/plugin calls to context.browser_task() with dynamically constructed or externally-sourced JS strings
• Agent tool descriptions or outputs containing embedded <script> or JS eval-like payloads
• Unexpected DOM mutations, network requests, or cookie access following agent tool invocation
• Third-party datasette-agent plugins requesting browser_task capability without clear justification
• Log entries showing browser_task invoked immediately after untrusted data ingestion (e.g., from a queried dataset or external tool response)

Remediation Steps

1. 1

   Sandbox browser_task execution

   Run injected JS in a strictly sandboxed iframe or Web Worker with no access to the parent page's cookies, DOM, or origin, and enforce CSP restrictions.

2. 2

   Require explicit user confirmation

   Prompt the user to review and approve any browser_task JS payload before execution, especially when the code originates from a plugin or dynamic tool output rather than static, audited code.

3. 3

   Restrict payload provenance

   Only allow browser_task code that is statically bundled with a vetted plugin; disallow LLM-generated or dynamically constructed JS strings from being passed directly to browser_task.

4. 4

   Audit third-party plugins

   Review and pin versions of any datasette-agent plugins using browser_task, treating this capability as equivalent to granting client-side code execution privileges.

5. 5

   Monitor and log invocations

   Log all browser_task calls with source plugin, payload hash, and triggering context to enable post-hoc detection of anomalous or injected behavior.