Most agent frameworks run the orchestration loop server-side. The LLM calls tools, the server executes them in a sandbox, and the client gets a response. AG2B flips this. The agent loop runs in the browser. Tools execute client-side. The server becomes an optional LLM proxy.
This architectural shift moves the security perimeter from server sandboxes to browser isolation. The browser is an untrusted client. You cannot trust the agent’s decisions because a malicious user can modify the JavaScript, skip tool calls, or inject fake tool results.
The Show HN post launching AG2B cites B2B pressure as the driver: “Add an AI feature, yesterday!” Most agent frameworks pull in a whole stack when you run server-side. AG2B removes that infrastructure requirement by moving orchestration to the client. A live demo at ag2b-example.vercel.app shows a working Kanban board where the agent drives the entire interface end to end.
How the Browser Runtime Works
AG2B runs the agent loop in JavaScript. The flow:
- User sends a prompt to the agent
- Agent forwards prompt to LLM (via server proxy or direct API call)
- LLM responds with tool calls
- Agent executes tools in the browser’s JavaScript runtime
- Tool results feed back into the next LLM call
- Loop continues until the agent produces a final text response
Tools are JavaScript functions registered in a Scope. The agent exposes these to the LLM via function calling. The LLM picks tools, the browser executes them, and the agent manages state in memory.
import { Agent, OpenAiProvider, Scope, Tool } from '@ag2b/core';
import z from 'zod/v4';
// Server proxy holds the API key, not the browser
const agent = new Agent({
provider: new OpenAiProvider({ baseURL: '/api/llm' })
});
const setBackground = new Tool({
name: 'setBackground',
description: 'Change the page background color.',
parameters: z.object({
color: z.string().describe('Any valid CSS color')
}),
handler: ({ color }) => {
document.body.style.backgroundColor = color;
}
});
const appearance = new Scope({
name: 'appearance',
tools: [setBackground]
});
agent.scopes.register(appearance);
await agent.chat('Make the page feel like a sunset, use oklch.');The baseURL: '/api/llm' pattern proxies LLM calls through your server. The browser never sees the API key. The server can rate-limit, log requests, and enforce policies.
WebMCP: Bridging Local Tools into the Browser
WebMCP (Web Model Context Protocol) is the mechanism for exposing tools that live outside the browser. It defines a protocol for tool discovery and invocation across origins.
Without WebMCP, a browser-based agent can only call JavaScript functions defined in the same origin. WebMCP lets you expose tools from:
- Local development servers
- Desktop applications
- Browser extensions
- Other origins with CORS headers configured
The protocol handles:
- Tool schema discovery
- Parameter validation
- Cross-origin invocation
- Response serialization
This solves the “how do I let the agent call my local API” problem without requiring server-side orchestration. The agent discovers tools via WebMCP, the browser enforces same-origin policy or CORS, and the tool executes wherever it lives.
WebMCP does not bypass CORS. It relies on the browser’s existing security model. If a tool lives on a different origin, that origin must explicitly allow cross-origin requests via CORS headers.
Security Boundary Shifts
Server-side agents run in a trusted environment you control. Browser-side agents run in an untrusted client the user controls.
| Security Boundary | Server-Side Agents | Browser-Side Agents (AG2B) |
|---|---|---|
| Execution isolation | Docker, VMs, sandboxed processes | Browser tab sandbox (no file system access, same-origin policy enforced, but vulnerable to XSS if credentials stored in LocalStorage) |
| Credential storage | Environment variables, secret managers | Server proxy (required for production) or LocalStorage (XSS risk, not recommended) |
| Tool exposure | Server controls which tools exist | Client registers tools, WebMCP exposes external ones (CORS-enforced) |
| Prompt injection impact | Can compromise server, access internal APIs | Can compromise client, access user data in browser, limited by same-origin policy |
| Network boundary | Server makes outbound calls | Browser makes outbound calls, subject to CORS |
| State persistence | Database, Redis, file system | In-memory (lost on refresh) or IndexedDB |
The browser tab sandbox provides strong isolation between tabs and origins. A malicious prompt cannot escape the tab to access other tabs or the file system unless the tool explicitly grants that access via a browser API (like the File System Access API). But the browser sandbox does not protect against XSS. Any script on the page can read LocalStorage, modify the DOM, or intercept tool calls.
Credential Management: The Proxy Pattern
Server-side agents store API keys in environment variables or secret managers. Browser-side agents have three options:
-
Store credentials in LocalStorage or SessionStorage: Simple but exposes keys to XSS attacks. Any script on the page can read them. Not recommended for production.
-
Proxy all LLM calls through a server: The server holds the API key, the browser sends prompts to the server, the server forwards them to the LLM. Required for production use.
-
Use short-lived tokens: The server issues a token valid for one session, the browser uses it, the token expires. This limits exposure but requires token refresh logic.
The proxy model is the safest default. The browser never sees the API key. The server can rate-limit, log requests, and enforce policies. The downside is you need a server.
The proxy flow in practice:
Browser (AG2B Agent) -> POST /api/llm (your server)
|
v
Server retrieves API key from environment
|
v
POST https://api.openai.com/v1/chat/completions
|
v
Response streams back to browserThe server acts as a credential boundary. The browser sends prompts, the server authenticates with the LLM provider, the response streams back. The agent loop still runs client-side, but the LLM never sees the client directly.
Prompt Injection and Tool Exfiltration
A malicious prompt can instruct the agent to call tools in ways you did not intend. In a browser-side agent, this might mean:
- Calling a tool that sends user data to an attacker-controlled endpoint
- Using a WebMCP tool to exfiltrate data from a local API (if CORS allows it)
- Modifying the DOM to phish credentials
- Calling a tool repeatedly to exhaust rate limits
The browser’s same-origin policy limits some of this. The agent cannot make cross-origin requests unless the target server allows it via CORS. But if the agent has access to a tool that makes requests (like a fetch wrapper), the tool can bypass CORS by running on the server.
Concrete example: If the agent has access to a fetch-wrapper tool, a malicious prompt could instruct it to POST user data to attacker.com. The browser same-origin policy does not block this because the tool itself makes the request from the server origin (if proxied) or the browser origin (if not).
Defense strategies:
- Scope tools tightly: Only register tools the agent needs for the current task
- Validate tool inputs: Use Zod schemas to enforce parameter constraints
- Log tool calls: Track what the agent does, especially for sensitive tools
- Rate-limit tool execution: Prevent runaway loops
- Require user confirmation: For destructive or sensitive tools, prompt the user before executing
Never expose a generic fetch tool. Only expose domain-specific tools with explicit purposes.
AG2B’s Scope primitive helps here. You can register different scopes for different tasks and only expose the tools the agent needs. This reduces the attack surface.
State Persistence and Tab Lifecycle
Server-side agents persist state in databases or Redis. Browser-side agents lose state when the tab closes or refreshes unless you explicitly persist it.
Options for state persistence:
- In-memory only: Fast, simple, but lost on refresh. Fine for single-session tasks.
- SessionStorage: Persists across page reloads within the same tab, lost when the tab closes.
- LocalStorage: Persists across tabs and sessions, but limited to 5-10 MB and vulnerable to XSS.
- IndexedDB: Larger storage, structured data, but more complex API.
- Server sync: Send state updates to the server, restore on page load. Adds latency but survives tab closure.
For long-running agents, you need server sync or IndexedDB. For short tasks, in-memory state is fine.
Architecture Comparison
Server-Side Agent (Traditional)
Client -> Server (Agent Loop) -> LLM API
|
v
Tool Execution (Sandboxed)
|
v
Database / Internal APIsBrowser-Side Agent (AG2B)
Client (Agent Loop) -> Server (LLM Proxy) -> LLM API
|
v
Tool Execution (Browser Sandbox)
|
v
DOM / LocalStorage / WebMCP Tools (CORS-enforced)WebMCP Tool Exposure
Browser (AG2B Agent) -> WebMCP Discovery Request -> Local Server / Extension
|
v
Tool Schema Response
|
v
Browser (AG2B Agent) -> WebMCP Tool Invocation -> Tool Execution (CORS-enforced)The server-side model centralizes control. The browser-side model distributes it. The trade-off is infrastructure complexity versus security guarantees.
Attack Surface Summary
Browser-based agent orchestration introduces specific vulnerabilities that do not exist in server-side architectures:
Tool exposure and CORS enforcement
- WebMCP relies on CORS headers. If the local tool server does not set CORS headers, the browser blocks the request. This is a feature, not a bug. It prevents accidental exposure.
Credential storage in untrusted clients
- Credentials must be proxied through a server. Storing API keys in LocalStorage exposes them to XSS attacks. Any script on the page can read them.
Prompt injection leading to data exfiltration
- Defense: Scope tools tightly, validate inputs with Zod schemas, log all tool calls, rate-limit execution, require user confirmation for sensitive tools. Never expose a generic fetch tool.
Browser sandbox limitations compared to server isolation
- Browser tab sandboxes isolate tabs from each other and from the file system. But they do not protect against XSS within the same origin. A malicious script can read LocalStorage, modify the DOM, and intercept tool calls.
State loss on tab closure or refresh
- State is lost on refresh unless you persist it to SessionStorage, LocalStorage, IndexedDB, or sync it to a server. For long-running agents, server sync is the safest option.
Technical Verdict
Architectural Verdict
Use AG2B when you need to ship client-side AI features fast, the agent manipulates browser state, and you can tolerate the security trade-offs of running orchestration in an untrusted client. The browser sandbox provides strong isolation between tabs, but you lose the ability to trust the agent’s decisions. Always proxy LLM credentials through a server.
Avoid it when the agent needs access to server-side resources, handles sensitive data, or makes decisions that affect other users. In those cases, server-side orchestration with proper sandboxing is the safer choice.
The WebMCP protocol is the interesting piece here. It solves the tool exposure problem for browser-based agents without requiring server-side orchestration. CORS enforcement means you cannot accidentally expose tools to malicious origins, but you also cannot call tools on origins that do not explicitly allow it. If you are building tools that need to work across origins or integrate with local development environments, WebMCP is worth examining.
Security Verdict
Browser-based agent orchestration introduces specific attack vectors that do not exist in server-side architectures. Here is the risk breakdown:
High Risk: Credential Storage
- Storing API keys in LocalStorage or SessionStorage exposes them to XSS attacks. Any malicious script on the page can read them. Safeguard: Always proxy LLM calls through a server. Never store API keys client-side in production.
Medium Risk: Tool Exfiltration via Prompt Injection
- A malicious prompt can instruct the agent to call tools in unintended ways, such as POSTing user data to an attacker-controlled endpoint. Control: Never expose a generic fetch tool. Only expose domain-specific tools with explicit purposes. Validate all tool inputs with Zod schemas. Log all tool calls. Require user confirmation for sensitive tools.
Medium Risk: CORS Bypass via Tool Wrappers
- If the agent has access to a tool that makes server-side requests (via a proxy), the tool can bypass browser CORS restrictions. Defense: Do not expose tools that make arbitrary HTTP requests. Only expose tools that call specific, whitelisted endpoints.
Low Risk: Cross-Tab Escape
- The browser tab sandbox isolates tabs from each other and from the file system. A malicious prompt cannot escape the tab to access other tabs or the file system unless the tool explicitly grants that access via a browser API. Control: Do not expose tools that use the File System Access API or other privileged browser APIs unless absolutely necessary.
Low Risk: State Exfiltration via WebMCP
- WebMCP tools are CORS-enforced. The agent cannot call a WebMCP tool on a different origin unless that origin explicitly allows it via CORS headers. Safeguard: Ensure WebMCP tool servers set strict CORS headers. Only allow requests from trusted origins.
Overall Security Posture: Browser-based agent orchestration is safe for UI manipulation and client-side automation. It is not safe for handling sensitive data, making server-side decisions, or exposing tools that can affect other users. The proxy pattern for credential management is required. Tool scope must be tightly controlled. Prompt injection is a persistent risk that requires defense in depth.
Source Links
- AG2B Documentation (Primary source, accessed May 2026)
- Show HN Discussion (May 28, 2026)
- Live Demo: Kanban Board (Interactive example)