The first browser-native
agent harness.

peerd turns your existing browser into an agent workstation. The full agent loop runs inside a browser extension: model routing, tools, memory, page control, sandboxes, local compute, permissions, and audit. No cloud browser. No sidecar process. No MCP gateway. Your tabs, your sessions, your model keys, your machine.

Agents use your real browser, run notebooks and Linux VMs in WebAssembly, build client-side apps, review their work, and share signed workflows peer-to-peer.

Install from Chrome Web Store Install for Firefox View on GitHub Read the docs
01, what it is, what it isn't

Native & cloud AI apps drive your browser from outside.
peerd lives inside it.

peerd lives entirely in your browser runtime: no background process on your machine, no sidecar, no cloud server, no external tool broker between the agent and the browser. Just you, your browser, and uncompiled, simple-to-grok JavaScript.

01.

Not a cloud AI browser.

Comet, Atlas, Brave Leo, and Dia run your browsing on their servers. peerd runs entirely on your machine, in the browser you already use.

02.

Not an AI browser you move into.

Those vendors ship a whole new browser and ask you to switch. peerd is an extension: it adds the agent to your current browser, with your tabs, sessions, and extensions intact.

03.

Not a terminal-only harness.

Claude Code, OpenCode, and Aider live in your terminal. They can't see the page you're looking at, fill the form on your screen, or use the session you logged into. peerd can.

04.

Not a browser-driving automation server.

Playwright MCP and Browserbase drive a fresh headless browser over external automation: slow, fragile, none of your real session state. peerd is the browser; agent and page share a process.

05.

Not a hosted operator.

Cloud operators run your browsing in their datacenters; cloud sandboxes run your code in theirs. peerd runs both locally, with your sessions and your model keys, on your machine.

06.

Not an MCP gateway with a browser attached.

peerd doesn't broker browser agency through a cloud tool server. The browser itself is the harness; MCP is optional interop, not the architecture.

peerd is the browser-native harness itself.

02, why the browser

The browser
is the runtime, the network, the hypervisor, and the operating system.

The first generation of agents lived in chat boxes. The second lives in IDEs, terminals, and cloud sandboxes. peerd is betting the next agent runtime is the browser itself: the place where you already have your apps, sessions, documents, permissions, identity, and workflows. peerd doesn't put an agent near the browser. It makes the browser the harness.

So peerd doesn't just run in the browser. It uses the browser as its runtime, as its hypervisor, and as its security model. Zero lines of cryptographic code. Zero lines of sandboxing code. Zero lines of process-isolation code. The browser already wrote them, and hardened them for decades against the most hostile software environment on earth: the open web.

The agent control plane, permissions, audit, storage, and execution environment all live in the browser; models can be local or remote, your choice. That's the bet: the browser and the open web are the natural infrastructure for an ecosystem of open AI agents, already on every machine that matters.

// the agent workstation has five primitives:

Act. Use tabs, sessions, pages, and web apps through mediated browser tools.

Think. Route models, spawn subagents, use memory, plan, review, and operate under budget and permission limits.

Compute. Run notebooks, JS workers, sandboxes, and Linux VMs in WebAssembly.

Build. Create artifacts, local apps, and reusable workflows.

Share. Package and sign apps and workflows for peer-to-peer sharing.

// peerd inherits:

Why pay Cloudflare for V8 isolates when you can already run them locally, for free, with no latency? Or leverage Firefox's SpiderMonkey equivalent primitive, Realms. peerd works with both. With millisecond start times and highly customizable environment configurations from HTML & OPFS exposure to WASM, it's the ideal compositional foundation for agent workloads.

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 isn't just for daemon, it's 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 is local today: tap the mic by any input and Moonshine transcribes over WebGPU, audio never leaving the tab. Web LLM is next: in-browser inference over WebGPU and WebNN, so the whole agent loop can run with no provider in the path. The browser is already a model runtime, and peerd uses it.

connecting… just you
03, security

Secure by construction.
Not a filter you can talk around.

Webpages can carry hidden instructions designed to hijack an agent. peerd doesn't defend with one clever filter. It defends with five structural commitments: inheritance from the browser, a spectrum of sandboxes picked per trust level, structural removal of the lethal trifecta, a single egress chokepoint shared by the agent and every runtime it spawns, and credential isolation by construction — your model key kept where no sandbox can reach it.

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 an isolate. Cloudflare hardens the V8 isolate at datacenter scale and meters it by the invocation. 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; 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

peerd's main agent never reads raw page content. A disposable runner does: fresh context, no memory, no keys, no egress tools, no spawn, no code-eval. Even if injected, it has nothing to exfil through. Untrusted input and valuable capabilities are never in the same model context.

// defense in depth on top

Every DOM read wraps its output as <untrusted_web_content>; the runner's summary is itself wrapped <untrusted_runner_summary> on the way back. An injection has to defeat two model contexts with two different framings to win. Full writeup in the docs ↗

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.

And no third-party gateway. Provider traffic goes from your browser to the provider you configured. Application integrations, when they ship, go from your browser to the application's API. There is no peerd cloud service in the data path because there is no peerd cloud service.

// what isn't, honestly

HTTPS to private-network IPs (192.168.x, ::1, *.local) is still reachable, because the denylist matches host strings, not CIDR. A CIDR-aware private-IP gate is going into webFetch ahead of the denylist; code, not policy. Arbitrary-public-host C2 isn't solvable by any IP filter. That's bounded by the runner having no web tools at all. More in the docs ↗

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 with something to intercept.

peerd-egress/fetch/safe-fetch.js ↳ provider-allowlist gate 
// 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.
// no telemetry, no backend, ever.
04, what comes next

The d is for distributed.

Once an agent can build local apps and workflows, the next step is sharing them: package, sign, fork, and send them straight to another peer. peerd is the first AI agent harness to ship browser-native peer-to-peer transport. WebRTC is already in every browser, battle-tested across five billion devices. WebTorrent used it for files; peerd uses it for agents and the things they build.

Watch a peerd agent build a small app, sign it, and share it: other people's agents discover it, install it, and run it, peer to peer, no server in the middle. An agent-native app and workflow network, agents sharing runnable capabilities, not a feed of posts.

No blockchain. No coin. No NFT. Signed apps and workflows shared peerd-to-peerd.
The real Web 3.0.
05, questions

FAQ

Where does my data go?

To the model provider you configured. That's it. peerd has no backend. Your conversations, vault contents, and API key never leave your machine except as outbound calls to the model you picked.

BYOK and "no backend", but my prompts still go to the model, right?

Right, and we won't pretend otherwise. Your prompt (which can include page content) goes to the provider you chose: Anthropic, OpenRouter, or your own local Ollama, where nothing leaves the machine. There is no peerd server in the path, ever. "Client-side" means we can't see it; pick the provider whose terms you trust, or run local.

Do I need a paid API key?

Anthropic, OpenRouter, and Ollama (free, local) all ship today. Bring whichever key you want, or run local with no key and no bill. In-browser inference over WebGPU is next.

Can the agent see my bank, email, password manager?

Not by default. A sensitive-site denylist ships pre-loaded with hundreds of banks, health portals, password managers, and identity providers, editable in settings. Turn on Confirm before actions and nothing happens without your per-step approval.

Isn't a browser agent with broad permissions exactly the prompt-injection risk everyone's writing about?

Yes, it's the problem we built around first. The agent that holds your keys never reads a page; a throwaway runner with no keys and no network does, and its output comes back fenced as untrusted. Even a perfectly injected page has nothing to steal through. The cloud agents put untrusted content and your credentials in one model context; peerd never does.

How is the Linux VM not a security hole?

The VM is sandboxed by the tab, like everything else peerd runs in tabs, the same V8 isolate primitive Cloudflare uses for their AI agent code execution platform. Its network is HTTPS-only, gated by peerd's egress allowlist, the same gate the agent itself uses. The VM cannot open raw sockets, port-scan, SSH out, or pivot to your local network because browsers don't expose those capabilities to any code in any tab. The agent can do anything in the VM and your machine is not in the threat model. Structural, not policy.

How is this different from Claude Code / OpenCode / Hermes?

Those live in your terminal. They can't see the page you're looking at, fill the form on your screen, or use the session you logged into. peerd lives in the browser; everything the browser sees, the agent sees. See section 01 for the full comparison matrix.

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 peerd Labs 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 0.x, experimental beta. There's no "V1" yet; 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 private messaging and a DHT, with async (offline) messaging the next phase. Shipping MCP would dilute the thesis and add an exfiltration vector the rest of the security model exists to close.

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.

06, install peerd

Add peerd to your browser.

Free, Apache 2.0, no account. Bring your own model key.

Install from the Chrome Web Store.

Add peerd to Chrome →

Works on any Chromium browser, Chrome, Edge, Brave, Arc, Vivaldi.

Install from Firefox Add-ons.

Add peerd to Firefox →

The same WebExtension, on the standard APIs Chrome and Firefox share.

Run from source. No build step, the repo is the extension.

git clone https://github.com/NotASithLord/peerd.git

Then open chrome://extensions, turn on Developer mode, click Load unpacked, and select the repo's extension/ folder. You'll need one API key, from Anthropic or OpenRouter. Full docs: docs/.