peerd shows why browser agents are a governance problem first
peerd is best read as a browser-agent governance sample: local custody, actor isolation, egress control, scoped grants, and auditability before autonomy.
A browser-native agent is a governance problem before it is a productivity feature. If an agent can operate inside a logged-in browser, it sits beside cookies, internal tools, cloud consoles, customer data, and pages written by strangers. The demo question—can it click?—is almost irrelevant. The governance question is whether the system limits what compromised reasoning can reach.
peerd is an early but useful artifact because it is built around that question. It is local-first, BYOK, extension-based, and explicit about its status as 0.x experimental software. More importantly, it uses the browser platform as part of the trust model rather than pretending the model alone can police itself.
Custody changes the design
Hosted browser agents centralize the execution environment. peerd moves execution into the user’s own browser. That keeps the developer out of the data path, but it also means the extension must be evaluated as high-trust software. Local custody is not a free safety win. It is a different responsibility model.
The useful pattern: authority is not evenly distributed
peerd separates the orchestrator from the actors that touch environments. A tab actor operates a tab. A VM actor operates a VM. A notebook actor operates a notebook. These actors are keyless and narrower. The service worker holds the privileged routes, rechecks requests, and records audit events.
That shape matters more than any single feature. Prompt injection becomes less catastrophic when hostile content lands in a context without provider keys, without arbitrary network access, and without every browser write tool.
Three controls to copy
- A real egress chokepoint. Credentialed model calls should not be able to redirect or drift to lookalike origins.
- Origin- and session-scoped grants. “Approve once” must not become “approve everywhere”.
- Audit logs that support investigation. peerd’s recent hash-chain work is not proof against same-origin compromise, but it is better than unaudited automation.
Where peerd should sit in a stack
Use it as a local research and workflow prototype, not as a regulated enterprise automation layer. It is useful for studying browser-agent boundaries, testing local-first custody, and exploring how a side-panel agent can work with real tabs. For CI, use Playwright. For enterprise workflow control, use identity and policy systems. For long-running cloud jobs, use isolated remote machines.
Evaluation checklist
- Separate browser profile.
- Test accounts only.
- Limited and revocable model keys.
- Confirmation enabled for actions.
- Sensitive-site denylist checked before real browsing.
- Audit log reviewed after every run.
- No production admin consoles during early testing.
Conclusion
peerd should not be sold as a finished assistant. Its value is sharper: it is an implementation of browser-agent governance ideas while the field is still fluid. If agents are going to enter real browsers, the winning designs will look less like chat demos and more like permission systems. peerd points in that direction.