Le premier harnais d'agent IA natif du web

peerd est le premier runtime d'agent à usage général construit directement sur les primitives du navigateur : Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn et WebExtensions. Il s'exécute entièrement dans Chrome et Firefox, avec vos onglets, sessions connectées, applications web et puissance de calcul locale.

Alors que les plateformes d'agents tentent d'attirer le navigateur dans le harnais, peerd attire le harnais dans le navigateur.

Pour l'inférence proprement dite, vous pouvez choisir un fournisseur de modèles hébergé pris en charge, un modèle local via localhost, ou explorer la prise en charge préliminaire des modèles WebGPU locaux (nous gardons également un œil sur WebNN).

Aucun compte peerd, navigateur hébergé ou connexion à un serveur d'outils n'est requis. Les versions actuelles n'envoient aucune télémétrie produit à peerd.

Installation · peerd.ai · Architecture · Sécurité

Fonctionnalités

• Fonctionne dans le navigateur que vous utilisez déjà. L'agent peut lire et piloter vos onglets, applications web, sessions connectées et contenus de pages.
• Construit des clients de sites réutilisables. L'acteur web peut apprendre un site une fois et réutiliser ce client lors de tâches ultérieures.
• Exécute du code dans les limites du navigateur. Les scripts, les Notebooks JavaScript scellés, les outils WASI compilés, les Apps du navigateur et les WebVM Linux offrent à l'agent une puissance de calcul locale sans accès à votre système d'exploitation hôte.
• Délègue à des acteurs distincts. Chaque page et environnement de calcul possède son propre acteur sans clé, avec des outils limités à cet environnement.
• Conserve un contexte utile. Les sessions, la mémoire, les compétences, les objectifs, la revue et les points de contrôle vivent dans l'extension.
• Utilise le modèle de votre choix. L'inventaire des fournisseurs en direct est défini dans registry.js, y compris les adaptateurs cloud BYOK et les options locales sans clé.
• Connecte directement les navigateurs. Les versions preview ajoutent une identité signée, la découverte navigateur-à-navigateur, les dwapps et la communication agent-à-agent via WebRTC ; les paquets du store les suppriment entièrement.

Pourquoi le navigateur

Les agents locaux peuvent accéder à tout votre ordinateur. Les agents distants vivent chez quelqu'un d'autre. Le navigateur est l'alternative : une capacité locale derrière des frontières de sécurité durcies depuis trois décennies.

peerd utilise ces frontières. Le travail sur les pages est confié à des acteurs distincts disposant uniquement des outils de cet onglet ou environnement. Les identifiants, les règles réseau, les confirmations et l'audit restent dans l'extension. Sa conception de défense en profondeur suppose qu'un contenu non sûr finira par franchir un filtre.

Prise en charge des navigateurs

peerd prend en charge Chromium et Firefox. Firefox exécute les acteurs dans des workers dédiés et utilise des Notebooks visibles pour le calcul JavaScript. Les fonctionnalités nécessitant l'hôte de document hors écran de Chrome sont supprimées des contrôles Firefox et des outils de modèle avant utilisation. Les versions preview de Firefox omettent dweb jusqu'à ce que Firefox dispose d'un hôte maillé.

Les Apps et les WebVM s'exécutent sur Chrome. Les Apps n'ont aucun accès réseau ambiant. Les ressources distantes, les fetchs, WebRTC, les formulaires et la navigation vers des documents externes sont bloqués. Les liens HTTP et HTTPS externes nécessitent une confirmation de l'utilisateur.

Les lacunes concrètes de capacité des navigateurs, leurs problèmes en amont et les tests requis pour supprimer chaque garde sont suivis dans docs/BROWSER-COMPATIBILITY.md.

Le code est la source de vérité pour le comportement actuel. Commencez par CLAUDE.md, puis lisez le module pertinent sous extension/.

Modèle de sécurité

peerd utilise l'isolation du navigateur, une exposition étroite des outils, des passerelles de politique de service worker et des contrôles d'egress explicites. L'agent principal délègue le travail d'environnement à des acteurs sans clé. Sur Chrome et Firefox, les boucles d'agent non-orchestratrices s'exécutent dans des tas de workers dédiés séparés. Si le navigateur ne peut pas prouver cette frontière, la requête de l'acteur ne s'exécute pas et n'effectue aucun travail sur sa cible.

Le comportement réseau dépend de l'opération. Les appels de modèle, les lectures web, les chargements d'actifs runtime, le trafic sandbox et le trafic dweb preview utilisent des chemins et des politiques étendus différents. Voir SECURITY.md et le modèle de menace pour les frontières actuelles et les limitations connues.

Installation

Chrome depuis les sources

1. Clonez le dépôt.
2. Ouvrez chrome://extensions.
3. Activez le mode développeur.
4. Choisissez Charger l'extension non empaquetée et sélectionnez le répertoire extension/.

Rechargez l'extension depuis chrome://extensions après les modifications des sources.

Firefox depuis les sources

Firefox nécessite un paquet spécifique à Firefox. Ne chargez pas le manifeste de développement Chrome vérifié dans le dépôt. Utilisez une version de Firefox au moins égale au minimum déclaré dans le patch de canal sous manifests/. Ce plancher suit la prise en charge du scripting lié au document utilisée par les outils du navigateur.

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

Ouvrez about:debugging#/runtime/this-firefox, choisissez Charger un module complémentaire temporaire et sélectionnez artifacts/peerd-preview-firefox.xpi. Les modules complémentaires temporaires doivent être rechargés après le redémarrage de Firefox. Les transformations navigateur et canal sont définies par les scripts d'empaquetage.

Paquets de publication

Voir GitHub Releases pour les artefacts actuels. Les versions store et preview diffèrent. Les versions store omettent dweb. Les versions preview l'incluent et peuvent activer des fonctionnalités d'automatisation supplémentaires. Le code d'empaquetage fait autorité pour chaque navigateur et canal.

Première exécution

1. Ouvrez peerd depuis la barre d'outils du navigateur.
2. Créez et déverrouillez le coffre-fort local. Le déverrouillage par phrase de passe est toujours disponible. Le déverrouillage par clé d'accès dépend de la prise en charge de WebAuthn PRF dans le navigateur et l'appareil.
3. Terminez la courte procédure d'intégration du profil.
4. Ouvrez les paramètres, puis ajoutez une clé de fournisseur ou choisissez un fournisseur local pris en charge.
5. Sélectionnez un modèle et démarrez une conversation.

Seuls les secrets du coffre-fort et les enregistrements de sécurité protégés sont couverts par la frontière de chiffrement du coffre-fort. Les autres états locaux de l'extension suivent les règles de stockage de la documentation de sécurité.

Architecture

L'extension comporte cinq modules principaux. Chaque module expose son API publique via son index.js.

Le châssis de l'extension vit dans background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ et les répertoires de support associés. Le placement des hôtes et la règle du worker à froid sont documentés dans docs/EXTENSION-HOSTS.md.

Développement

L'extension source est du JavaScript vanilla avec des modules ES et s'exécute directement lorsqu'elle est chargée non empaquetée. Il n'y a pas de bundler de développement, de transpileur, de watcher ni d'arborescence runtime générée. L'empaquetage de publication utilise Bun uniquement sur sa copie de staging jetable pour supprimer les espaces/commentaires des modules rédigés dans les graphes à froid du service worker statique et du document hors écran Chrome. Il préserve les frontières des modules, les noms de liaisons, les imports paresseux et chaque octet vendored. Passez --no-minify à bun run package -- ... lorsqu'un artefact de diagnostic lisible est 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

Il existe trois surfaces de test :

• Les tests Bun pour la logique pure.
• Les tests dans le navigateur pour l'intégration de l'extension et du navigateur. Ils s'exécutent en headless sous Chrome et, en sharded, sous Gecko contre le paquet Firefox Store installé. Chaque lane exécute chaque test qu'elle enregistre ; les totaux diffèrent légèrement car certains tests ne s'enregistrent que là où un service worker en direct répond.
• Les E2E Chrome en direct et la vérification visuelle pour les flux complets.

À leurs côtés, la suite red-team dans tests/red-team/ pilote chaque adversaire du modèle de menace contre le code de défense réel et enregistre si chaque sonde hostile a été bloquée. Sa matrice est docs/security/RED-TEAM-RESULTS.md.

Chaque lane publie son propre compte comme badge ci-dessus. Le JSON des badges sous badges/ est généré par le travail CI qui a exécuté la lane puis comparé par diff, donc un compte sur cette page est toujours une preuve d'une exécution qui a eu lieu plutôt qu'un nombre tapé par quelqu'un. Régénérez-en un avec bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (nécessite Firefox et geckodriver), ou bun run gen:badge:e2e, et validez le résultat. bun run check:badges vérifie que les endpoints sont bien formés sans lancer de navigateur.

Pour les modifications d'interface, exécutez bun run e2e:verify, inspectez scripts/cdp/artifacts/result.json et inspectez les captures d'écran générées.

Les fichiers générés ne doivent pas être modifiés à la main. En particulier, extension/manifest.json et extension/shared/channel-config.js proviennent des sources du manifeste et de l'empaquetage. CI vérifie leur dérive.

Lisez CONTRIBUTING.md avant de modifier le code.

Documentation

• CLAUDE.md : structure du projet, conventions et posture actuelle
• SECURITY.md : politique de sécurité et signalement
• docs/security/THREAT-MODEL.md : frontières de confiance et risques résiduels
• docs/security/LIFECYCLE-CONTRACT.md : comportement d'interruption et limites de récupération
• docs/security/RED-TEAM-RESULTS.md : couverture red-team
• docs/APP-ACTORS.md : acteurs App définis par manifeste, adaptateurs sémantiques en direct et UX co-pilote dans l'onglet
• docs/DWAPP-BUNDLE.md : transport dwapp compressé, arbres de travail décodés et actifs binaires
• docs/store/ : empaquetage store, permissions, confidentialité et notes de revue
• scripts/cdp/states.mjs : états E2E et visuels

Dépendances et licence

L'extension livrée n'a aucune dépendance runtime npm. package.json n'en déclare aucune, et l'empaquetage ne résout jamais un chemin node_modules dans l'artefact stagé, donc l'arborescence des outils de développement ne peut pas atteindre un navigateur installé. Le code runtime tiers est vendored sous extension/vendor/ à la place. Sa source, sa version et sa licence vivent dans les fichiers SOURCE.txt adjacents, et chaque octet vendored est épinglé par SHA-256 dans extension/vendor/vendor.lock.json, que bun run check:vendor vérifie en CI et en preflight.

Deux autres positions de chaîne d'approvisionnement portent leurs propres badges ci-dessus, tous deux régénérés par bun run gen:dev et vérifiés par diff en CI. Chaque GitHub Action tierce s'exécute à un SHA de commit complet, contrôlé par check:actions : un tag majeur est une référence mutable que son éditeur peut déplacer, ce qui signifierait du code arbitraire dans un travail détenant ce checkout, et dans le workflow de publication, les secrets de signature. Les dépendances nouvellement résolues attendent également une fenêtre de quarantaine avant de pouvoir entrer dans le lock, définie par minimumReleaseAge dans bunfig.toml, accompagnée d'une analyse de malware à l'installation.

peerd est sous licence Apache License 2.0. Les composants vendored conservent leurs propres licences. CheerpX est un runtime propriétaire fourni par Leaning Technologies et n'est pas couvert par la licence Apache de peerd.