This is largely a solo side project I've been building for only a short time, but informed by a career that spans web dev, AI, and P2P systems. I'm opening it up fully today for the first time as an early developer preview.

* Repo: https://github.com/NotASithLord/peerd * General info and docs: https://peerd.ai

The technical architecture is the product.

peerd started from a question the entire industry seems to be asking: what should the sandbox substrate be for AI agents?

Browsers have spent decades defending against hostile code, hostile documents, hostile networks, and hostile users. A lot of agent infrastructure ends up rebuilding those pieces of isolation, permissioning, networking, UI, and sandboxed execution that the browser already has.

peerd's architectural bet is to use that substrate directly, on your machine. Cloudflare aggressively markets V8 isolates as the best substrate for AI agents and charges for them as Dynamic Workers. They're already running in every Chromium tab on your machine, free, with no round trips.

That means the premise goes further than web automation. Workload execution happens in the browser too: headless JS workers, visual notebooks, personal client-side apps, and full Linux VMs via WebAssembly. Everything is self-contained in the browser via a web extension — no sidecar, no local server, no localhost daemon, no MCP gateway, no backend, no telemetry, no account. Written in no-build vanilla JS with minimal non-browser dependencies. The repo is the extension: clone it, load extension/ unpacked, you're running. You don't have to switch to a separate AI browser to use it. Works with Anthropic, OpenRouter, and local Ollama today. Experimental browser-native inference via WebGPU runs Gemma in-tab — no provider in the path at all.

peerd also includes an early P2P agent/app layer as its answer to "A2A." The preview build ships the transport and basic protocol: two peerd instances can discover each other through bootstrap/signaling, establish a WebRTC connection, and exchange signed messages and app bundles directly. The goal is for agent-to-agent delegation and collaboration to ride on those same signed channels without a platform or middlemen owning the path between peer(d)s.

All of that creates a lot of capability surface. Security is the part where peerd needs the most scrutiny. peerd does introduce the classic prompt-injection danger zone: private data, untrusted content, and outbound network access. The mitigation is structural. The main agent does not directly receive raw page dumps or get low-level DOM-driving tools. A disposable browser runner handles page inspection and interaction in a fresh context with no model key, no long-term memory, and no general egress tools. The model key stays in the extension service worker. Provider/API egress goes through allowlisted wrappers, and open-web/VM network paths go through chokepoints with private-network blocking, denylist checks, and audit trails. P2P connections are separate signed channels. None of that make it magically safe. It is an early design I'm trying to make concrete enough that people can inspect it, break it, and improve it.

Honest limitations: this is an experimental developer preview. GitHub install is the only path today. Chrome Web Store and Firefox AMO submissions are still pending. The P2P core ships, but needs real-peer testing beyond what I can do alone. The WebVM backend currently uses CheerpX, which works very well but is a commercial dependency and not the most ideologically pure part of the stack. Some pieces stay preview-only until they have more miles on them and the extension stores complete review.

I'll be in the comments for a bit. Scrutiny welcome.