agent-in-a-browser

The core functionality involves executing dynamic code (TypeScript/JavaScript) within a WASI sandbox in the browser, which is inherently high-risk if not properly isolated. The project mitigates this by leveraging browser-native security features: - **WASI Sandbox**: Provides a confined environment for code execution, aiming to prevent access to the host system. - **Origin Private File System (OPFS)**: Used for persistent storage, offering a sandboxed and isolated filesystem. - **Cross-Origin Isolation Headers**: `Cross-Origin-Opener-Policy` and `Cross-Origin-Embedder-Policy` are enforced via the `worker/index.js` to enable `SharedArrayBuffer` for synchronous WASM I/O, which is crucial for strong isolation in various browser environments. - **CORS Proxy Allowlist**: The `/cors-proxy` endpoint in `worker/index.js` explicitly whitelists domains like `api.githubcopilot.com`, `generativelanguage.googleapis.com`, `mcp.stripe.com`, and `github.com`. This helps control outbound requests originating from the main browser context. - **WASI HTTP Client**: WASM modules can make HTTP requests using the `wasi:http` API. While the `curl` command and LLM integrations use this, it means the WASM sandbox itself has network access, which could be a vector for data exfiltration if a malicious agent were to compromise the runtime. However, for an agent to function, such access is often necessary. - **Localhost MCP Bridge**: The `tools/mcp-bridge` provides a local WebSocket and HTTP server for integration with local tools like Claude Code. This is limited to `localhost` and is generally considered safe. Overall, significant effort has been made to secure a high-risk operation within browser sandboxing mechanisms. The residual risks are largely inherent to the nature of running arbitrary code, even within a carefully designed sandbox.