El primer harness de agentes de IA nativo de la web

peerd es el primer runtime de agentes de propósito general construido directamente sobre primitivas del navegador: Workers, orígenes, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn y WebExtensions. Se ejecuta completamente dentro de Chrome y Firefox, con tus pestañas, sesiones iniciadas, aplicaciones web y cómputo local.

Mientras que las plataformas de agentes intentan meter el navegador en el harness, peerd mete el harness en el navegador.

Para la inferencia real puedes elegir un proveedor de modelos alojado compatible, un modelo local mediante localhost, o probar el soporte preliminar para modelos WebGPU locales (también estamos vigilando WebNN).

No se requiere cuenta de peerd, navegador alojado ni conexión a un servidor de herramientas. Las compilaciones actuales no envían telemetría de producto a peerd.

Instalación · peerd.ai · Arquitectura · Seguridad

Características

• Funciona en el navegador que ya usas. El agente puede leer y controlar tus pestañas, aplicaciones web, sesiones iniciadas y contenido de páginas.
• Construye clientes de sitio reutilizables. El actor web puede aprender un sitio una vez y usar ese cliente de nuevo en tareas posteriores.
• Ejecuta código dentro de los límites del navegador. Scripts, Notebooks de JavaScript sellados, herramientas WASI compiladas, Apps del navegador y WebVMs de Linux le dan al agente cómputo local sin acceso a tu sistema operativo anfitrión.
• Delega en actores separados. Cada página y entorno de cómputo tiene su propio actor sin claves con herramientas limitadas a ese entorno.
• Conserva contexto útil. Sesiones, memoria, habilidades, objetivos, revisión y puntos de control viven en la extensión.
• Usa el modelo que elijas. El inventario de proveedores en vivo se define en registry.js, incluyendo adaptadores cloud BYOK y opciones locales sin claves.
• Conecta navegadores directamente. Las compilaciones de vista previa añaden identidad firmada, descubrimiento navegador-a-navegador, dwapps y comunicación agente-a-agente sobre WebRTC; los paquetes de la tienda lo eliminan por completo.

Por qué el navegador

Los agentes locales pueden acceder a todo tu ordenador. Los agentes remotos viven en el de alguien más. El navegador es la alternativa: capacidad local detrás de límites de seguridad endurecidos durante tres décadas.

peerd usa esos límites. El trabajo de página va a actores separados con solo las herramientas para esa pestaña o entorno. Las credenciales, reglas de red, confirmaciones y auditoría permanecen en la extensión. Su diseño de defensa en profundidad asume que el contenido no seguro eventualmente pasará un filtro.

Soporte de navegadores

peerd soporta Chromium y Firefox. Firefox ejecuta actores en workers dedicados y usa Notebooks visibles para el cómputo JavaScript. Las características que necesitan el host de documento fuera de pantalla de Chrome se eliminan de los controles de Firefox y las herramientas de modelo antes de su uso. Las compilaciones de vista previa de Firefox omiten dweb hasta que Firefox tenga un host de malla.

Las Apps y WebVMs se ejecutan en Chrome. Las Apps no tienen acceso de red ambiental. Los recursos remotos, fetches, WebRTC, formularios y navegación a documentos externos están bloqueados. Los enlaces HTTP y HTTPS externos requieren confirmación del usuario.

Las brechas concretas de capacidad del navegador, sus problemas ascendentes y las pruebas requeridas para eliminar cada guarda se rastrean en docs/BROWSER-COMPATIBILITY.md.

El código es la fuente de verdad para el comportamiento actual. Comienza con CLAUDE.md, luego lee el módulo relevante bajo extension/.

Modelo de seguridad

peerd usa aislamiento del navegador, exposición estrecha de herramientas, puertas de política de service-worker y controles explícitos de egreso. El agente principal delega el trabajo de entorno a actores sin claves. En Chrome y Firefox, los bucles de agente no orquestadores se ejecutan en heaps de workers dedicados separados. Si el navegador no puede probar ese límite, la solicitud del actor no se ejecuta y no realiza ningún trabajo en su objetivo.

El comportamiento de red depende de la operación. Las llamadas de modelo, lecturas web, cargas de activos de runtime, tráfico de sandbox y tráfico dweb de vista previa usan rutas y políticas limitadas diferentes. Consulta SECURITY.md y el modelo de amenazas para los límites actuales y limitaciones conocidas.

Instalación

Chrome desde el código fuente

1. Clona el repositorio.
2. Abre chrome://extensions.
3. Activa el modo de desarrollador.
4. Elige Load unpacked y selecciona el directorio extension/.

Recarga la extensión desde chrome://extensions después de cambios en el código fuente.

Firefox desde el código fuente

Firefox necesita un paquete específico de Firefox. No cargues el manifiesto de desarrollo de Chrome verificado. Usa una versión de Firefox igual o superior al mínimo declarado en el parche de canal bajo manifests/. Ese mínimo sigue el soporte de scripting vinculado a documentos usado por las herramientas del navegador.

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

Abre about:debugging#/runtime/this-firefox, elige Load Temporary Add-on, y selecciona artifacts/peerd-preview-firefox.xpi. Los add-ons temporales deben cargarse de nuevo después de reiniciar Firefox. Las transformaciones de navegador y canal están definidas por los scripts de empaquetado.

Paquetes de lanzamiento

Consulta GitHub Releases para los artefactos actuales. Las compilaciones de tienda y vista previa difieren. Las compilaciones de tienda omiten el dweb. Las compilaciones de vista previa lo incluyen y pueden habilitar características de automatización adicionales. El código de empaquetado es la autoridad para cada navegador y canal.

Primer uso

1. Abre peerd desde la barra de herramientas del navegador.
2. Crea y desbloquea la bóveda local. El desbloqueo con frase de contraseña está siempre disponible. El desbloqueo con passkey depende del soporte WebAuthn PRF en el navegador y el dispositivo.
3. Completa la breve incorporación de perfil.
4. Abre Configuración, luego añade una clave de proveedor o elige un proveedor local compatible.
5. Selecciona un modelo y comienza un chat.

Solo los secretos de la bóveda y los registros de seguridad protegidos están cubiertos por el límite de cifrado de la bóveda. Otro estado local de la extensión sigue las reglas de almacenamiento en la documentación de seguridad.

Arquitectura

La extensión tiene cinco módulos principales. Cada módulo expone su API pública a través de su index.js.

El chasis de la extensión vive en background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ y directorios de soporte relacionados. La ubicación de hosts y la regla de worker en frío están documentadas en docs/EXTENSION-HOSTS.md.

Desarrollo

La extensión fuente es JavaScript vanilla con módulos ES y se ejecuta directamente cuando se carga sin empaquetar. No hay bundler de desarrollo, transpilador, watcher ni árbol de runtime generado. El empaquetado de lanzamiento usa Bun solo en su copia de staging desechable para eliminar espacios en blanco/comentarios de los módulos creados en el service-worker estático y los grafos en frío fuera de pantalla de Chrome. Preserva los límites de módulos, nombres de enlaces, imports perezosos y cada byte vendido. Pasa --no-minify a bun run package -- ... cuando un artefacto de diagnóstico legible sea útil.

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

Hay tres superficies de prueba:

• Pruebas Bun para lógica pura.
• Pruebas en navegador para integración de extensión y navegador. Se ejecutan headless bajo Chrome y, fragmentadas, bajo Gecko contra el paquete de Firefox Store instalado. Cada carril ejecuta cada prueba que registra; los totales difieren ligeramente porque algunas pruebas se registran solo donde un service worker en vivo responde.
• E2E de Chrome en vivo y verificación visual para flujos completos.

Junto a ellas, la suite de red team en tests/red-team/ impulsa cada adversario del modelo de amenazas contra el código de defensa real y registra si cada sonda hostil fue bloqueada. Su matriz es docs/security/RED-TEAM-RESULTS.md.

Cada carril publica su propio recuento como insignia arriba. El JSON de insignias bajo badges/ es generado por el trabajo de CI que ejecutó el carril y luego se compara, por lo que un recuento en esta página siempre es evidencia de una ejecución que ocurrió en lugar de un número que alguien escribió. Regenera uno con bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (necesita Firefox y geckodriver), o bun run gen:badge:e2e, y confirma el resultado. bun run check:badges verifica que los endpoints estén bien formados sin lanzar un navegador.

Para cambios de UI, ejecuta bun run e2e:verify, inspecciona scripts/cdp/artifacts/result.json e inspecciona las capturas de pantalla generadas.

Los archivos generados no deben editarse a mano. En particular, extension/manifest.json y extension/shared/channel-config.js provienen de las fuentes de manifiesto y empaquetado. CI los verifica por desviación.

Lee CONTRIBUTING.md antes de cambiar código.

Documentación

• CLAUDE.md: estructura del proyecto, convenciones y postura actual
• SECURITY.md: política de seguridad y reporte
• docs/security/THREAT-MODEL.md: límites de confianza y riesgos residuales
• docs/security/LIFECYCLE-CONTRACT.md: comportamiento de interrupción y límites de recuperación
• docs/security/RED-TEAM-RESULTS.md: cobertura de red team
• docs/APP-ACTORS.md: actores App definidos por manifiesto, adaptadores semánticos en vivo y la UX de co-piloto en pestaña
• docs/DWAPP-BUNDLE.md: transporte dwapp comprimido, árboles de trabajo decodificados y activos binarios
• docs/store/: empaquetado de tienda, permisos, privacidad y notas de revisores
• scripts/cdp/states.mjs: estados E2E y visuales

Dependencias y licencia

La extensión distribuida no tiene dependencias de runtime npm. package.json declara ninguna, y el empaquetado nunca resuelve una ruta node_modules en el artefacto de staging, por lo que el árbol de herramientas de desarrollo no puede alcanzar un navegador instalado. El código de runtime de terceros se vende bajo extension/vendor/ en su lugar. Su fuente, versión y licencia viven en los archivos SOURCE.txt adyacentes, y cada byte vendido está fijado por SHA-256 en extension/vendor/vendor.lock.json, que bun run check:vendor verifica en CI y preflight.

Dos posiciones más de cadena de suministro llevan sus propias insignias arriba, ambas regeneradas por bun run gen:dev y verificadas por desviación en CI. Cada GitHub Action de terceros se ejecuta en un SHA de commit completo, controlado por check:actions: una etiqueta mayor es una ref mutable que su publicador puede mover, lo que significaría código arbitrario en un trabajo que tiene este checkout, y en el flujo de trabajo de lanzamiento, los secretos de firma. Las dependencias recién resueltas también esperan una ventana de cuarentena antes de poder entrar en el lock, establecida por minimumReleaseAge en bunfig.toml, junto con un escaneo de malware en la instalación.

peerd está licenciado bajo la Apache License 2.0. Los componentes vendidos conservan sus propias licencias. CheerpX es un runtime propietario proporcionado por Leaning Technologies y no está cubierto por la licencia Apache de peerd.