The first complete 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, spins up JS sandboxes for scripting and full Linux VMs in WebAssembly for shell work, hosts personal client-side apps, and connects to a peer-to-peer network over WebRTC.
peerd is your AI peer.
The future of AI agents is web native. No servers. No janky browser MCP.
Native AI apps drive your browser from outside.
peerd lives inside it.
peerd is a browser extension that turns your browser into an AI agent harness. It reads pages, clicks links, fills forms, and runs shell commands in real Linux VMs running in WebAssembly. Bring your own model, no service, no subscription, no middleman.
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.
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.
Not a browser-driving agent.
Playwright MCP, browser-use, BrowserBase 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.
Not a cloud operator.
ChatGPT Operator and Anthropic's Computer Use run in datacenters with their own browsers and their own credentials. peerd runs locally with yours. Your conversation, sessions, and API key never leave your machine.
The browser
is the
runtime, the network, the hypervisor, and the operating system.
Cloud AI browsers ask you to switch your default. Native agent apps install an app and drive a browser from outside through Playwright-style automation, never inheriting the logins, cookies, or tabs you already have. Both reimplement what the browser already does, session state, the DOM, hardware access , only worse.
A browser-native harness doesn't just run in the browser. It uses the browser, as a runtime, as a hypervisor, as a security model. That's the bet.
// peerd inherits:
Process isolation, same-origin policy, site isolation, the renderer sandbox, Content Security Policy. We didn't build any of it. We use it.
Not a remote shell. Not a fake terminal. A real Linux VM compiled to WebAssembly, running entirely in your browser. 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.
peerd ships the wedge at launch: Ed25519 cryptographic
identity (did:key), content-addressed
peerd://<did>/<sha256> URIs,
signed app bundles transferred peer-to-peer over WebRTC
with paste-code pairing. The d in peerd is for
distributed.
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.
Click the mic icon next to any text input. Moonshine over WebGPU; audio never leaves your device. Terminal agents can't ship voice without a server upload or a separate native helper. peerd just listens.
Three structural commitments.
Not policy.
Webpages can carry hidden instructions designed to hijack an agent. peerd doesn't defend with one clever filter — it defends with three structural commitments: inheritance from the browser, 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 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.
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, JS Sandboxes, and
Apps all route through the same gates.
// what's structural, not policy
The browser gives the VM no IP stack — SSH, raw
TCP/UDP, ICMP, SMTP, BitTorrent, 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.
// what isn't, honestly
HTTPS to private-network IPs
(192.168.x, ::1,
*.local) is still reachable — 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 ↗
// 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.
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, no platform in the middle. The infrastructure for peer-to-peer is already deployed and battle-tested across five billion devices. The use case for it is here.
AI agents are that use case. As their numbers grow and their capabilities deepen, they'll need ways to find, talk to, and transact with each other. They'll spawn swarms and exit faster than any platform can mediate. An agent economy needs new social networks, new payment rails, new everything, built for peers, not for platforms.
The stack is already there. At V1 launch peerd ships
Phase 0 of peerd-distributed:
Ed25519 cryptographic identity (did:key),
content-addressed peerd://<did>/<sha256>
URIs, signed multi-file app bundles transferred chunk by
chunk over WebRTC data channels with paste-code (or QR)
pairing. No DHT yet, no async messaging yet, but
two browsers can already exchange a signed app with no
server in the data path. The "real web 3.0" claim moves
from aspirational to demoable.
From there: bootstrap signaling so users don't paste codes. A minimal Kademlia DHT and passkey-bound persistent identity, the beat that backs the "real web 3.0" claim. Async messaging over social-graph relays, the App Store as a federated social app, and the abuse-mitigation maturity that turns this from a demo into infrastructure.
The browser is the runtime and hypervisor.And peerd is the real web 3.0.
The proof starts at launch.
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.
Do I need a paid API key?
At launch, yes, peerd uses your model provider's API and you bring the key. Anthropic and OpenRouter are the launch adapters; native OpenAI and Ollama (free, local) adapters follow shortly. Further out: in-browser inference via WebGPU and WebNN acceleration, no API key, no provider bill.
Can the agent see my bank, my email, my password manager?
Not by default. A sensitive-site denylist ships pre-loaded with hundreds of banks, healthcare portals, password managers, and identity providers. Editable from settings. You can also drop the agent into Paranoid mode, nothing happens without explicit per-action confirmation.
How is the Linux VM not a security hole?
The VM runs in WebAssembly inside the browser sandbox. Its network is HTTPS-only, gated by peerd's egress allowlist, 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 raw sockets to any code. 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 in V1; we're migrating to v86 (BSD-2-Clause) down the road for a fully open stack.
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, Phase 0 of peerd-distributed ships
browser-to-browser signed bundles at V1 launch, with
async messaging in subsequent phases. 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 wedge at V1 launch and matures through
V2.x. Different scope, different audience, different
architecture.
More in the docs FAQ.
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 →Firefox support ships in v1.x.
Watch the release →Run from source. No build step, the repo is the extension.
git clone https://github.com/NotASithLord/peerd.git