Il primo harness per agenti AI nativo del web

peerd è il primo runtime per agenti generici costruito direttamente sui primitivi del browser: Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn e WebExtensions. Funziona completamente dentro Chrome e Firefox, con le tue schede, le sessioni con accesso effettuato, le web app e la potenza di calcolo locale.

Mentre le piattaforme per agenti cercano di trascinare il browser nell'harness, peerd porta l'harness nel browser.

Per l'inferenza vera e propria puoi scegliere un provider di modelli ospitato supportato, un modello locale tramite localhost, oppure dare un'occhiata al supporto preliminare per modelli WebGPU locali (teniamo d'occhio anche WebNN).

Non è richiesto alcun account peerd, browser ospitato o connessione a un tool-server. Le build attuali non inviano telemetria di prodotto a peerd.

Installazione · peerd.ai · Architettura · Sicurezza

Funzionalità

• Funziona nel browser che già usi. L'agente può leggere e pilotare le tue schede, le web app, le sessioni con accesso effettuato e il contenuto delle pagine.
• Costruisce client di sito riutilizzabili. L'attore web può imparare un sito una volta e riusare quel client in attività successive.
• Esegue codice dentro i confini del browser. Script, JavaScript Notebook sigillati, strumenti WASI compilati, App del browser e WebVM Linux danno all'agente potenza di calcolo locale senza accesso al sistema operativo host.
• Delega ad attori separati. Ogni pagina e ambiente di calcolo ha il proprio attore senza chiavi con strumenti limitati a quell'ambiente.
• Conserva il contesto utile. Sessioni, memoria, competenze, obiettivi, revisione e checkpoint vivono nell'estensione.
• Usa il modello che scegli. L'inventario live dei provider è definito in registry.js, inclusi adattatori cloud BYOK e opzioni locali senza chiavi.
• Collega i browser direttamente. Le build di anteprima aggiungono identità firmata, discovery browser-to-browser, dwapp e comunicazione agente-agente su WebRTC; i pacchetti dello store li eliminano completamente.

Perché il browser

Gli agenti locali possono accedere a tutto il tuo computer. Gli agenti remoti vivono nel computer di qualcun altro. Il browser è l'alternativa: capacità locale dietro confini di sicurezza temprati per tre decenni.

peerd usa quei confini. Il lavoro sulle pagine va ad attori separati con solo gli strumenti per quella scheda o ambiente. Credenziali, regole di rete, conferme e audit restano nell'estensione. Il suo design di difesa in profondità presuppone che contenuti non sicuri prima o poi superino un filtro.

Supporto browser

peerd supporta Chromium e Firefox. Firefox esegue gli attori in worker dedicati e usa Notebook visibili per il calcolo JavaScript. Le funzionalità che richiedono l'host del documento offscreen di Chrome vengono rimosse dai controlli di Firefox e dagli strumenti dei modelli prima dell'uso. Le build di anteprima per Firefox omettono dweb finché Firefox non ha un host mesh.

Le App e le WebVM girano su Chrome. Le App non hanno accesso di rete ambientale. Le risorse remote, i fetch, WebRTC, i moduli e la navigazione verso documenti esterni sono bloccati. I link HTTP e HTTPS esterni richiedono conferma dell'utente.

I gap concreti di capacità del browser, i relativi problemi a monte e i test richiesti per rimuovere ogni protezione sono tracciati in docs/BROWSER-COMPATIBILITY.md.

Il codice è la fonte di verità per il comportamento attuale. Inizia da CLAUDE.md, poi leggi il modulo pertinente sotto extension/.

Modello di sicurezza

peerd usa isolamento del browser, esposizione ristretta degli strumenti, gate di policy del service worker e controlli espliciti di egress. L'agente principale delega il lavoro sugli ambienti ad attori senza chiavi. Su Chrome e Firefox, i loop di agenti non orchestratori girano in heap di worker dedicati separati. Se il browser non può dimostrare quel confine, la richiesta dell'attore non viene eseguita e non svolge alcun lavoro sul suo target.

Il comportamento di rete dipende dall'operazione. Le chiamate ai modelli, le letture web, i caricamenti di asset runtime, il traffico sandbox e il traffico dweb di anteprima usano percorsi e policy con ambiti diversi. Vedi SECURITY.md e il modello di minaccia per i confini attuali e le limitazioni note.

Installazione

Chrome da sorgente

1. Clona il repository.
2. Apri chrome://extensions.
3. Attiva la Modalità sviluppatore.
4. Scegli Carica estensione non pacchettizzata e seleziona la directory extension/.

Ricarica l'estensione da chrome://extensions dopo le modifiche al sorgente.

Firefox da sorgente

Firefox richiede un pacchetto specifico per Firefox. Non caricare il manifest di sviluppo Chrome incluso nel repository. Usa una versione di Firefox uguale o superiore al minimo dichiarato nella patch del canale sotto manifests/. Quel minimo segue il supporto di scripting legato al documento usato dagli strumenti del browser.

bun run package -- --channel=preview --browser=firefox --no-sign

Apri about:debugging#/runtime/this-firefox, scegli Carica componente aggiuntivo temporaneo e seleziona artifacts/peerd-preview-firefox.xpi. I componenti aggiuntivi temporanei devono essere ricaricati dopo il riavvio di Firefox. Le trasformazioni di browser e canale sono definite dagli script di packaging.

Pacchetti di rilascio

Vedi GitHub Releases per gli artefatti attuali. Le build dello store e di anteprima differiscono. Le build dello store omettono dweb. Le build di anteprima lo includono e possono abilitare funzionalità di automazione aggiuntive. Il codice di packaging è l'autorità per ogni browser e canale.

Primo avvio

1. Apri peerd dalla barra degli strumenti del browser.
2. Crea e sblocca il vault locale. Lo sblocco con passphrase è sempre disponibile. Lo sblocco con passkey dipende dal supporto WebAuthn PRF nel browser e nel dispositivo.
3. Completa il breve onboarding del profilo.
4. Apri Impostazioni, poi aggiungi una chiave del provider o scegli un provider locale supportato.
5. Seleziona un modello e avvia una chat.

Solo i segreti del vault e i record di sicurezza protetti sono coperti dal confine di crittografia del vault. Altro stato locale dell'estensione segue le regole di archiviazione nella documentazione di sicurezza.

Architettura

L'estensione ha cinque moduli principali. Ogni modulo espone la sua API pubblica tramite il suo index.js.

Il telaio dell'estensione vive in background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ e directory di supporto correlate. Il posizionamento degli host e la regola del worker freddo sono documentati in docs/EXTENSION-HOSTS.md.

Sviluppo

L'estensione sorgente è JavaScript vanilla con moduli ES e gira direttamente quando viene caricata non pacchettizzata. Non c'è bundler di sviluppo, transpiler, watcher o albero runtime generato. Il packaging di rilascio usa Bun solo sulla sua copia di staging usa e getta per rimuovere spazi bianchi/commenti dai moduli autori nei grafi freddi statici del service worker e dell'offscreen di Chrome. Preserva i confini dei moduli, i nomi dei binding, gli import lazy e ogni byte venduto. Passa --no-minify a bun run package -- ... quando un artefatto diagnostico leggibile è utile.

bun install
bun run gen:dev
bun test ./tests
bun scripts/cdp/run-inbrowser-tests.mjs
bun run typecheck
bun run lint
bun run e2e:verify
bun run preflight

Ci sono tre superfici di test:

• Test Bun per la logica pura.
• Test in-browser per l'integrazione di estensione e browser. Girano headless sotto Chrome e, in shard, sotto Gecko contro il pacchetto Firefox Store installato. Ogni corsia esegue ogni test che registra; i totali differiscono leggermente perché alcuni test si registrano solo dove un service worker live risponde.
• E2E Chrome live e verifica visiva per i flussi completi.

Accanto a questi, la suite red-team in tests/red-team/ guida ogni avversario del modello di minaccia contro il codice di difesa reale e registra se ogni sonda ostile è stata bloccata. La sua matrice è docs/security/RED-TEAM-RESULTS.md.

Ogni corsia pubblica il proprio conteggio come badge sopra. Il JSON dei badge sotto badges/ è generato dal job CI che ha eseguito la corsia e poi confrontato, quindi un conteggio su questa pagina è sempre prova di un'esecuzione avvenuta piuttosto che un numero digitato da qualcuno. Rigenerane uno con bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (richiede Firefox e geckodriver), o bun run gen:badge:e2e, e committa il risultato. bun run check:badges verifica che gli endpoint siano ben formati senza avviare un browser.

Per le modifiche UI, esegui bun run e2e:verify, ispeziona scripts/cdp/artifacts/result.json e ispeziona gli screenshot generati.

I file generati non devono essere modificati a mano. In particolare, extension/manifest.json e extension/shared/channel-config.js provengono dal manifest e dalle sorgenti di packaging. CI li controlla per rilevare derive.

Leggi CONTRIBUTING.md prima di modificare il codice.

Documentazione

• CLAUDE.md: struttura del progetto, convenzioni e postura attuale
• SECURITY.md: policy di sicurezza e segnalazione
• docs/security/THREAT-MODEL.md: confini di fiducia e rischi residui
• docs/security/LIFECYCLE-CONTRACT.md: comportamento di interruzione e limiti di recupero
• docs/security/RED-TEAM-RESULTS.md: copertura red-team
• docs/APP-ACTORS.md: attori App definiti dal manifest, adattatori semantici live e UX co-pilota in scheda
• docs/DWAPP-BUNDLE.md: trasporto dwapp compresso, alberi di lavoro decodificati e asset binari
• docs/store/: packaging dello store, permessi, privacy e note per i revisori
• scripts/cdp/states.mjs: stati E2E e visivi

Dipendenze e licenza

L'estensione distribuita non ha dipendenze runtime npm. package.json non ne dichiara nessuna, e il packaging non risolve mai un percorso node_modules nell'artefatto di staging, quindi l'albero degli strumenti di sviluppo non può raggiungere un browser installato. Il codice runtime di terze parti è invece venduto sotto extension/vendor/. La sua sorgente, versione e licenza vivono nei file SOURCE.txt adiacenti, e ogni byte venduto è ancorato tramite SHA-256 in extension/vendor/vendor.lock.json, che bun run check:vendor verifica in CI e preflight.

Altre due posizioni della supply chain portano i propri badge sopra, entrambi rigenerati da bun run gen:dev e controllati per derive in CI. Ogni GitHub Action di terze parti gira a un commit SHA completo, protetto da check:actions: un tag major è un ref mutabile che il suo editore può spostare, il che significherebbe codice arbitrario in un job che detiene questo checkout e, nel workflow di rilascio, i segreti di firma. Le dipendenze appena risolte restano anche in una finestra di quarantena prima di poter entrare nel lock, impostata da minimumReleaseAge in bunfig.toml, insieme a una scansione malware all'installazione.

peerd è concesso in licenza sotto la Apache License 2.0. I componenti venduti mantengono le proprie licenze. CheerpX è un runtime proprietario fornito da Leaning Technologies e non è coperto dalla licenza Apache di peerd.