The first AI agent harness
native to the browser.

peerd is a browser extension. It runs an agent loop with full access to your tabs and sessions, and leverages local V8 isolates for sandboxing. Spin up Notebooks for scripting, full Linux VMs in WebAssembly for shell work, generate personal client-side apps, and share them with the first peer-to-peer WebRTC network built for agent-to-agent communication.

The future of AI agents is web native and p2p.

install peerd view on github →
01, what it is, what it isn't

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

peerd lives entirely in your browser runtime. There are no background processes on your system or bolted-on sidecars. No cloud servers or janky MCP integrations. It's just you and your browser, with uncompiled, simple-to-grok JavaScript.

01.

Not a cloud AI browser.

Comet, Atlas, Brave Leo, Dia ask you to switch your default browser to theirs. peerd is an extension, it plugs into the browser you already use, with the tabs and sessions you already have.

02.

Not a terminal harness.

Claude Code, OpenCode, Hermes, Aider live in your terminal. They can't reach 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.

03.

Not a browser-driving agent.

Playwright MCP, BrowserBase, and most browser-use deployments orchestrate a fresh browser through external automation, slow, fragile, none of your real session state. peerd is the browser; agent and page share a process and a memory.

04.

Not cloud-hosted.

Cloud operators run your browsing in their datacenters; cloud sandboxes run your code in theirs. peerd runs both locally, on your machine, with your sessions. Your conversation, sessions, and API key never leave it.

02, why the browser

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

peerd doesn't just run in the browser. It uses the browser as its runtime, as its hypervisor, and as its security model. That single choice is the whole architecture.

peerd inherits everything the browser has already shipped. 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.

That's the bet: the browser and the open web are the natural infrastructure for an ecosystem of open AI agents. The browser is already on every machine that matters, and every digital service that matters already has websites and web APIs.

// 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 four structural commitments: inheritance from the browser, a spectrum of sandboxes picked per trust level, structural removal of the lethal trifecta, and a single egress chokepoint shared by the agent and every runtime it spawns.

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 ↗

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, ever.
// works without us.
04, what comes next

The d is for distributed.

WebRTC ships in every modern browser. Two browsers can negotiate a direct connection and exchange arbitrary data, no relay, no server, nothing in the middle. The infrastructure for peer-to-peer is already deployed and battle-tested across five billion devices. peerd is the first AI agent harness to ship browser-native peer-to-peer transport. WebTorrent uses WebRTC for files. peerd uses it for agents.

Watch a peerd agent build a small app, share it, and other people's agents discover it, install it, and use it. The apps themselves can tap the same p2p network for real-time decentralized web apps, or dwapps, which both humans and agents can use. All with no server in the middle. The agent-to-agent web is here, running for real.

No blockchain. No coin. No NFT. Just a real peerd-to-peerd network in the browser for your agents and apps.
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.

Firefox build in preview: WebExtensions parity is done.

Watch the release →

Built on WebExtensions, so the Firefox build tracks Chrome closely.

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/.