The browser-native
agent harness
peerd adds a general-purpose agent to the browser you already use, inside its tabs, sessions, security boundaries, and local compute.
It can turn websites into reusable clients, run code and compiled tools, boot Linux VMs in WebAssembly, build browser Apps, and connect agents peer-to-peer over WebRTC on the preview channel.
Runs in your browser. Sandboxed from the rest of your computer.
Chrome Web Store and Firefox AMO: coming soon.
Local agents can access your whole computer.
Remote agents live in someone else's.
peerd runs inside your browser.
Some agents run in the cloud and control a browser from afar. Others run on your computer with access to your files, passwords, terminal, and signed-in sessions. peerd takes a third path: it runs locally, inside the browser's sandbox.
Not another browser to switch to.
peerd is an extension. It adds the agent to the Chrome or Firefox you already use, with your tabs, authenticated sessions, and extensions intact.
Not a remote browser session.
Remote harnesses operate another browser somewhere else, then reach back through a cloud session or tool connection. peerd works in the browser and sessions already in front of you.
Not a process with the keys to your computer.
Running on your device is not automatically safe. Many local agents can reach your terminal, files, passwords, and browser. peerd stays inside the browser sandbox.
Not a maze of tool servers.
Pages become reusable clients, and code runs in browser sandboxes. Separate actors handle separate jobs, so one process does not get the keys to everything.
The browser
is the
runtime, the network, the hypervisor, and the operating system.
Your browser already contains the applications, authenticated sessions, identity, storage, networking, UI, and increasingly the compute an agent needs. It also carries decades of scar tissue from running powerful software against hostile content. peerd treats those two facts as one architecture: the browser is the harness.
peerd builds on the browser's existing walls: separate sites, sandboxed frames, Workers, permission prompts, and browser-controlled gateways. peerd adds limited toolsets, network checks, and an audit trail.
The current extension keeps its control plane, permissions, audit, storage, and execution environments in the browser. Models can be local or remote; you choose the provider. It can do a lot without getting the keys to everything.
// five things peerd can do:
Act. Use tabs, sessions, pages, and web apps through browser-controlled tools.
Think. Route models, spawn subagents, use memory, plan, review, and operate under budget and permission limits.
Compute. Run notebooks, JS workers, compiled WASI tools, and Linux VMs in WebAssembly.
Build. Create artifacts, local apps, and reusable workflows.
Share. Let browser agents find each other and exchange signed apps, workflows, and messages over the preview P2P network.
// peerd inherits:
Run them locally, for free, with no latency. Firefox exposes the same primitive through SpiderMonkey Realms; peerd works with both. Millisecond start times, configurable from HTML & OPFS exposure to WASM.
Not a remote shell. Not a fake terminal. A real Linux VM compiled to WebAssembly, running in a tab, inheriting the tab's enhanced isolation layered on top of the V8 isolate. The agent can run any command in it, including destructive ones. The worst case is the VM breaks and you start a new one. Your home directory is not in the threat model. Each VM is its own tab: own context, watchable, killable, attachable from any chat session. Spin up several in parallel; the agent addresses them by label.
No OAuth dance, no credential storage, no session pools. The DOM is to peerd what LSP is to a coding agent: accessibility tree, mutation observers, ARIA roles, computed styles, real cookies, real headers. Semantic structure, not scraped HTML.
The d in peerd is for distributed. peerd runs a
real browser-to-browser network
where all the logic lives in the extension and the only
servers are stateless nodes that introduce peers, then
drop out of the data path. Today: Ed25519 identity
(did:key), content-addressed
peerd:// bundles, an N-peer WebRTC mesh with
gossip and genuinely-private 1:1 messaging, and a Kademlia
DHT for discovery.
WebCrypto AES-GCM encrypts the vault. WebAuthn passkeys unlock it. Subresource Integrity verifies every model and plugin download. Origin isolation keeps the extension's storage off-limits to pages. Zero lines of crypto code.
Voice can be transcribed locally with Moonshine, while the Ollama adapter connects to models running on your machine without a provider key. Cloud models remain available by choice. The live provider list is defined by the extension, not a promise frozen into this page.
Assume the page can fool the agent.
Limit what happens next.
Like the browser itself, peerd assumes pages can be hostile. It takes a defense-in-depth approach: filtering is one layer, but every other layer assumes something will eventually get through.
Inheritance.
Cloud agents build sandboxes from scratch. Native agents run as fully privileged OS processes. peerd is a browser extension, so it composes nearly three decades of browser platform development tackling untrusted code and content safety: per-tab process isolation, same-origin policy, site isolation, the renderer sandbox, CSP, opaque-origin iframes.
The crypto stack is the same story: WebCrypto AES-GCM, WebAuthn PRF, Subresource Integrity. peerd writes zero lines of cryptographic code.
A spectrum of sandboxes.
// the primitive is free
A sandbox is a sealed execution context built on a JavaScript isolate. Cloudflare leverages and markets V8 isolates at datacenter scale and meters them by the invocation for AI sandboxes. peerd gets the same primitive for free: it's already in every tab and every worker the browser runs.
// one boundary per trust level
peerd isn't stuck with one box. It picks the boundary by
trust: the agent's own scripts run in a language-sealed
Notebook; a compiled tool — a WASI binary: SQLite, a codec,
a language runtime — runs inside that same sealed worker
with zero ambient capability, seeing only the bytes it is
handed; code built for you, or delivered peer-to-peer,
runs in an opaque-origin iframe with a real origin
boundary and not even any chrome.* access; a full
POSIX program runs WASM-confined in a Linux VM. Untrusted
code never runs in a weaker sandbox than it needs.
The lethal trifecta, broken structurally.
// the failure mode
Simon Willison's lethal trifecta (June 2025): an AI combining private data + untrusted content + an outbound network path is one prompt injection from exfiltrating anything it can reach. PromptArmor disclosed live exploits against Google Antigravity (late 2025) and Anthropic's Claude Cowork (January 2026). Most browser-driving agents sit squarely in this failure mode.
// the structural fix
The main agent sends page work to a separate browser actor with only the tools for that tab. The actor has no model key, and model and tool calls go back through the extension's checks. Even if a page fools it, the actor does not get the vault or the keys to the rest of the system.
// defense in depth on top
Results are marked with where they came from. Tool limits, tab binding, Plan/Act mode, the denylist, network rules, and the audit log all live outside the model. The page may change what the model says, but it cannot talk those checks away.
One egress chokepoint, top to bottom.
// two gates
Provider traffic on a strict allowlist
(safeFetch). Open-web HTTP(S) on a
denylist (webFetch) blocking
bank/health/identity/password-manager origins. Both
audited on every call. WebVMs, Notebooks, and
Apps all route through the same gates.
// what's structural, not policy
The browser gives the VM no IP stack, so SSH, raw
TCP/UDP, ICMP, SMTP, BitTorrent, and custom C2 protocols
are not addressable. The extension's CSP pins plain
HTTP to your configured local Ollama only;
http:// elsewhere is blocked at the
manifest layer. HTTPS from inside the VM
(curl, wget, git)
is proxied through the same peerd-egress
webFetch gate the agent itself uses,
same denylist, same audit entry.
Key-bearing provider traffic goes from the extension to the provider you configured. Open-web reads, runtime assets, sandbox traffic, and preview P2P use separate paths with their own controls. The code and security documentation are the authority for each path.
// what isn't, honestly
No architecture turns model output into trusted code. Public web access still carries residual exfiltration risk, trusted skills remain trusted code, and users can deliberately grant powerful actions. peerd makes those boundaries inspectable and keeps the current limits explicit in its threat model.
Credential isolation by construction.
// where the key lives
Your model key never leaves the service worker. It's
decrypted from the vault there and only there, used to
build the Authorization header, and held
in memory the whole time. The plaintext key never
touches disk and is gone the moment the browser closes.
// where it never goes
No sandbox ever receives it. The Notebook, the App iframe, the Linux VM, the headless worker: none get the key, and none get an environment variable carrying it. They reach the network only by relaying through the same egress gate the agent uses. Untrusted code can't read a secret that was never placed where it runs. Isolation by architecture, not a credential proxy bolted in front.
// Hard egress allowlist for model-provider traffic. Even if the agent // is fully prompt-injected and tries to POST your conversation to an // attacker-controlled URL, this layer refuses. Fail closed. const HARDCODED_ALLOWLIST = Object.freeze([ 'https://api.anthropic.com', 'https://api.openai.com', 'https://openrouter.ai', 'http://127.0.0.1:11434', // local Ollama 'http://localhost:11434', ]); export const makeSafeFetch = ({ getAllowlist, auditLog }) => async (resource, init) => { const origin = resolveOrigin(resource); if (!getAllowlist().includes(origin)) { await auditLog({ type: 'egress_denied', origin }); throw new EgressDeniedError(origin); } return fetch(resource, init); }; // Open-web traffic (the agent's web tools + the VM's curl/wget) goes // through peerd-egress/fetch/web-fetch.js. Same audit log, denylist // gate instead of allowlist.
A2A is now P2P.
peerd-to-peerd agents with WebRTC.
A2A is becoming the language for agents to discover each other, exchange capabilities, and delegate work. Most implementations assume agents are hosted somewhere: a cloud service, enterprise platform, server process, or localhost daemon. peerd explores a different topology: true peer-to-peer A2A from the browser. Your personal browser agent can become a live peer: discoverable, callable, permissioned, auditable, and able to exchange signed apps and workflows directly over WebRTC, without a cloud host or middleman.
A2A is the protocol narrative. P2P is the topology. peerd's difference is that the agent endpoint can be the user's browser, not a hosted service. Most A2A connects cloud agents to cloud agents. peerd makes the user's browser a live agent peer. This is experimental, and shipping on the preview channel today.
Two browser agents meet. They exchange identities, discover signed apps and workflows, and can exchange messages, directly over WebRTC. All without a cloud host.FAQ
Where does my data go?
Most peerd data stays in the browser on your device. Model inputs go to the provider you choose; web tasks contact the sites you direct peerd to; optional feature files and preview P2P use their own documented paths. Vault secrets are only attached to their intended provider origin.
Does local-first mean no network traffic?
No. A useful browser agent makes network requests. Model calls go directly to the provider you selected, web work reaches the sites involved, and some optional features download runtime assets or join the preview P2P network. Local-first describes where the harness and product state live, not an offline claim.
Do I need a paid API key?
peerd supports BYOK cloud providers and a keyless local Ollama option. The extension's provider registry is the live source of truth, because supported providers and models change over time.
Can the agent see my bank, email, password manager?
Sensitive sites are blocked by default, and you can edit the list in Settings. Plan mode can read but cannot click, type, or submit. Act mode enables those actions through peerd's safety checks.
Isn't a browser agent with broad permissions exactly the prompt-injection risk everyone's writing about?
Yes. peerd assumes hostile content can steer reasoning. Page work goes to a separate browser actor. It has no model key and only gets tools for that tab. Model and tool calls go back through the extension's checks. Labels mark page content as untrusted, but security does not depend on the label alone.
How is the Linux VM not a security hole?
The WebVM runs inside a browser tab using CheerpX and WebAssembly, with its own browser-backed disk. It cannot directly reach files or the terminal on your computer. Network-capable operations pass through peerd's network gate and are recorded in the audit trail. The exact guarantees and residual risks live in the threat model.
How is this different from Claude Code / OpenCode / Hermes?
Terminal agents are local, but commonly get broad access to your terminal, files, passwords, and signed-in sessions. peerd starts from a different boundary: the browser contains the applications and sessions, while actors receive only the tools for their environment. See section 01.
Is peerd really open source?
Yes, Apache 2.0. The extension code lives at github.com/NotASithLord/peerd. CLA required for contributions; trademark held by Ariel Deschapell to prevent fork-confusion. The VM engine (CheerpX) is a commercial dependency today; we're migrating to v86 (BSD-2-Clause) down the road for a fully open stack.
Is peerd stable? What version is this?
peerd is shipping as a v0.x developer preview today: install from source on GitHub. The architecture is stable; the surface is still being polished against real-world use. Chrome Web Store and Firefox AMO releases are coming soon. The version stays 0.x until the surface stabilizes.
Why doesn't peerd support MCP?
MCP exists to bridge agents to tools they can't otherwise
reach. peerd doesn't need that bridge. Tabs replace MCP
for application access, the agent reads the live
DOM of any app you're logged into. fetch
replaces MCP for APIs. WebVM replaces MCP for shell.
WebRTC replaces MCP for agent-to-agent comms,
peerd-distributed already runs a browser-to-browser
network with direct messaging and a DHT on the preview channel.
The browser remains the primary capability surface rather than a
thin client for a separate tool broker.
How is this different from Claude in Chrome, Nanobrowser, Comet?
Those are mostly web-task automation tools focused on
"go do this thing on a website." peerd is the broader
developer agent harness, the browser-native
equivalent of Claude Code or OpenCode, with real Linux
VMs, voice, structural lethal-trifecta defense, and a
peer-to-peer module (peerd-distributed)
that ships its first wedge today and matures from there.
Different scope, different audience, different
architecture.
More in the docs FAQ.
Add peerd to your browser.
Experimental 0.x, Apache 2.0, no account. Bring a supported model key or use local Ollama.
Run from source. No build step, the repo is the extension.
git clone https://github.com/NotASithLord/peerd.git
Coming soon to the Chrome Web Store.
Coming soon to Firefox Add-ons.