O primeiro harness de agente de IA nativo da web

O peerd é o primeiro runtime de agente de uso geral construído diretamente sobre primitivas do navegador: Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn e WebExtensions. Ele roda completamente dentro do Chrome e do Firefox, com suas abas, sessões autenticadas, aplicativos web e computação local.

Enquanto as plataformas de agentes tentam puxar o navegador para dentro do harness, o peerd puxa o harness para dentro do navegador.

Para a inferência real, você pode escolher um provedor de modelo hospedado compatível, um modelo local via localhost, ou conferir o suporte preliminar para modelos locais WebGPU (também estamos de olho no WebNN).

Nenhuma conta peerd, navegador hospedado ou conexão com servidor de ferramentas é necessária. As compilações atuais não enviam telemetria de produto para o peerd.

Instalação · peerd.ai · Arquitetura · Segurança

Recursos

• Funciona no navegador que você já usa. O agente pode ler e controlar suas abas, aplicativos web, sessões autenticadas e conteúdo de páginas.
• Cria clientes de site reutilizáveis. O ator web pode aprender um site uma vez e usar esse cliente novamente em tarefas posteriores.
• Executa código dentro dos limites do navegador. Scripts, JavaScript Notebooks lacrados, ferramentas WASI compiladas, Apps do navegador e WebVMs Linux dão ao agente computação local sem acesso ao seu sistema operacional host.
• Delega para atores separados. Cada página e ambiente de computação recebe seu próprio ator sem chave, com ferramentas limitadas àquele ambiente.
• Mantém contexto útil. Sessões, memória, habilidades, objetivos, revisão e checkpoints vivem na extensão.
• Usa o modelo que você escolher. O inventário de provedores ativo é definido em registry.js, incluindo adaptadores de nuvem BYOK e opções locais sem chave.
• Conecta navegadores diretamente. As compilações de preview adicionam identidade assinada, descoberta navegador a navegador, dwapps e comunicação agente a agente via WebRTC; os pacotes da store removem isso completamente.

Por que o navegador

Agentes locais podem acessar todo o seu computador. Agentes remotos vivem no computador de outra pessoa. O navegador é a alternativa: capacidade local atrás de limites de segurança endurecidos ao longo de três décadas.

O peerd usa esses limites. O trabalho de página vai para atores separados com apenas as ferramentas para aquela aba ou ambiente. Credenciais, regras de rede, confirmações e auditoria permanecem na extensão. Seu design de defesa em profundidade pressupõe que conteúdo não seguro eventualmente passará por um filtro.

Suporte a navegadores

O peerd suporta Chromium e Firefox. O Firefox executa atores em workers dedicados e usa Notebooks visíveis para computação JavaScript. Recursos que precisam do host de documento offscreen do Chrome são removidos dos controles do Firefox e das ferramentas de modelo antes do uso. As compilações de preview do Firefox omitem o dweb até que o Firefox tenha um mesh host.

Apps e WebVMs rodam no Chrome. Apps não têm acesso de rede ambiente. Recursos remotos, fetches, WebRTC, formulários e navegação externa de documentos são bloqueados. Links HTTP e HTTPS externos exigem confirmação do usuário.

Lacunas concretas de capacidade dos navegadores, seus problemas upstream e os testes necessários para remover cada proteção são rastreados em docs/BROWSER-COMPATIBILITY.md.

O código é a fonte da verdade para o comportamento atual. Comece com CLAUDE.md e depois leia o módulo relevante em extension/.

Modelo de segurança

O peerd usa isolamento do navegador, exposição estreita de ferramentas, portões de política de service worker e controles explícitos de egresso. O agente principal delega trabalho de ambiente para atores sem chave. No Chrome e no Firefox, loops de agente que não são orquestradores rodam em heaps de workers dedicados separados. Se o navegador não puder provar esse limite, a solicitação do ator não é executada e não realiza trabalho no alvo.

O comportamento de rede depende da operação. Chamadas de modelo, leituras web, carregamentos de ativos de runtime, tráfego de sandbox e tráfego dweb de preview usam caminhos e políticas de escopo diferentes. Consulte SECURITY.md e o modelo de ameaças para ver os limites atuais e as limitações conhecidas.

Instalação

Chrome a partir do código-fonte

1. Clone o repositório.
2. Abra chrome://extensions.
3. Ative o modo de desenvolvedor.
4. Escolha Carregar sem compactação e selecione o diretório extension/.

Recarregue a extensão de chrome://extensions após alterações no código-fonte.

Firefox a partir do código-fonte

O Firefox precisa de um pacote específico para Firefox. Não carregue o manifest de desenvolvimento do Chrome versionado. Use uma versão do Firefox igual ou superior ao mínimo declarado no patch de canal em manifests/. Esse piso acompanha o suporte a scripting vinculado a documentos usado pelas ferramentas do navegador.

Abra about:debugging#/runtime/this-firefox, escolha Carregar complemento temporário e selecione artifacts/peerd-preview-firefox.xpi. Complementos temporários precisam ser carregados novamente após o Firefox reiniciar. As transformações de navegador e canal são definidas pelos scripts de empacotamento.

Pacotes de lançamento

Consulte GitHub Releases para ver os artefatos atuais. As compilações da store e de preview diferem. As compilações da store omitem o dweb. As compilações de preview o incluem e podem habilitar recursos adicionais de automação. O código de empacotamento é a autoridade para cada navegador e canal.

Primeira execução

1. Abra o peerd pela barra de ferramentas do navegador.
2. Crie e desbloqueie o cofre local. O desbloqueio por frase secreta está sempre disponível. O desbloqueio por passkey depende do suporte a WebAuthn PRF no navegador e no dispositivo.
3. Conclua a breve integração de perfil.
4. Abra Configurações e adicione uma chave de provedor ou escolha um provedor local compatível.
5. Selecione um modelo e inicie um chat.

Apenas segredos do cofre e registros de segurança protegidos são cobertos pelo limite de criptografia do cofre. Outros estados locais da extensão seguem as regras de armazenamento na documentação de segurança.

Arquitetura

A extensão tem cinco módulos principais. Cada módulo expõe sua API pública por meio do seu index.js.

O chassi da extensão vive em background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ e diretórios de suporte relacionados. A disposição dos hosts e a regra do cold worker estão documentadas em docs/EXTENSION-HOSTS.md.

Desenvolvimento

A extensão de origem é JavaScript vanilla com ES modules e roda diretamente quando carregada sem compactação. Não há bundler de desenvolvimento, transpilador, watcher ou árvore de runtime gerada. O empacotamento de lançamento usa Bun apenas em sua cópia de staging descartável para remover espaços em branco/comentários dos módulos de autoria nos grafos frios estáticos de service worker e offscreen do Chrome. Ele preserva limites de módulos, nomes de bindings, imports preguiçosos e cada byte vendido. Passe --no-minify para bun run package -- ... quando um artefato de diagnóstico legível for útil.

Há três superfícies de teste:

• Testes Bun para lógica pura.
• Testes no navegador para integração de extensão e navegador. Eles rodam headless no Chrome e, em shards, no Gecko contra o pacote da Firefox Store instalado. Cada lane executa todos os testes que registra; os totais diferem ligeiramente porque alguns testes só são registrados onde um service worker ativo responde.
• E2E ao vivo no Chrome e verificação visual para fluxos completos.

Ao lado deles, a suíte red-team em tests/red-team/ executa cada adversário do modelo de ameaças contra o código de defesa real e registra se cada sonda hostil foi bloqueada. Sua matriz está em docs/security/RED-TEAM-RESULTS.md.

Cada lane publica sua própria contagem como um badge acima. O JSON de badges em badges/ é gerado pelo job de CI que executou a lane e depois comparado por diff, então uma contagem nesta página é sempre evidência de uma execução que aconteceu, e não um número digitado por alguém. Regere um com bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (precisa de Firefox e geckodriver), ou bun run gen:badge:e2e, e faça commit do resultado. bun run check:badges verifica se os endpoints estão bem formados sem iniciar um navegador.

Para alterações de UI, execute bun run e2e:verify, inspecione scripts/cdp/artifacts/result.json e verifique as capturas de tela geradas.

Arquivos gerados não devem ser editados manualmente. Em particular, extension/manifest.json e extension/shared/channel-config.js vêm das fontes de manifest e empacotamento. A CI verifica se há desvios.

Leia CONTRIBUTING.md antes de alterar código.

Documentação

• CLAUDE.md: estrutura do projeto, convenções e postura atual
• SECURITY.md: política de segurança e relato de problemas
• docs/security/THREAT-MODEL.md: limites de confiança e riscos residuais
• docs/security/LIFECYCLE-CONTRACT.md: comportamento de interrupção e limites de recuperação
• docs/security/RED-TEAM-RESULTS.md: cobertura do red-team
• docs/APP-ACTORS.md: atores de App definidos por manifest, adaptadores semânticos ativos e a UX de co-piloto na aba
• docs/DWAPP-BUNDLE.md: transporte de dwapp compactado, árvores de trabalho decodificadas e ativos binários
• docs/store/: empacotamento da store, permissões, privacidade e notas para revisores
• scripts/cdp/states.mjs: estados E2E e visuais

Dependências e licença

A extensão distribuída não tem dependências de runtime npm. O package.json não declara nenhuma, e o empacotamento nunca resolve um caminho node_modules para o artefato em staging, então a árvore de ferramentas de desenvolvimento não pode alcançar um navegador instalado. O código de runtime de terceiros é fornecido sob extension/vendor/ em vez disso. Sua origem, versão e licença ficam nos arquivos SOURCE.txt adjacentes, e cada byte vendido é fixado por SHA-256 em extension/vendor/vendor.lock.json, que bun run check:vendor verifica na CI e no preflight.

Mais duas posições na cadeia de suprimentos têm seus próprios badges acima, ambos regenerados por bun run gen:dev e verificados por drift na CI. Toda GitHub Action de terceiros roda em um SHA de commit completo, controlado por check:actions: uma tag major é uma referência mutável que seu publicador pode mover, o que significaria código arbitrário em um job que possui este checkout e, no workflow de release, os segredos de assinatura. Dependências recém-resolvidas também passam por uma janela de quarentena antes de entrar no lock, definida por minimumReleaseAge em bunfig.toml, junto com uma varredura de malware na instalação.

O peerd é licenciado sob a Apache License 2.0. Componentes vendidos mantêm suas próprias licenças. O CheerpX é um runtime proprietário fornecido pela Leaning Technologies e não é coberto pela licença Apache do peerd.