Before the browser agent drives, write the permission lease

There is a moment in every browser-extension install where Chrome warns you, in plain language, that the thing you are about to add can "read and change all your data on the websites you visit." For most extensions, that line is a reason to back out. A coupon finder does not need to read your bank.

peerd asks for that authority on purpose. It is an AI agent that runs inside the browser you already use, and the whole pitch is that it helps with whatever tab you point it at. Broad page access is not a smell here. It is the job. Which is exactly why I would not install it on a real account before writing down the terms.

That is the shift worth noticing. A browser-native agent is not an app you grant a narrow scope. It is a tenant you hand a workspace, with your logged-in sessions already inside it. And tenants get a lease.

What peerd is actually proposing

peerd showed up as a Show HN on June 23 and describes itself, in its own README, as "the first AI agent harness native to the browser." Strip the marketing and it means something concrete: a Chrome and Firefox extension that runs the full agent loop on your machine, reads and drives your tabs, and spins up sandboxed compute right there in the browser, including JavaScript notebooks and a Linux VM compiled to WebAssembly.

The design choices are the interesting part. You bring your own API key to a model provider. There is no backend, no telemetry, and no cloud component sitting in the data path. The repository is Apache-2.0, it had picked up a couple hundred GitHub stars in its first week, and it is honest about its stage: a 0.x experimental beta where breaking changes are likely and, in its own words, it "drives the browser and holds API keys, so use with care."

I want to be clear about what I am doing here. This is not a review, and it is not a warning that peerd is unsafe. It is a useful artifact because it makes a problem visible that every browser agent has and most marketing hides: once an agent lives in your browser, the permission boundary is the product. peerd just writes its boundary down where you can read it. So let us read it.

The permission surface, taken apart

peerd's documentation is unusually specific about what it can touch and how it tries to contain itself. Walking the surface is the fastest way to learn what to ask of any browser agent.

Page reading and actions. The Chrome Web Store build does not request the debugger permission. Instead, per its permission justifications, it uses chrome.scripting to read page content, build accessibility-style snapshots, and click and type. It uses tabs to list, open, and navigate tabs for orchestration. Worth noting: the development manifest does list debugger along with a longer permission set, so what you grant depends on which build you install. Do not assume the store version and a source build ask for the same thing.

Host permissions. It requests <all_urls>. The justification is the same honest one from the opening: the assistant has to act on whatever page you assign it at task time, so it cannot enumerate sites in advance. That is the broadest grant in the browser, and peerd's answer is to constrain it after the fact rather than narrow it up front.

The key vault. Your model-provider key lives in an encrypted vault, secured with Argon2id and WebAuthn-PRF per the SECURITY.md. The key is the crown jewel, and vault or key exfiltration is listed as an in-scope vulnerability the project wants reported.

The reader boundary. This is the most thoughtful piece, and the one I would study before building anything similar. The agent that holds your keys never reads raw page content. A disposable runner with no key, no memory, and no egress tools reads the page and hands back fenced, untrusted output. The idea is to keep a malicious page from talking directly to the part of the system that can spend your money or call tools.

Egress chokepoint. Outbound requests funnel through a safeFetch provider allowlist and a webFetch SSRF guard with a sensitive-origin denylist. The agent is not supposed to be able to call arbitrary endpoints, which is the difference between "reads a page" and "ships that page somewhere."

Sandboxed compute. The notebooks and the WebAssembly Linux VM run in opaque-origin iframes and isolated sandboxes. Code the agent writes is supposed to execute without reaching back into the extension's privileges. Sandbox escape is, again, explicitly in scope as a vulnerability class.

The denylist, on by default. Per the reviewer notes, peerd ships refusing to operate on banks, brokerages, crypto exchanges and wallets, health portals, government services, password managers, and identity providers. The service worker blocks tool dispatch until that denylist loads, so there is no early window where the guard is off.

Action verification. An action does not count as done until peerd checks the result against the live page. That sounds like a small QA detail. It is closer to a trust primitive: the agent has to prove the click landed instead of reporting success from its own intentions.

The audit log. Tool dispatch is policy-gated and written to an append-only local log, and the log records outbound requests including the ones that got denied. That last part matters. A log of what an agent tried and was stopped from doing is often more useful than a log of what it did.

It is a serious-looking set of controls. It is also, by the project's own admission, early and unaudited, and the HN thread poked at the obvious seams. One commenter asked what stops the runner's own summary from smuggling a prompt injection back into the main loop. Another asked why this needs a browser-specific security model at all, versus plain OS user or container isolation. Those are the right questions. They are also your questions to answer before you test, not the vendor's to answer for you.

The browser-agent permission lease

Here is the artifact. A lease is not a vibe check and it is not a vulnerability hunt. It is a short operating agreement for a workspace you are renting out to software. Each row is a question peerd's docs already force into the open, written so you can fill it in for any browser agent you are evaluating.

Scroll sideways to see all 3 columns.

Lease term	What it governs	What to write down before testing
Page scope	Which sites and tabs the agent may read and act on	The exact set of origins for your first use case, not "all my tabs." If the tool only offers <all_urls>, your scope lives in the denylist and a separate profile, not the grant.
Identity and keys	Whose API key it spends and where that key rests	Which provider, which key, how it is stored, and who else on the machine can reach the vault.
Reader boundary	What component touches raw, untrusted page content	Confirm a low-privilege reader handles pages and the key-holding loop never sees raw markup directly.
Egress limits	Where the agent is allowed to send data	The allowlist of endpoints it may call, plus an explicit block on internal and loopback addresses.
Compute sandbox	What the agent-written code can reach when it runs	Where notebooks and VMs execute, and proof that sandboxed code cannot reach the extension's privileges or your other tabs.
Off-limits origins	Sites the agent must refuse even if asked	Your denylist: banking, payroll, health, identity, anything that moves money or proves who you are. Confirm it is on by default.
Proof of work	How the agent shows a task actually happened	Whether actions are verified against the live page before being marked done, so "completed" means observed, not intended.
Audit trail	What record survives the session	Where the log lives, whether it is append-only, and whether it captures denied attempts, not just successful ones.
Revocation	How fast you can take the authority back	The one-move kill: disable the extension, rotate the key, clear the vault. Know this before you start, not during an incident.
Term and stage	How stable the thing you are trusting is	Version, beta status, and whether security fixes land on a release you track or only on main. peerd backports nothing; the supported version is the latest commit.

The two rows that catch people are Page scope and Revocation.

Scope, because "whatever tab I point at" feels like control right up until you realize the tool you pointed at is the one deciding what counts as the task. Revocation, because almost nobody decides how they will pull the keys back until the moment they need to, and that is the worst time to be reading documentation.

If filling this in feels familiar, it should. It is the same instinct behind logging agent receipts before AI touches customer work, and the same boundary thinking that made a separate browser profile the quietly important detail in other browser-agent setups. The lease just puts those instincts on one page, before the install.

The trade you are actually making

Here is the part I keep turning over. peerd's best feature and its biggest ask are the same thing.

No backend and no telemetry means your page contents and your tasks are not piling up in someone else's logs. For a small team doing authenticated work - support portals, CMS edits, QA passes, invoice admin - that is a real reduction in data exhaust. There is no third party to breach, no vendor retention policy to read, no quiet training pipeline. The data stays on your machine.

But "stays on your machine" is not the same as "safe." It means the entire boundary now lives on your machine, in your browser, under your watch. The vault is yours to protect. The denylist is yours to trust. The host permission is yours to constrain. Cloud agents at least concentrate the security work in a place with a security team. A browser-native agent hands that work to you, along with the keys.

That is not an argument against the local-first shape. I think it is the more honest shape. It is an argument for treating the browser permission boundary as something you design, not something you accept at the install dialog. The same lesson AutoJack taught about localhost: the boundary you never wrote down is the one that surprises you. peerd's own docs are basically a lease the project wrote for itself. The least you can do is write one for your accounts before you hand them over.

A browser agent does not need a vibe check. It needs a lease: where it can work, what it can touch, how it proves the job, and when the keys come back.

Your next move

Pick the one browser-agent use case you would actually try first. The real one, on a real account, the thing that made you read this far. Then fill the ten rows of the lease above for that single workflow before any agent gets your logged-in tabs. The AI workflow security review worksheet covers the same ground for data access, approvals, and shutdown paths, and the AI workflow controls page shows where the lease fits in a larger process.

If a row comes up blank and you want a second set of eyes, bring one browser-agent use case and we will fill the lease with you before it touches anything that matters. That is also the shape of how we scope process automation: figure out the boundary first, then let the agent drive.